MarkLogic 製品と他社製品との比較
ここでの目的は、データ管理ソリューションを比較する際の枠組みを提供するとともに、既存のアーキテクチャ内で今後 MarkLogic 製品をどのように導入していけるのかを示すことです。ひとつの完璧なソリューションであらゆるユースケースに対応できるわけではありません。トレードオフを考慮し、また今後既存のアーキテクチャがどう変化するのかを考えておくことが重要です。
主な比較項目
まず、頻繁に話題になる主な比較対象を取り上げます。以下の比較を読む際には、「自分たちのビジネス目標は何か」について考えてください。こうすることにより、目的を伴わない単に抽象的・純粋な機能比較ではなく、自分たちが今抱えるデータ問題およびビジネス問題の解決に必要な要件は何なのかがはっきりします。
MarkLogic データハブと他社製品の比較
以下の表では、MarkLogic データハブと他の技術を比較したものの概要を示します。データハブは数多くの技術を1つのデータプラットフォームに統合した製品であるため、同等の機能を実現するために複数の技術を組み合わせたものと比較されることがよくあります。しかしこれは二者択一ではありません。データハブと他の技術が併用されることはよくあります。全体のアーキテクチャの検討において重要なのは、この選択によりアーキテクチャがよりシンプルになるか、それとも複雑になるかということです。
| MarkLogic データハブ | データウェアハウス + ETL | マネージドクラウドサービス | データレイク + オープンソースコンポーネント | |
|---|---|---|---|---|
| 概要 | あらゆるエンタープライズデータに対して柔軟なデータの統合、管理、検索を提供するデータハブ。MarkLogic サーバーを基盤とする。 | 従来型のエンタープライズデータウェアハウス (EDW)。Oracle と従来からある ETL ツール (Informaticaなど) を統合したもの | カスタムビルドのクラウドデータハブアーキテクチャ。大手クラウドプロバイダが提供するマネージドクラウドサービスコンポーネントを使用したもの。 | Hadoop およびさまざまなデータモデル固有のデータベース、検索エンジン、ETL ツールを使用したデータレイク。 |
| ユニファイド (一元的) | はい | 場合による | いいえ | いいえ |
| トランザクション (業務) および分析に利用できるか？マルチモデルか？ | 実績あり | OLTP 向きではない。真のマルチモデルではない。非リレーショナルデータには不向き (低速でコストが高い) | コンポーネントごとに導入、統合、監視、保護、支払いが必要 | データサイエンティスト用に最適化されたパッチワーク的なアーキテクチャ。各ツールを別々に管理して統合する必要があるという同じ問題を抱えている |
| アジャイル | はい | アジャイルではない | 場合による | いいえ |
| プロジェクトの完了にかかる時間 | 他の選択肢の1/10の時間でデータの統合が可能 | ETL に時間がかかる。すべて事前にモデリングする必要がある | 小規模なプロジェクトでのみ短期間で済む。大規模なプロジェクトでは指数関数的に複雑さが増す | 導入スケジュールが長い (データサイエンス作業においても) |
| 基幹業務に対応できるエンタープライズ仕様 | はい | アジャイルではない | その途上にある | いいえ |
| 安全性、信頼性、実績 | ミッションクリティカルな環境での実績ある信頼性と高度なセキュリティ | はい | 個々のコンポーネントは安全。統合したときに問題が生じる | 大規模になると管理不能 |
MarkLogic サーバーと他社製品の比較
以下の表は、MarkLogic サーバー (マルチモデルデータベース) を、データハブアーキテクチャの基礎となりうるかどうかの観点から、他の著名なデータベース技術と直接比較した概要を示したものです。
| MarkLogic サーバー | Oracle | DynamoDB | MongoDB | |
|---|---|---|---|---|
| マルチモデル | はい 実績のある柔軟なマルチモデル | 場合による 業界標準の非リレーショナルタイプに対応しているが不十分 | いいえ AWSはデータモデルごとに個別の DBMS を提供 | いいえ ドキュメントのみ。ドキュメントを業界標準ではない BSON として格納 |
| セキュリティ | はい 認証済みのセキュリティと定評のある実績 | はい | 場合による きめ細かく制御できない。リネージのトラッキングに制約あり。開発者側に責任を負わせる | 場合による きめ細かく制御できない。リネージのトラッキングに制約あり。開発者側に責任を負わせる |
| 分散トランザクション | はい 大規模実装でも実証済みの ACID トランザクション。すべてのANSI規格に対応 | はい | 場合による シンプルな ACID トランザクション。実証されていない | いいえ MongoDB 4.2.6 は、ACID 準拠に関する第三者機関によるテストに不合格。リードスキュー異常、循環的な情報フロー、書き込みの重複、内部的な整合性の破綻が発生 |
| Scalability | はい 実績あるスケーラビリティおよび弾力的な拡張・縮退と、優れたコストパフォーマンス | 場合による Oracle を拡張する場合、データを新たなサイロにフォークする必要があることが多い。スケールアウトは費用がかさむ | はい | 場合による 困難だがリレーショナルより安価。多くの場合ダウンタイムが発生しリファクタリングが必要 |
| クラウドニュートラル | はい クラウドニュートラルの実績あり | はい ライセンスの再取得が必要な場合あり | いいえ AWS 上でのみ稼働 | はい |
