MarkLogicのクラウドネイティブなデータ統合をご確認ください。
MarkLogicのクラウドネイティブなデータ統合をご確認ください。
主なクラウドデータベース企業の詳細
主なクラウドデータベース企業の詳細
DHS上に構築された新たなコンテンツハブでお客様やパートナー様、MarkLogicの新しい動画をご覧ください。
ここでの目的は、データ管理ソリューションを比較する際の枠組みを提供するとともに、既存のアーキテクチャ内で今後MarkLogic製品をどのように導入していけるのかを示すことです。ひとつの完璧なソリューションであらゆるユースケースに対応できるわけではありません。トレードオフを考慮し、また今後既存のアーキテクチャがどう変化するのかを考えておくことが重要です。
まず、頻繁に話題になる主な比較対象を取り上げます。以下の比較を読む際には、「自分たちのビジネス目標は何か」について考えてください。こうすることにより、目的を伴わない単に抽象的・純粋な機能比較ではなく、自分たちが今抱えるデータ問題およびビジネス問題の解決に必要な要件は何なのかがはっきりします。
以下の表では、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サービスではない場合も |
クラウドニュートラルではない クラウドネイティブだが、クラウドニュートラルではない |
複雑 管理は複雑で、コストが高い |
以下の表は、MarkLogicサーバー(マルチモデルデータベース)を、データハブアーキテクチャの基礎となりうるかどうかの観点から、他の著名なデータベース技術と直接比較した概要を示したものです。
MarkLogicサーバー | Oracle | DynamoDB | MongoDB | |
---|---|---|---|---|
マルチモデル |
はい 実績のある柔軟なマルチモデル |
場合による 業界標準の非リレーショナルタイプに対応しているが不十分 |
いいえ AWSはデータモデルごとに個別のDBMSを提供 |
いいえ ドキュメントのみ。ドキュメントを業界標準ではないBSONとして格納 |
セキュリティ |
はい 認証済みのセキュリティと定評のある実績 |
はい |
場合による きめ細かく制御できない。リネージのトラッキングに制約あり。開発者側に責任を負わせる |
場合による きめ細かく制御できない。リネージのトラッキングに制約あり。開発者側に責任を負わせる |
分散トランザクション |
はい 大規模実装でも実証済みのACIDトランザクション。すべてのANSI規格に対応 |
はい |
場合による シンプルなACIDトランザクション。実証されていない |
いいえ MongoDB 4.2.6は、ACID準拠に関する第三者機関によるテストに不合格。リードスキュー異常、循環的な情報フロー、書き込みの重複、内部的な整合性の破綻が発生 |
スケーラビリティ |
はい 実績あるスケーラビリティおよび弾力的な拡張・縮退と、優れたコストパフォーマンス |
場合による Oracleを拡張する場合、データを新たなサイロにフォークする必要があることが多い。スケールアウトは費用がかさむ |
はい |
場合による 困難だがリレーショナルより安価。多くの場合ダウンタイムが発生しリファクタリングが必要 |
クラウドニュートラル |
はい クラウドニュートラルの実績あり |
はい ライセンスの再取得が必要な場合あり |
いいえ AWS上でのみ稼働 |
はい |
MarkLogicによる、迅速なデータ統合、コスト削減、安全なデータ共有についてご紹介します。
当Webサイトを継続利用することにより、お客様はMarkLogicのプライバシーステートメントに従ってクッキーの使用に同意するものとします。