MarkLogic と MongoDB との比較
概要
新しいアプリケーションを構築し、レガシーアプリケーションをモダナイズする目的で、市場にはリレーショナル以外のデータベースが数多く登場しています。しかし依然としてデータ統合に大きな課題があるのはなぜでしょうか。
個別に運用されている多数のシステム内に、大量の様々なデータが蓄積されている、というのはよくある話です。さらに、クラウドサービスやアプリケーションの導入により、多様なデータサイロは増加の一途をたどっています。このような状況において、急速に進化するビジネスニーズを満たすアプリケーションを構築するには、次の機能が必要です。
- 多様なデータソースを迅速に読み込んで統合し、一元化されたビューを表示
- 結果を迅速かつ反復的に提供することで、データ統合のコストとリスクを軽減
- データのガバナンスとセキュリティを向上させ、セルフサービスの利用とデータの共有を促進
ここでは、「MongoDB Atlas」および「MarkLogic データハブサービス」という2つのクラウドデータプラットフォームが、どのようにデータ統合のニーズに対応できるのかを比較します。特に、全社的なデータ統合におけるこれらのクラウドサービスの機能と根本的な違いを比較します。
比較表
| MarkLogic データハブサービス | MongoDB Atlas | |
|---|---|---|
| 目的 |
|
|
| 統合プラットフォーム |
|
|
| データ統合 |
|
|
| 基盤となるデータベース |
|
|
| トランザクション |
|
|
| セキュリティ＆ガバナンス |
|
|
| データへのアクセス |
|
|
| 検索 |
|
|
| スケーラビリティ |
|
|
| コスト |
|
|
| デプロイメント |
|
|
MongoDB Atlas とは
MongoDB Atlas はフルマネージドのクラウドデータベースサービス (DBaaS) です。これにより、アプリケーションを簡単にクラウドに移行できます。コンサンプション (消費) ベースの料金設定であり、MongoDB NoSQL データベースの実行、拡張、管理に関するタスクをオフロードできます。
MongoDB はオープンソースライセンスとその使い易さから、最も人気の高いドキュメントデータベースになっています。分散型のスケールアウトアーキテクチャと、データ集約用の一元化されたクエリインターフェイスにより、可用性が高く対応力のあるアプリケーションを簡単に構築できます。また、リレーショナルデータベースではなくドキュメントデータモデルなので、アプリケーションデータモデルをデータベーススキーマを再構築せずに簡単に進化させられる柔軟性があります。これにより生産性が向上します。最近では、マルチドキュメントに対する ACID トランザクションなどの新機能、MongoDB Stitch などの新しいクラウドサービスによって、MongoDB Atlas の利用領域は拡大しています。
MarkLogic データハブサービスとは
MarkLogic データハブサービスは、アジャイルなデータ統合のためのサーバーレスなクラウドデータハブです。データ統合ワークロードをクラウドに簡単に移行し、トランザクション、運用、および分析用の各アプリケーションを大規模に実行できます。またコストは予測可能になり削減されます。
データハブサービスの一元化されたアーキテクチャは、DBaaS よりも優れています。あらゆるデータを読み込んでキュレーションし、データ統合ライフサイクル全体に対してガバナンスを適用します。マルチモデルデータ管理、ビルトイン検索、トランザクション、きめ細かなセキュリティ、スマートマスタリングなど、必要な機能がすべて揃っています。これらの機能を使うことで、企業全体のデータを素早く統合し、複数のユースケースおよびユーザータイプに対応できる耐久性の高いデータアセットを実現できます。
データハブサービスの主なメリットの一部をご紹介します。
- 必要に応じてデータソースを柔軟に追加。変化し続けるデータに対応。スキーマオンリードにより、現在および将来の利用方法に対応 (事前のデータモデリングは不要)
- アジャイルなデータ統合 (時間がかかる複雑な ETL は不要)
- データの分断を解消し、データアーキテクチャをシンプルに (ポリグロットパーシステンスアプローチにより様々なデータベースを統合する必要がない)
- ビジネスエンティティおよび関係性をよりリッチにモデリング。さらにリッチなクエリとデータサービスを実現
- オープンスタンダードおよび API によるクラウドニュートラルなサービス。データの読み込み、クエリ、共有 (ベンダーロックインがない)
用語とコンセプト
| MarkLogic データハブサービス | MongoDB Atlas | |
|---|---|---|
| データモデル |
|
|
| データのキュレーション |
|
|
| データリネージ |
|
|
| Indexing |
|
|
| クエリ |
|
|
| セキュリティ |
|
|
| トランザクション |
|
|
上の表で紹介したとおり、MarkLogic データハブサービスではさまざまなデータ形式をサポートしており、ネイティブ形式のままデータを読み込めるので、データ統合がより楽になります。統合後、ビルトインのデータキュレーションツールを使って、元のデータを段階的にカノニカルデータに変換できます。また出自やリネージに関する価値の高いメタデータを記録できます。このように、データとメタデータをライフサイクル全体を通じて一緒に扱うので、検索やクエリ、データ共有を安全に行えます。
MarkLogic データハブサービスの方がクラウドサービスに適している理由
MarkLogic データハブサービスと MongoDB Atlas はいずれも NoSQL (非リレーショナル) に基づいて構築されていますが、その目的は異なります。以下のセクションでは、これら2つのデータ管理プラットフォームの主な違いを説明していきます。
一元化されたプラットフォーム：クラウドデータハブ vs クラウドデータベース
MarkLogic データハブサービスは、フルスタックのエンタープライズデータ統合プラットフォームを備えたクラウドデータハブです。たいへんな運用作業の負担はありません。一元化されたアーキテクチャなので、データ統合用に自分で複数のものを継ぎはぎしてデータハブソリューションを構築するよりも、市場投入時間が短く TCO (総所有コスト) も小さくなります。
データハブサービスでは、データをそのまま読み込める柔軟性があるため、データを段階的に統合およびキュレーションして、セマンティックメタデータを追加できます。データの品質やセキュリティ、ガバナンスを犠牲にする必要はありません。また、AWS や Azure といったプラットフォームサービスとシームレスに統合できるため、データハブサービスを自社のエンタープライズデータアーキテクチャに簡単に統合できます。様々なクラウドプラットフォームサービスを活用し、データハブサービス内にクラウドネイティブのアプリケーションやワークフロー、パイプライン (データ統合ワークロードをオーケストレーションする) を構築できます。
MongoDB Atlas はドキュメント DBaaS です。MongoDB はこれ以外にアドオン型クラウドサービスとして、Atlas Search、MongoDB Stitch、MongoDB Charts なども提供しています。これらは Atlas と統合できますが、Atlas とは別に課金されます。
MongoDB Atlas は、データサービス (または REST API) を構築するためのきめ細かいデータセキュリティポリシーやアプリケーションサービスを提供していません。このためアプリケーションにおいて、データベース以外の場所にデータ処理ロジックとデータセキュリティポリシーを実装する必要があります。この場合、セキュリティホールと拡張性の問題によってアプリケーションがより脆弱になります。これとは対照的に、MarkLogic データハブサービスのデータサービス (または REST API) はデータベースに実装されており、ビルトインの検索エンジン、キャッシュ、およびきめ細かいデータアクセスポリシーを活用できるので、スピーディかつ安全なデータ処理を実現できます。
MongoDB Stitch サービス (Atlas 用のアプリケーションサービスときめ細かいデータアクセスポリシーを提供する) のサブスクリプションも提供されていますが、これによりさらにコンサンプションベースのコストがかかるため、TCO が増加します。
また、MongoDB Atlas にはデータ統合ツールが標準機能として搭載されていません。そのため、業務データレイヤやレガシーのモダナイゼーションなどの様々なユースケースに対応するには、サードパーティーのツールを使ってデータを統合する必要があります。これにより、TCO の増加だけでなく、複数のツールでデータとメタデータの整合性を維持する際のガバナンス上の問題も発生します。一方 MarkLogic データハブサービスでは、統合ライフサイクルを通じてデータとメタデータを一緒にトラッキングするため、すべてを1か所で安全に制御できます。このように、分断データの統合に関して、MongoDB よりも MarkLogic に大きなメリットがあると言えます。
データ統合：ビルトインツール vs サードパーティツール
MarkLogic データハブサービスは、マルチ構造データのアジャイル統合に特化した、一元化されたサービスです。反復的なアプローチでカノニカルモデルの構築、データのハーモナイズやマスタリング、セマンティックによるデータのエンリッチを行い、アプリケーションへのデータサービスの提供時間を短縮します。このアプローチにより、さらに短期間で結果が得られます。
データハブサービスにはエンドツーエンドのデータキュレーションツールが備わっています。非リレーショナルデータを適切に処理できるだけでなく、リネージや出自などのメタデータもトラッキングできるので、プロセス全体へのガバナンスを実現できます。ローコード/ノンコードのこのデータキュレーションツールの機能は次のとおりです。
- 階層型 (または入れ子) エンティティ、関係性、その他のメタデータ (インデックスや個人情報フィールドなど) を定義するモデラー
- ビルトイン関数（またはカスタムコード）の豊富なライブラリを使ってソースデータをカノニカルモデルにハーモナイズするマッピング機能
- 重複を処理 (または削除) するマッチ＆マージルールを定義するスマートマスタリング。選択してアンマージすることも可能
- モダンな検索と視覚化を提供するエクスプローラ。キュレーション済みデータおよびメタデータのセルフサービス利用を実現
これらのポイント＆クリックツールにより、段階的なデータキュレーションができます。ユーザーは、プロセス内の各ステップを検証できます。また、データ統合ライフサイクルの任意のステップに戻ることで、問題を迅速に修正 (または変更に対応) できます。ビジネス上の緊急の課題を解決するために、カノニカルモデルを簡単に拡張することで、新しいデータソースの取り込み、データのガバナンスとキュレーションを実現できます。
一方、MongoDB Atlas では、ETL (データのハーモナイズ用)、MDM (データのマスタリング用)、グラフデータベース (セマンティック的なエンリッチ用) など様々なサードパーティーツールが必要です。また、分断データの統合にはさらに他のツールも必要です。このようなデータ統合アーキテクチャでは、運用および保守のコストが大きくなります。実行されるサービスが増えることで、インフラのフットプリント (データの重複やバックアップなど)、DevOps の複雑さ、そしてガバナンス上の課題 (分断されたセキュリティポリシーやリネージなど) も増加します。
また、サードパーティーのデータ統合ツール (ETL や MDM など) は非リレーショナルデータよりもリレーショナルデータの処理を得意としています。このため、これらのツールを使って複雑な階層型ドキュメントをハーモナイズおよびマスタリングするには、メンテナンスと拡張が難しいカスタムコードが必要になります。
MarkLogic データハブサービスの統合アーキテクチャは、シンプルな運用を実現します。生産性が向上し、安全で信頼性の高い統合ハブが得られます。反復的なモデルドリブンアプローチによって、あらゆるソース (Oracle、Teradata、Hadoop など) から様々なデータ形式（ IoT、メインフレーム、ERP など) を簡単に統合して、目的に合った一貫性のあるデータアセットを提供します。
データモデル：マルチモデル vs ドキュメントモデル
MarkLogic データハブサービスは、実績のある MarkLogic サーバーに基づいて構築されています。MarkLogic サーバーはマルチモデルデータベースで、データをドキュメントおよびセマンティックグラフとして保存でき、SQL クエリ用のリレーショナルビューをサポートしています。複数のサイロにまたがるビジネスコンセプトを管理できる柔軟性を備えており、単一の統合バックエンド内でこれらのコンセプトをエンティティおよび関係性として具体的に表現できます。
同一エンティティに関するデータを複数の形式 (JSON、XML、RDF トリプルなど) で保存できます。標準的なクエリ言語 (SQL や SPARQL など) や REST API でこのデータにアクセスできます。セマンティックとドキュメントデータを統合し、階層型の関係性を把握することでデータへの意味付けができます。例えば、JSON ドキュメントとして保存したエンティティを RDF トリプルによる分野固有のオントロジーでエンリッチすることで、セマンティック検索用のナレッジグラフを作成できます。このように、MarkLogic はより高度な統合データインテリジェンスプラットフォームとして、エンティティと関係性を管理できます。
MongoDB Atlas は、ドキュメントモデル専用のデータベースです。ネイティブでは他のデータモデルをサポートしません。データは JSON ドキュメントのバイナリシリアライゼーションである BSON として保存されます。柔軟な集約フレームワークを備えており、様々な演算子 (join、filter など) を使ってドキュメントを処理します。
これはドキュメントモデルであるため、非常に柔軟性が高いデータベースとなっています。しかし、関係性すなわち関連付けられたデータの保存と解析には適していません。MongoDB Atlas には、ドキュメントに対してシンプルなフィールド値ベースのグラフトラバーサルを実行する再帰的な検索のための集約演算子が用意されています。しかし、データセット内の複数の関係性を分析するための、複雑なパターンマッチングを行うグラフクエリはサポートしていません。このため MongoDB Atlas では、グラフデータを扱う分析アプリケーションは構築できません。これとは対照的に、MarkLogic データハブサービスではグラフをネイティブにサポートしているため、セマンティック検索用に専門知識 (ドメインナレッジ) に基づいて関係性を記述したりデータをエンリッチしたりできます。このアプローチにより、ソーシャルグラフや不正検知などといった、高度な分析アプリケーションを簡単に構築できます。
また、MongoDB Atlas のコレクションにはいろいろな制約があります。ドキュメントは1つのコレクションにしか割り当てられず、セキュリティポリシーは各ドキュメントではなくコレクション単位で設定されます。一方、MarkLogic データハブサービスのコレクションはラベルのようなものであり、柔軟なスライス＆ダイス検索ができます。また、よりきめ細かいレベルでセキュリティポリシーを定義でき、コレクション、ドキュメント、サブドキュメントのレベルでセキュリティポリシーを設定できます。
分断データの統合には柔軟なデータ基盤が必要ですが、MongoDB Atlas のドキュメントのみのデータモデルでは不十分です。MarkLogic データハブサービスでは、単一の統合バックエンドで柔軟なマルチモデルデータ基盤が利用できるため、簡単、スピーディかつ安全にデータを統合できます。
トランザクション：100%ACID vs 部分的なACID
MarkLogic は10年以上にわたってハイパフォーマンスなトランザクション (業務) アプリケーション (「SoR：システムオブレコード」) を提供してきました。MarkLogic データハブサービスは100％の ACID トランザクションを提供し、読み取りと書き込みの両方で強いデータの整合性を実現しています。実績のある MarkLogic サーバーを基にして構築されており、ミッションクリティカルな大規模な業務システムに必要な、妥協のないデータの整合性および耐久性を備えています。
ハイパフォーマンスな ACID トランザクションは、オペレーショナル/トランザクショナルなデータハブの基礎となる機能です。データハブサービスでは、事業部門の垣根を超えてデータを素早く統合でき、業務アプリケーションのデータをリアルタイムかつ一貫性のある形で一か所で把握できます。MarkLogic の ACID トランザクションの詳細については、こちらのブログをご覧ください。
MongoDB のトランザクションは長年かけて改善されてきましたが、100% ACID 準拠の整合性が必要な大規模案件では、いまだに適切な選択肢とは言えません (結局のところ、これこそ開発者が本当に求めている機能であり、MongoDB 開発者が長年求めてきたものなのですが)。
最近の発表によると、レプリカセットおよびシャーディング済みクラスタ環境において、マルチドキュメントの ACID トランザクションが追加されました。デフォルトでは、MongoDB のトランザクションは ACID に準拠しておらず、読み取りと書き込み確認 (read/write concern) が弱くなっています。このため ACID を実現するには、一番高いトランザクションレベルの読み取り確認 (「スナップショット」) と書き込み確認 (「majority (過半数)」) に、明示的に設定する必要があります。しかし、MongoDB バージョン4.6.2 の ACID 準拠に関する独立機関のレポートによると、読み取り確認と書き込み確認のレベルを最高にしても、MongoDB はスナップショットの分離ができませんでした。このレポートでは、「スナップショットの分離」における「完全な ACID トランザクション」という MongoDB の主張は疑わしいか、誤解を招くと結論付けています。
また、MongoDB Atlas では整合性が強い書き込み (「過半数」書き込み確認) ではパフォーマンスが落ちます。これは、非同期データレプリケーション (マスター/スレーブレプリケーション) により、レイテンシが大きくスループットが低いためです。一方、MarkLogic データハブサービスでは同期的なデータレプリケーションを行います。
通常、アプリケーションは、MongoDB Atlas によるデータの整合性と耐久性に依拠することができません。これは、読み取りと書き込みの整合性の切り替え (ACID をクエリごとに有効化/無効化できる) ができるためです。そのため、アプリケーション側で強い整合性のある読み取り (「linearizable」読み取り確認など) を行うことでダーティリードや旧バージョンの読み取りを回避する必要があります。また読み取りの際にクォーラムを使用するため、この場合もレイテンシが高くなります。
MongoDB Atlas ではトランザクションが ACID に完全に準拠していないため、アプリケーション側でトランザクションロジックを実装する必要がありますが、これは保守や拡張が困難です。つまり、MongoDB Atlas はミッションクリティカルなトランザクショナル/オペレーショナルアプリケーションには適していません。
セキュリティ：一元化されたきめ細かいセキュリティ vs アプリケーション側でのセキュリティ
MarkLogic データハブサービスでは、ドキュメント単位および要素単位のセキュリティできめ細かいアクセス制御を行います。また、ルールベースのリダクションポリシーでデータ消失を防止します。セキュリティポリシーは柔軟なロールベースモデルで定義され、個々のフィールド単位までリダクションおよびアクセス制御が可能です。きめ細かく定義されたポリシーは、ユーザーのセキュリティプロファイルに基づいて、暗黙的な制約としてデータベースによって適用されます。その結果、管理者はすべてのデータアクセス (つまり元のデータと統合済みデータの両方) に一貫して適用されるセキュリティポリシーを一元的に管理できます。これにより、組織は安心してデータを共有でき、複数のユースケースやユーザータイプに対してデータを提供できます。このように、MarkLogic のデータ統合により、セキュリティとデータガバナンスが改善されます。。セキュリティの詳細についてはトラストセンターをご覧ください。
一方、MongoDB では、データアクセスの制御や機密データの共有に関して、これと同等のきめ細かいセキュリティがありません。ドキュメントに記載されているように、MongoDB Atlas ではドキュメントやサブドキュメント単位ではなく、コレクション単位でしかデータが保護されません。このため、フィールド単位の保護はアプリケーション開発者が行う必要があります。ドキュメントに記載されているように、データベースに対するすべてのクエリに対応できるフィールド単位のリダクションロジック (フィルタなど) をアプリケーション側に実装する必要があります。一方、MarkLogic データハブサービスでは、セキュリティポリシーをデータベースが担うので、アプリケーション側にデータセキュリティポリシーを実装する必要はありません。
データセキュリティが適用された場合でも、依然としてデータを共有できることが重要です。MarkLogic の強固なセキュリティ制御は、世界中のミッションクリティカルシステムにおける実績があります。MarkLogic は、大手の金融サービス機関、医療機関、政府機関におけるデータアセットの保護において高い信頼と評価を得ています。
拡張性： 100% ACID のスケールアウト vs 結果整合性のスケールアウト
MarkLogic には、3ペタバイト以上のデータが格納されているケースもあります。MarkLogic データハブサービスは分散型シェアードナッシングアーキテクチャであり、複雑なデータシャーディングを心配することなく弾力的に拡張・縮小できます。
シングルテナントのアクティブ/アクティブ高可用性実装アーキテクチャであり、同期的なデータレプリケーションと自動フェイルオーバーを備えています。さらに、業務/分析/データ統合の各ワークロードおよびストレージごとに個別に自動拡張されるため、高いパフォーマンスと信頼性を実現します。
また、自動データバランシングやビルトインの検索エンジンなどの機能により、アプリケーションを拡張してもクエリのパフォーマンスを維持できるだけでなく、アプリケーションによるデータベースのキャッシュも最小限に抑えられます。詳細については、データハブサービスのページをご覧ください。
MongoDB Atlas は分散型アーキテクチャを採用しており、データシャーディングによって水平スケールアウトを実現しています。シャーディングによって、MongoDB Replica Set 実装は単一サーバーを超えて拡張できます。このアプローチでは、複雑な移行を手作業で行って Replica Set 実装をシャーディングされたクラスタに変換する必要があります。この場合、各シャードは独立した Replica Set としてモデリングされます。
シャーディングは DataOps チームにとって複雑な作業です。というのもアプリケーションを、データシャーディングのメリットが受けられるように設計する (つまり、後から変更がきかないシャーディングキーに基づいてデータモデルを設計する) 必要があるのです。さらに、MongoDB のマルチドキュメント ACID トランザクションは、大規模構成時にはレイテンシが高く、データの整合性が弱くなります。このため、データのキュレーションと業務 (オペレーショナル) ワークロードには、MongoDB Atlas を使用できません。一方、MarkLogic データハブサービスは、100% ACID 準拠のスケールアウトアーキテクチャを提供しています。
100% ACID 準拠の分散型スケールアウトシステムを構築するのは容易ではありません。MarkLogic データハブサービスでは、運用の負担なく、データアーキテクチャをシンプルにし、ミッションクリティカルなワークロードを大規模に実行できます。
検索/クエリ/インデックス：マルチモデル対象かつ検索に最適化されたクエリ vs ドキュメントのみ対象のクエリ
MarkLogic データハブサービスは、優れたパフォーマンスを提供し、元のデータと統合済みデータの両方に対するセルフサービス利用を促進するように設計されています。検索ベースのアプローチでデータにアクセスし、一元化された検索インターフェイスから複数のデータモデルに対してクエリを実行できます。
ビルトインの検索エンジンでドキュメントの構造とコンテンツ（単語、フレーズ、関係性、値など）に自動的にインデックス付けすることにより、効率的かつ高速な検索クエリが実現されています。このインデックス情報はユニバーサルインデックスと呼ばれ、読み込まれたデータにすぐにインデックス付けします。特定のインデックスを設定しなくても、読み込んだあらゆるコンテンツを全文検索できるため、わざわざモデリングしなくても元データのプロファイリングが可能です。
インデックスは常にデータと同期されているため、トランザクショナル/オペレーショナルなユースケース (業務利用) に簡単に対応できます。複雑なクエリをサポートするために、レンジインデックス、リバースインデックス (リアルタイムアラート用)、地理情報インデックス、トリプルインデックス (セマンティックグラフや RDF データ用) などのインデックスが用意されています。
インデックスの作成と保守を自動化することで、データハブサービスでは複数のデータモデル (ドキュメント、グラフ、リレーショナル) に対して、Optic API などの一つの複合クエリで高速かつ簡単に検索を実行できます。また、標準的なクエリ言語、API、プログラミング言語 (SQL、SPARQL、REST、JavaScript、XQuery など) を使ってデータの格納とアクセスを柔軟に行えます。例えば、インデックスを活用することで、SPARQL とドキュメント検索クエリを組み合わせたセマンティック検索をナレッジグラフに対して実行しインサイトを発見したり、リレーショナルビュー対して SQL 分析を実行したりできます。
多数の検索機能がすでに備わっているので、高度な検索アプリケーションを簡単に構築できます。検索機能には、近接、ワイルドカード、句読点の区別、発音符号による区別、大文字小文字の区別、スペル修正、シソーラス、スニペット、ファセット、検索結果の強調表示、予測入力機能、ステミング (語幹処理)、関連度順表示、多言語サポートなどがあります。
一方、MongoDB Atlas は、アドホックなドキュメントクエリと、マルチステージパイプラインとしてドキュメントを処理する aggregation パイプラインフレームワークを使った集約クエリをサポートしています。aggregation パイプラインフレームワークは複合クエリを作成する一元化されたクエリインターフェイスで、さまざまなデータ操作 (リダクション、ファセット、集約、結合、フィルタ、グラフ、地理情報など) に使える様々な演算子セットが用意されています。
他の DBaaS 製品同様、MongoDB Atlas でもインデックスを利用してクエリ実行をスピードアップしています。デフォルトでは、プライマリインデックス (「_id」フィールドに対する一意的なインデックスなど) が作成され、ユーザーはドキュメント内の任意のフィールドに追加のセカンダリインデックス (複合、地理情報、テキストなど) を作成できます。しかし、この場合、クエリ最適化のためのインデックスの作成と管理に DataOps チームが多大な労力を費やす必要があります。例えば、インデックス (単一フィールドや複合など) を定義するには、ユーザーがすべてのデータアクセスパターンと、クエリにおいて MongoDB がインデックスの論理積をどう使用するのかを理解している必要があります。MarkLogic データハブサービスでは、ビルトインの検索機能とユニバーサルインデックスによりシンプルかつ効率的にインデックスを管理できます。
また、MongoDB Atlas のテキスト検索機能では、ハイパフォーマンスな検索アプリケーションの構築に制約があります (関連度順に表示できないなど)。この制約を克服するために、MongoDB は Atlas Search (Apache Lucene がベース) を別サービスとしてリリースしました。このサービスは aggregation パイプライン演算子を使用して高度な検索機能を実現しています。しかし、MarkLogic データハブサービスと異なり、Atlas Search のインデックスは結果整合性しか満たしていません。そのため、Atlas Search では単一のドキュメントトランザクションでも「リードアフターライト」の整合性がありません。また、自動インデックス付けが行われず、あらゆる種類のデータにアクセスできるわけでもありません。
また、MongoDB Atlas は業界標準のクエリ言語 (SQL など) をサポートしておらず、ドキュメントのクエリに JSON シンタックスを使用します。
マルチ構造データをさまざまな角度 (「レンズ」) から確認できる機能は、分断データの統合には欠かせません。MarkLogic データハブサービスでは、SQL 分析、セマンティックグラフクエリ、ドキュメント検索を実行できるだけでなく、Optic API でこれらを組みわせることでさまざまなユースケースとユーザータイプに対応できます。また、すべてのインデックスが一元化されたプラットフォームの一部として最適化されているため、一貫性のあるパフォーマンスと安全性が提供されます。
料金設定：予測可能な低コスト vs 制約があって高コスト
MarkLogic データハブサービスは、クラウドクレジットに基づくコンサンプションベースの課金です。随時支払うことも、事前にクレジットを一括購入して節約することもできます。すべての費用が含まれた価格設定 (ハードウェア、ソフトウェア、運用、プロビジョニング、年中無休のサポート) のため、シンプルです。演算処理 (「compute」)、ストレージ、帯域幅に対する支払いとなります。また、時点によって異なる (予想できない) ワークロードによる需要のスパイクがあっても、コストが予測可能です。
未使用の演算処理クレジットを貯めて、これを需要が急増したときのバースト (または演算処理の自動拡張) に追加料金なしで使用できます (未使用クレジットの最大12倍まで)。これによって大幅なコスト削減が可能になり、ピーク時の使用量に合わせてプロビジョニングする必要がなくなります。また、需要急増による自動拡張を原因とする高額な請求を回避できます。料金設定の詳細については、データハブサービスのページをご覧ください。
MongoDB Atlas でもコンサンプションベースの料金設定となっていますが、全体的なコストが高くなっています。また、需要急増に対応するための無料の自動バーストはありません。
MongoDB Atlas の料金設定には制約があり、より高額です。LDAP 統合、年中無休のサポート、BI コネクタ、Stitch (Atlas のアプリケーションサービス) などにはアドオンを購入する必要があります。一方、MarkLogic データハブサービスの料金にはすべての費用が含まれており、予測も可能です。
透明性のある予測可能な料金は、クラウドサービスを検討する際の重要な考慮事項となります。MarkLogic データハブサービスでは、データ統合ワークロード/業務用/分析用のアプリケーションを実行しながら、予測可能な低コストで高いパフォーマンスと信頼性を実現します。
MarkLogic データハブサービスの一般的な使用例
MarkLogic データハブサービスは、大規模なデータセットと複数のデータモデルがある複雑なデータ統合に特に適しています。データが急激に変化したり、ビジネスニーズが短時間で進化していく場合は、マルチモデルデータベースを備えたデータハブの方が適しています。
データハブのさまざまなユースケースの中から、以下の3つをご紹介します。
- 様々な360° ビュー (全体像) – ERP データを統合し、顧客、従業員、資産などの「360° ビュー (全体像)」を構築
- 検索と発見 - リッチなナレッジのアプリケーション (通常はセマンティックを使用) で情報を共有
- 運用分析 – リアルタイムでの不正検知や、公園や製造施設の安全のリアルタイム監視
業界固有のユースケースもあります (金融取引データの統合や、製造業における BOM の構築など)。
ここからは、MongoDB ではなく MarkLogic を選択した組織の例をいくつかご紹介します。
- 世界最大手の保険会社 – 複数の業務部門を対象とした、費用対効果に優れた「ドキュメント管理-as-a-Service」プラットフォームを構築しました。POC では、MarkLogic、MongoDB、Couchbase、Cassandra、DynamoDB が使われました。POC の目的は5億件のドキュメントを扱うソフトウェアのベンチマークでした。最終的に、数百万のドキュメントおよびユーザーに対応できる拡張性を備えた MarkLogic が選ばれました。
- 数十億ドル規模の金融サービス企業 – 証券の処理と清算には MongoDB ではなく MarkLogic が選ばれました。MongoDB は機密性の高い取引データを扱うのに十分なセキュリティがないと判断されたためです。
- 大手の州保健福祉サービスプロバイダー – メディケイドの受給資格の確認と申請処理の精度とスピードを改善するために、MongoDB ではなく MarkLogic が選ばれました。MongoDB は、メインフレーム、アプリケーション、外部データをまとめたリアルタイムの全体像を提供できなかったためです。
- 米軍 – 軍事調査能力を改善するため、データの管理/共有プラットフォームを新しく構築しました。MongoDB は拡張時にパフォーマンスが落ちたため、MongoDB ではなく MarkLogic が選ばれました。
MongoDB Atlas の方が適しているケース
MongoDB Atlas はオープンソースデータベースとして開発者の人気を集めています。トランザクションが要求されない新規アプリケーション用に、クラウドニュートラルで使い勝手の良いドキュメントデータベースを探している場合には、これは良い選択肢となります。
一方、データを統合し、ミッションクリティカルなユースケースの促進を検討している企業にとっては、スケーラブルなマルチモデルデータベースを擁する MarkLogic データハブサービスの方が適しています。
次のステップ
MarkLogic データハブサービス (DHS) の詳細をご覧いただき、製品デモにご登録ください。
MarkLogic データハブサービスのドキュメントを読む
