MLTV now live! New videos, new content hub.

マルチモデルデータベースの表現

マルチモデルデータベースは、異機種環境データの管理に関する課題を解決できる洗練されたソリューションです。アプリケーションで複数のデータベースモデルを統合するポリグロットパーシステンスと違い、マルチモデルデータベースは、統合された単一のバックエンドを使用して複数のデータモデルをネイティブの形式でそのままサポートします。ポリグロットパーシステンスではデータがサイロ化され、複数のインターフェイスを使用するために複雑な統合ワークフローが必要になるのに対して、マルチモデルデータベースではデータの統合が促進され、統一されたインターフェイスによってデータの一貫性、セキュリティ、アクセスが保たれます。

ポリグロットパーシステンスの場合、エンドユーザーが使用できるようにデータの一貫性とセキュリティを確保するには、アプリケーションで複数のサービスをオーケストレーションする必要があります。これに対して、マルチモデルデータベースでデータモデルを適切に組み合わせてエンティティ(患者の医療記録など)をモデリングするとデータアーキテクチャがどれほどシンプルになるかは、ご想像のとおりです。

マルチモデルのMarkLogicサーバーをさらに活用

MarkLogicサーバーは、ドキュメント、セマンティックグラフ、地理情報、リレーショナルの各モデルのメリットを拡張性の高いハイパフォーマンスの業務データベースに統合したマルチモデルデータベースです。JSON、XML、テキスト、RDFトリプル、地理情報、バイナリ(PDF、画像、動画など)をネイティブに格納でき、統合された検索とクエリのインターフェイスを備えています。このため、データの一貫性を損なわずに、ユースケースに適したデータモデルを選んで組み合わせることができる柔軟性があります。例えば、ビジネスエンティティ(お客様など)について信頼できる全体像を構築し、複数のユースケース(ロイヤルティプログラム、パーソナライゼーションなど)に使用することができます。

1人の人物を記述する3つの方法:ドキュメント、RDFトリプル、リレーショナルビュー
図には、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をネイティブに格納しません(「In Oracle Database, JSON data is stored using the common SQL data type VARCHAR2, CLOB, and BLOB (unlike XML data, which is stored using abstract SQL data type XMLType).(Oracleデータベースで、JSONデータは一般的なSQLデータ型VARCHAR2、CLOB、BLOBを使用して格納されます(SQL抽象データ型XMLTypeを使用して格納されるXMLデータとは異なります)」)。その結果、値を取得するためには、JSONドキュメント全体をトラバースしてデータを見つける必要があります。これは時間がかかりすぎます。パフォーマンス改善のために、Oracleは2つのアプローチを推奨しています。1つ目が、マテリアライズドビューにデータを抽出し、値を別の表にプッシュする方法です(シュレッディング)。もう1つの方法は、ACIDコンプライアンスが維持されないJSON検索索引で、定期的にトリガーされたときしか更新されません。マルチモデル化を主張するその他のリレーショナルデータベースも同様に、NoSQLデータ型をネイティブに格納できないという問題に直面しています。

一般的に、マルチモデルの偽物では、マルチモデルのワークロードは困難であるか、扱いにくいか、その両方です。ドキュメントに対するクエリのような単純な処理ができないほか、トリプルによるドキュメント同士のリンクや、XMLとJSONの両方に対するクエリなどの、より高度な機能を実行できません。MarkLogicサーバーは、どれも簡単に実行できます。

リソース

ホワイトペーパー

データモデリングの新しい考え方

アーキテクト向けのeBook

マルチモデルデータベースの技術的な優位性

開発者向けトレーニング

16分でわかるマルチモデルデータベース

エンタープライズ向けに、豊富な機能と開発を支援

当ウェブサイトではクッキーを使用しています。

当Webサイトを継続利用することにより、お客様はMarkLogicのプライバシーステートメントに従ってクッキーの使用に同意するものとします。