ビジネスは変化しており、データも変化しています。変化し続けるデータをすべて1つのリレーショナルスキーマにモデリングすることが早急に求められており、すべてのデータを1つの統合プラットフォームで処理できるマルチモデルデータベースが必要です。MarkLogicのお客様の言葉を借りれば、MarkLogicの柔軟なデータモデルにより、リレーショナル技術の足枷から解放されます。

根本的には、MarkLogicはマルチモデルデータベースです。MarkLogicでは、JSON、XML、RDF、位置情報データ、ラージバイナリ(PDF、画像、動画など)をネイティブに格納できます。このアプローチを採用することで、すべてのデータを取り込み、後で簡単に変更できます。構造化データ、非構造化データ(またはメタデータ)に関係なく、すべてのデータを「そのまま」ロードします。面倒なETLプロセスは不要です。別のデータソースを追加したり、スキーマを後で変更したりするのも、自由です。柔軟で高速、反復性に優れています。

データシート

どのソースからでもすべてのデータをロード

  • 構造化データ
  • 非構造化データ
  • メタデータ
  • 規制データ
  • ERPシステム
  • メインフレームデータ
  • 地理空間情報データ
  • IoT、クリックストリーム
  • その他
  • Oracle
  • IBM DB2
  • SQL Server
  • Sybase
  • Teradata
  • Netsuite
  • MS Excel
  • NoSQL
  • Hadoop
  • ファイルシステム
  • その他

ドキュメントモデル – 柔軟でユーザー重視

ドキュメントデータベースは、最も柔軟なNoSQLデータベースであり、一番人気があります。ドキュメントは多様で複雑なデータの処理に適しています。人間が読んで理解でき、データの概念またはビジネスモデルをほぼそのまま表現できます。またリレーショナルデータベースのインピーダンスミスマッチ問題を回避できます。

MarkLogicでは、ビジネスエンティティを表すJavaオブジェクトや、従来の意味での「ドキュメント」(Microsoft Word文書やPDFなど)からのフリーテキストなど、JSONやXMLドキュメントとしてすべて自然に格納できます。
  • 短時間で開発
  • 非スキーマ依存
  • 人間にとって自然
  • 「非正規化された」データ 
  • 検索とクエリ機能が向上
  • すべての属性を活用 
  • あらゆるものをコンテキスト内でクエリ
  • データ統合に最適

病院での外科手術の手順を表すJSONドキュメントの例:

{ “病院”: “Johns Hopkins”,
  “手術の種類”: “心臓移植”,
  “執刀医”: “Dorothy Oz”,
  “手術番号”: 13,
  “drugsAdministered”: [
    { “薬の名前”: “Minicillan”,
      “製薬会社”: “Drugs R Us”,
      “服用量”: 200, “doseUOM”: “mg” },
    { “薬の名前”: “Maxicillan”,
      “製薬会社”: “Canada4Less”,
      “服用量”: 400, “doseUOM”: “mg” },
    { “薬の名前”: “Minicillan”,
      “製薬会社”: “Drugs USA”,
      “服用量”: 150, “doseUOM”: “mg” }

ビルトイングラフデータベースで関係性に対応

ドキュメントはエンティティの格納に適していますが、データの関係性については、グラフデータベースが最適です。グラフデータベースは、人、顧客、プロバイダなどの関係性を格納して管理できるように設計されています。

MarkLogicは、セマンティックデータを保管して管理するためのビルトインのRDFトリプルストア(グラフデータベースの一種)を備えています。MarkLogicでは、この機能をMarkLogicセマンティックと呼んでいます。セマンティックでは、MarkLogicに格納されたJSONおよびXMLドキュメントを、最適な方法で関連付け、強化することで、ドキュメントモデルを強化します。これは、データ統合と強力なクエリを実現するうえで重要です。

セマンティックは、データのコンテクストも提供します。例えば、部品に関する情報が格納されたデータベースを考えてみましょう。ある部品のサイズは「42」となっていますが、このコンテクスト情報はどこにあるのでしょうか?「42」の単位は何でしょうか?誤差はどのくらいでしょうか?誰がいつ測定したのでしょうか?誰がこのデータを参照できるのでしょうか?こうしたコンテクスト情報がデータのセマンティックです。

詳細はこちら

それでも、構造化されたデータのリレーショナルビューが必要ですか?

構造化された表形式のデータリレーショナルビューは、標準のSQLでクエリを実行できるので、役に立つこともあります。MarkLogicがあれば、開発者は安心です。

MarkLogicでは標準のSQLをサポートしており、基盤となるデータは変更されず、MarkLogicではドキュメントのままです。ただしデータのリレーショナルビューを作成して、リレーショナルな表形式でドキュメントを表示することもできます。

このようなレベルのSQLサポートを可能にする基盤技術は、MarkLogic独自のものです。この技術をTDE(Template Driven Extraction)と呼び、ドキュメントデータのリレーショナルレンズを定義できるため、標準のSQLを使用してデータの一部をクエリできます。

新しいOptic APIを使用して、リレーショナルビューをクエリすることもできます。Optic APIは、ドキュメント、リレーショナルビュー、グラフデータ(またはそれらの組み合わせ)をクエリするための統合クエリインターフェイスです。Optic APIは、ドキュメントの結合や集約を実行することも可能です。別のドキュメントデータベースでも可能か試してみてください。

マルチモデルアプローチで最適なデータ統合を実現

MarkLogicは、スキーマがないのではなく、スキーマ非依存です。スキーマ非依存とは、スキーマを変更できることであり、複数のスキーマを同じデータベースに共存できることを意味します。この機能では、リレーショナルと異なり、スキーマに関する統一した基準にすべてのデータをマッピングする必要がないため、データを簡単で高速に統合できます。さらに、MarkLogicの強力なインデックスを使用することで、JavaScript、XQuery、SQL、SPARQLなど、任意の言語を使って全データを対象とした検索とクエリを実行できます。

  • ソースデータをそのまま読み込み、検索できる
  • リネージ、出自、その他のメタデータを保持できる
  • 必要なものだけをハーモナイズできる
  • 再読み込みせずにモデルを後から更新できる
  • 新しいスキーマが既存のデータ/アプリケーションに影響しない

リソースをすべての人に

ビジネス:マトリクスから脱却する準備はできていますか?

リレーショナルを使った従来のアプローチよりも、データ統合のマルチモデルアプローチが優れている理由を知りたくないですか?これまで不可能だと思っていたこと - マトリクスから脱却し、マシンの束縛から自由になる方法について、MarkLogicのエンジニアリング担当SVPのDavid Gorbetが説明します。

アーキテクト:マルチモデルデータベースの技術的な優位性

無料のO’Reilly eBook『Building on Multi-Model Databases』を読み、複数のスキーマを単一のプラットフォームで管理する方法について理解しましょう。マルチモデルデータベースにより、複雑さやリスクがどのように軽減できるか、また価値創出までの時間をどのように短縮するのか、その実例を紹介しています。

O’Reilly eBookをダウンロードする

開発者:16分でわかるマルチモデルデータベース

このショートチュートリアルでは、エンベロープパターンや継続的な機能強化など、ドキュメントとトリプルを使用したデータモデリングのベストプラクティスの概要について説明します。

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

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

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