マルチモデルデータベースのメリット
マルチモデルデータベースは、多種多様なデータの管理に関する課題を解決するための洗練されたソリューションです。
アプリケーション側で複数のデータベースモデルを統合するポリグロットパーシステンスと違い、マルチモデルデータベースは、統合された単一のバックエンドを使用して複数のデータモデルをネイティブにサポートします。ポリグロットパーシステンスではデータがサイロ化され、複数のインターフェイスによって統合ワークフローが複雑になるのに対して、マルチモデルデータベースではデータ統合が促進され、一元化されたインターフェイスによってデータの一貫性、セキュリティ、アクセスが保たれます。
ポリグロットパーシステンスの場合、エンドユーザーが使用できるようにデータの一貫性とセキュリティを確保するには、アプリケーションで複数のサービスをオーケストレーションする必要があります。これに対して、マルチモデルデータベースでデータモデルを適切に組み合わせてエンティティ（患者の医療記録など）をモデリングするとデータアーキテクチャがどれほどシンプルになるかは、ご想像のとおりです。
マルチモデルを最大限に活用する
MarkLogicサーバー
MarkLogicサーバーは、ドキュメント、セマンティックグラフ、地理情報、リレーショナルの各モデルのメリットを拡張性の高いハイパフォーマンスの業務データベースに統合したマルチモデルデータベースです。JSON、XML、テキスト、RDFトリプル、地理情報、バイナリ（PDF、画像、動画など）をネイティブに格納でき、統合された検索とクエリのインターフェイスを備えています。このため、データの一貫性を損なわずに、ユースケースに適したデータモデルを選んで組み合わせることができる柔軟性があります。例えば、ビジネスエンティティ（お客様など）について信頼できる全体像を構築し、複数のユースケース（ロイヤルティプログラム、パーソナライゼーションなど）に使用することができます。
この図では、Jenという名前の個人に関するドキュメントと、Jenに関するファクトと関係性を記述したいくつかのトリプルを示しています。Jenはリレーショナルビューでも表現できます。
マルチモデルによるデータ統合の改善
マルチモデルデータベースは、複数のデータモデルを格納してクエリを実行できるため、さまざまなサイロからデータを統合してこれまでにない柔軟性、業務効率、DevOpsのアジャイル性を実現できます。例えば、リレーショナルデータベースの場合、合意された1つの上位スキーマを事前に定義しなければならず、ビジネスニーズの進化に合わせて、維持が困難で面倒なETLプロセスによってすべてのソースデータをマッピングする必要があります。これに対して、マルチモデルデータベースはスキーマに依存しないため、複数のスキーマ（またはデータモデル）を共存させることができ、スキーマを柔軟に進化させて新しいビジネスニーズに速やかに対応できます。
マルチモデルデータベースであるMarkLogicサーバーは、あらゆるデータをそのままの形で簡単に読み込むことができ、リネージ、出自、その他のメタデータを維持したまま変更を素早く繰り返せる柔軟性があります。必要に応じてデータソースを追加し、構造化データと非構造化データを読み込み、既存のアプリケーションに影響を与えたりソースデータを読み込み直したりすることなく、スキーマを変更して新しいユースケースに対応できます。このため、MarkLogicサーバーは、MarkLogicデータハブプラットフォームにおいて構造が複数存在するデータを統合、キュレーション、管理するための基盤となっています。あらゆるソース（Oracle、SQL Server、Teradata、Hadoopなど）のあらゆるタイプ（IoT、クリックストリーム、メインフレーム、ERPなど）のデータを統合できます。
マルチモデルデータベースの主な機能
マルチモデルデータベースは、複数のデータモデル、インデックス、プログラミング言語をサポートして複数のユースケースを実現しながら、データセキュリティ、ガバナンス、一貫性に関して統合されたモデルを提供します。MarkLogicサーバーにより、次のようなことが実現します。
ドキュメントモデル – 柔軟でユーザー重視
ドキュメントデータベースモデルは、最も柔軟なNoSQLデータモデルであり、最も一般的なモデルです。ドキュメントは多様で複雑な階層型データの処理に適しています。人が読んで理解でき、データの概念またはビジネスモデルをほぼそのまま表現できます。またリレーショナルデータベースのインピーダンスミスマッチ問題を回避できます。
MarkLogicサーバーでは、ビジネスエンティティを表すJavaオブジェクトや、従来の意味での「ドキュメント」（Microsoft Word文書やPDFなど）からの一般的なテキストなど、JSONやXMLドキュメントとしてすべて自然に格納し、強い一貫性を維持できます。
ドキュメントに安全にアクセスして共有できるよう、MarkLogicサーバーにはビルトインの検索エンジン、ドキュメントおよび要素レベルのセキュリティ制御、リダクションポリシーなどが用意されています。検索エンジンが読み込み時の全文検索に備えてドキュメントを自動的にインデックス付けします。追加インデックス（レンジインデックス、地理情報インデックスなど）の定義や関連度順のカスタマイズなどの柔軟性もあります。このように様々な標準機能（ファセット、スニペットなど）により、高度な検索アプリケーションを迅速に構築できます。
まとめると、ドキュメントデータベースモデルには主に次のようなメリットがあります。
- 短時間で開発
- 非スキーマ依存
- 「非正規化された」データ
- すべての属性を活用
- あらゆるものをコンテキスト内でクエリ
- データ統合に最適
セマンテックグラフデータベースモデルで関係性に対応
ドキュメントはビジネスエンティティの格納に適していますが、エンティティの関係性については、もう1つの一般的なNoSQLモデル、セマンテックグラフデータベースモデルが最適です。このモデルは、人、顧客、プロバイダなど、興味対象のエンティティの関係性を格納して管理できるように設計されています。
さらに、MarkLogicサーバーは、セマンティックグラフデータモデルをビルトインのRDFトリプルストアとして提供しており、セマンティックデータを格納して管理できます。MarkLogicでは、この機能をMarkLogicセマンティックと呼んでいます。セマンティックでは、JSONおよびXMLドキュメントを最適な方法で関連付け、強化することで、ドキュメントモデルを強化します。これにより、データ統合を促進し、強力なクエリを実行して関係性を発見したり推論を実行したりできます。
セマンティックは、メタデータを格納することでデータのコンテキストも提供します（オントロジーなど）。例えば、部品に関する情報が格納されたデータベースを考えてみましょう。ある部品のサイズは「42」となっていますが、このコンテキスト情報はどこにあるのでしょうか？「42」の単位は何でしょうか？測定時の許容誤差はどのくらいでしょうか？誰がいつ測定したのでしょうか？こうしたコンテキスト情報がセマンテックデータであり、MarkLogicサーバーにRDFトリプルとして格納できます。
ドキュメントモデルと同様に、MarkLogicサーバーのビルトインの検索エンジンは、SPARQLクエリを使用してセマンティック検索を高速実行するためにRDFトリプルをインデックス付けします。セマンティック検索とドキュメント検索を組み合わせて複雑なクエリを簡単に作成し、インサイトを発見できます。
地理情報検索機能
ドキュメントデータモデルには、地理情報データを格納できる柔軟性があります。MarkLogicサーバーでは、関心のある地点、交差経路、地域などの地理情報をネイティブに格納、管理、検索できます。これにより、その他全てのデータ（エンティティ、関係性など）の「位置」に関する質問の答えが得られます。
MarkLogicサーバーのビルトインの検索エンジンは、地理情報データのインデックス付けにより、場所に基づく検索クエリと地理情報アプリケーション用のアラートが可能です。地理情報を利用して、強力な場所に基づく検索アプリケーションを実装しているお客様の詳細をご覧ください。
構造化されたデータのリレーショナルビュー
リレーショナルデータモデルが便利なのは、理由があります。表形式に構造化されたデータビューは、標準のSQLでクエリを実行できるので、役に立つこともあります。MarkLogicがあれば、開発者は安心です。
MarkLogicサーバーは標準のSQLをサポートしており、データの上にリレーショナルビューを作成し、データのセキュリティに妥協することなくSQL分析を実行できます。基盤となるデータは変更されず、MarkLogicサーバーでは元の形式のまま利用できます。
このようなレベルのSQLサポートを可能にする基盤技術は、MarkLogicサーバー独自のものです。この技術をTDE（Template Driven Extraction）と呼び、データ（またはエンティティ）のリレーショナルレンズを定義できるため、標準のSQLを使用してクエリできます。したがって、使い慣れたBIツールで業務分析を行えます。
統合インデックス
マルチモデルデータベースには統合検索インターフェイスがあり、統合されたインデックスを使用して複数のデータモデルに対してクエリを実行できます。通常は、データ型ごとに特定のインデックスを選択して管理しなければなりません。これに対し、MarkLogicサーバーは、データが読み込まれるとすぐに高速のデータアクセスを実現する統合インデックススイートを備えています。マルチモデルデータベースはGoogleのように機能します。Googleでは、webページを特定のフォーマットに適合させる必要はありません。ページにインデックスを付けて、統合検索インターフェイスからアクセス可能にするだけです。
MarkLogicサーバーはビルトインの検索エンジンにより、すべてのデータ型をインデックス付けして卓越した検索パフォーマンスを実現します。したがって、組み合わせ可能な単一のクエリで、複数のデータモデルのデータを迅速に検索できます。例えば、セマンティッククエリと検索クエリを組み合わせて、保険に加入していない慢性疾患の患者を見つけることができます。
構成可能なクエリ
マルチモデルデータベースには業界標準のクエリ言語とAPIが備わっているため、サポートされるすべてのデータモデルのデータを柔軟に格納してアクセス可能です。MarkLogicサーバーにより、ユーザーは検索、SQL、SPARQL、REST APIを使用してデータのクエリを実行できます。また、JavaScript、Node、Java、XQueryなど、複数のプログラミング言語もサポートしています。
真のマルチモデルデータベースであるMarkLogicサーバーは、マルチモデルデータアクセス用の統合されたクエリインターフェイスとしてオプティックAPIも備えています。あらゆるデータモデルのデータに柔軟かつ簡単にアクセスできます。ドキュメント、リレーショナルビュー、セマンティックグラフを対象として、組み合わせ可能な単一のクエリを作成できます（どのような組み合わせも可能です）。例えば、オプティックAPIを使用して、ドキュメントの検索やフィルタリング、リレーショナルな操作（結合や集計など）、出力用のドキュメントの抽出（または作成）などを実行できます。別のマルチモデルデータベースでも同じことを試してみてください。
統合プラットフォーム
マルチモデルデータベースは、データモデリングの柔軟性と統合されたクエリインターフェイスに加え、データセキュリティ、ガバナンス、トランザクション処理に単一のモデルをとっています。統合されたデータプラットフォームとして、開発者の生産性と運用効率を向上します。
真のマルチモデルデータベースであるMarkLogicサーバーは、データセキュリティ、ガバナンス、一貫性に関して統合されたモデルを提供します。シェアードナッシングアーキテクチャにより、拡張性と可用性を実現し、開発、テスト、アップグレード、バックアップ、リカバリなどの運用フットプリントを低減します。
マルチモデルの偽物に騙されないように
マルチモデルの偽物には気をつける必要があります。事実、多くのベンダーは、マルチモデルデータベースと偽って宣伝しています。市場に出回るマルチモデルの偽物には次の2種類があります。
- 1つ目のカテゴリに入るのは、統合されたストレージとクエリのレイヤーがない、複数の製品を結合しただけの製品です。基盤がこのように継ぎはぎの状態では、複合検索ができず、インデックス管理に細心の注意を払う必要があり、往々にしてデータの一貫性に欠け、予測可能な形で拡張することができません
- 2つ目のカテゴリに入るのは、マルチモデル化したと主張するリレーショナルデータベースです。真のマルチモデルデータベースの普及が進む中で、このような製品がトレンドになっており、Oracleさえもマルチモデルデータベースを主張するようになっています。
ところが、これらのリレーショナルデータベースの実態はいまだにリレーショナルで、真のマルチモデルではありません。Oracleのドキュメントによると、Oracle 19cはJSONをネイティブに格納しません（「Oracleデータベースでは、JSONデータは一般的なSQLデータ型であるVARCHAR2、CLOB、BLOBを使用して格納されます（抽象的なSQLデータ型XMLTypeを使用して格納されるXMLデータとは異なります）」）。その結果、値を取得するためには、JSONドキュメント全体をトラバースしてデータを見つける必要があります。これにはかなり時間がかかります。パフォーマンスを改善するために、Oracleは2つのアプローチを推奨しています。1つめは、マテリアライズドビューにデータを抽出し、値を別の表にプッシュする方法です（シュレッディング）。もう1つの方法はJSONサーチインデックスの使用ですが、この場合、ACIDコンプライアンスが維持されず、トリガーされたときしか更新されません。MarkLogicとOracleの比較の詳細については、こちらをクリックしてください。マルチモデルを主張するその他のリレーショナルデータベースも、NoSQLデータ型をネイティブに格納できないという問題があります。
一般に、偽のマルチモデルでは、マルチモデル的な作業が困難であったりやりにくかったりします。ドキュメントに対するクエリのような単純な問題だけでなく、トリプルによるドキュメント同士のリンクや、XMLとJSONに対して同時にクエリするといった高度な機能を実行できません。MarkLogicサーバーではこれらを簡単に実行できます。MarkLogicとその他のデータ管理ソリューションとの比較の詳細については、こちらをクリックしてください。