以下の表では、MarkLogicデータハブサービスと他の技術を比較したものの概要を示します。データハブサービスは数多くの技術を1つのデータプラットフォームに統合した製品であるため、同等の機能を実現するために複数の技術を組み合わせたものと比較されることがよくあります。これは二者択一ではありません。データハブと他の技術が併用されることはよくあります。全体のアーキテクチャについて検討する際に重要なのは、この選択によりアーキテクチャがよりシンプルになるか、それとも複雑になるかということです。
|
MarkLogicデータハブサービス |
データウェアハウス + ETL |
マネージドクラウドサービス |
データレイク + オープンソースコンポーネント |
|
すべてのエンタープライズデータに対して柔軟なデータの統合、管理、検索機能を提供するクラウドのデータハブ。MarkLogicサーバーを基盤とする |
従来型のエンタープライズデータウェアハウス（EDW）。Oracleと従来からあるETLツール（Informaticaなど）を統合したもの |
カスタムビルドのクラウドデータハブアーキテクチャ。大手クラウドプロバイダが提供するマネージドクラウドサービスコンポーネントを使用したもの。
例えば、AWSはDynamoDB（ドキュメント）、NeptuneDB（グラフ）、Elasticsearch Service（検索）、Amazon S3（オブジェクトストレージ）、Glue（ETL）、Athena（クエリサービス）を提供している |
Hadoopおよびさまざまなデータモデル固有のデータベース、検索エンジン、ETLツールを使用したデータレイク。
多くのバリエーション。ClouderaとMongoDB（ドキュメント）、Lucene（検索）、Neo4j（グラフ）、Talend（ETL）を組み合わせたものなど。 |
| ユニファイド（一元的）
トランザクション（業務）および分析に利用できるか？ マルチモデルか？
|
はい
実績あり |
場合による
OLTP向きではない。真のマルチモデルではない。非リレーショナルデータには不向き（低速でコストが高い） |
いいえ
コンポーネントごとに導入、統合、監視、保護、支払いが必要 |
いいえ
データサイエンティスト用に最適化されたパッチワーク的なアーキテクチャ。各ツールを別々に管理して統合する必要があるという同じ問題を抱えている |
| アジャイル
プロジェクトの完了にかかる時間
|
はい
他の選択肢の1/10の時間でデータの統合が可能 |
アジャイルではない
ETLに時間がかかる。すべて事前にモデリングする必要がある |
場合による
小規模なプロジェクトでのみ短期間で済む。大規模なプロジェクトでは指数関数的に複雑さが増す |
いいえ
導入スケジュールが長い（データサイエンス作業においても） |
| 基幹業務に対応できるエンタープライズ仕様
安全性、信頼性、実績
|
はい
ミッションクリティカルな環境での実績ある信頼性と高度なセキュリティ |
はい
|
その途上にある
個々のコンポーネントは安全。統合したときに問題が生じる |
いいえ
大規模になると管理不能 |
| クラウドネイティブ
フルマネージド型か？ どのクラウドか？
|
はい
クラウドネイティブ、マルチクラウド |
場合による
クラウド導入は複雑。真のSaaSサービスではない場合も |
クラウドニュートラルではない
クラウドネイティブだが、クラウドニュートラルではない |
複雑
管理は複雑で、コストが高い |
