現代の情報システムは非常に複雑です。 とりわけ、その複雑さは、そこで処理されるデータの複雑さによるものです。 データの複雑さは、使用されるデータ モデルの多様性に依存することがよくあります。 したがって、たとえば、データが「大きく」なると、その量 (「ボリューム」) だけでなく、その多様性 (「多様性」) も問題となる特性の XNUMX つになります。

推論に欠陥がまだ見つからない場合は、読み続けてください。

ページ内容

多言語永続性
マルチモデル
リレーショナルモデルに基づくマルチモデルDBMS
     MS SQL Serverのドキュメントモデル
     MS SQL Serverのグラフモデル
ドキュメントモデルに基づくマルチモデルDBMS
     MarkLogicのリレーショナルモデル
     MarkLogicのグラフモデル
「メインモデルを持たない」マルチモデルDBMS
     アランゴDB
     OrientDB
     アズール コスモスDB
グラフモデルに基づくマルチモデルDBMS?
まとめ
Опрос

多言語永続性

上記のことから、場合によっては XNUMX つのシステムのフレームワーク内であっても、データを保存し、その処理に関するさまざまな問題を解決するために、それぞれが独自のデータ モデルをサポートする複数の異なる DBMS を使用する必要があるという事実が生じます。 M.ファウラーの軽い手で、 作者 数々の有名な本とその中の一冊 共著者 この状況をアジャイルマニフェストと呼びます。 マルチバリアントストレージ (「多言語永続性」)。

Fowler 氏は、電子商取引の分野でフル機能の高負荷アプリケーションでデータ ストレージを整理する次の例も示しています。

もちろん、この例は多少誇張されていますが、対応する目的に応じて XNUMX つまたは別の DBMS を選択することを支持する考慮事項がいくつかあります。たとえば、次のとおりです。 ここで.

このような動物園で使用人になるのは簡単ではないことは明らかです。

• データ ストレージを実行するコードの量は、使用される DBMS の数に比例して増加します。 データを同期するコードの量は、この数値の XNUMX 乗に比例しない場合でも問題ありません。
• 使用する DBMS の数の倍数に応じて、使用する各 DBMS のエンタープライズ特性 (スケーラビリティ、フォールト トレランス、高可用性) を提供するコストが増加します。
• ストレージ サブシステム全体のエンタープライズ特性、特にトランザクション性を保証することは不可能です。

動物園の園長の視点から見ると、すべては次のようになります。

• DBMS メーカーからのライセンスとテクニカル サポートのコストが倍増します。
• 人員過剰と納期の増加。
• データの不一致による直接的な経済的損失または罰金。

システムの総所有コスト (TCO) が大幅に増加しています。 「複数のストレージオプション」の状況から抜け出す方法はあるのでしょうか?

マルチモデル

「多変量ストレージ」という用語は 2011 年に使用され始めました。 このアプローチの問題点の認識と解決策の模索には数年かかり、2015 年までに、Gartner アナリストの口からその答えが定式化されました。

• 「からNoSQL DBMS のマーケット ガイド - 2015»：
  

  DBMS、そのアーキテクチャ、およびその使用方法の将来はマルチモデルです。

• 「からODBMS のマジック クアドラント - 2016»：
  

  主要なオペレーショナル DBMS は、単一プラットフォームの一部として複数のモデル (リレーショナルおよび非リレーショナル) を提供します。

今回はGartnerのアナリストの予想が正しかったようだ。 というページに行くと、 主な評価 DB-Engines 上の DBMS を見ると、次のことがわかります。оそのリーダーのほとんどは、特にマルチモデル DBMS として自らを位置づけています。 プライベート評価のページでも同様のことが見られます。

以下の表は、マルチモデルであると主張する各民間評価のリーダーである DBMS を示しています。 各 DBMS について、元のサポートされているモデル (かつては唯一のモデルでした) と、現在サポートされているモデルが表示されます。 また、自身を「元々はマルチモデル」として位置付けており、作成者によれば、初期継承モデルを持たない DBMS もリストされています。

DBMS	初期モデル	追加モデル
オラクル	関連した	グラフ、ドキュメント
MS SQL	関連した	グラフ、ドキュメント
PostgreSQL	関連した	グラフ*、ドキュメント
MarkLogic	ドキュメンタリー	グラフ、リレーショナル
MongoDBの	ドキュメンタリー	Key-Value、グラフ*
DataStax	ワイドカラム	ドキュメンタリー、グラフ
Redisの	キーと値	ドキュメンタリー、グラフ*
アランゴDB	-	グラフ、ドキュメント
OrientDB	-	グラフ、ドキュメント、リレーショナル
アズール コスモスDB	-	グラフ、ドキュメント、リレーショナル

テーブルへの注意

表内のアスタリスクは、予約が必要なステートメントを示しています。

• PostgreSQL DBMS はグラフ データ モデルをサポートしていませんが、この製品はグラフ データ モデルをサポートしています。 それに基づいて、AgensGraph など。
• MongoDB に関連して、クエリ言語におけるグラフ演算子の存在について話すのがより正確です ($lookup, $graphLookup）グラフ モデルのサポートよりも重要ですが、もちろん、それらの導入には、グラフ モデルをサポートする方向で物理ストレージ レベルでの最適化が必要でした。
• Redis に関して言えば、拡張機能を意味します。 Redisグラフ.

次に、各クラスについて、いくつかのモデルのサポートがこのクラスから DBMS にどのように実装されるかを示します。 リレーショナル、ドキュメント、グラフ モデルが最も重要であると考え、特定の DBMS の例を使用して、「欠けているもの」がどのように実装されるかを示します。

リレーショナルモデルに基づくマルチモデルDBMS

現在、主要な DBMS はリレーショナルであるため、RDBMS がマルチモデリングの方向への動きを示さなければ、Gartner の予測は真実であるとは考えられません。 そして彼らはデモンストレーションをします。 マルチモデル DBMS は何もうまくできないスイスナイフのようなものであるという考えは、Larry Ellison に直接当てられます。

ただし、著者は Microsoft SQL Server でのマルチモデリングの実装を好みます。その例については、ドキュメント モデルとグラフ モデルの RDBMS サポートについて説明します。

MS SQL Serverのドキュメントモデル

MS SQL Server がドキュメント モデルのサポートを実装する方法については、Habré に関する優れた記事が XNUMX つすでにありますが、ここでは簡単な再話と解説に限定します。

• SQL Server 2016 での JSON の操作
• SQL Server 2017 JSON

MS SQL Server でドキュメント モデルをサポートする方法は、リレーショナル DBMS では非常に一般的です。JSON ドキュメントは、通常のテキスト フィールドに格納されることが提案されています。 ドキュメント モデルのサポートは、この JSON を解析するための特別な演算子を提供することです。

• JSON_VALUE スカラー属性値を抽出するには、
• JSON_QUERY サブドキュメントを抽出します。

両方の演算子の XNUMX 番目の引数は、JSONPath のような構文の式です。

抽象的には、この方法で保存されたドキュメントは、タプルとは異なり、リレーショナル DBMS の「ファーストクラスのエンティティ」ではないと言えます。 具体的には、MS SQL Server には現在、JSON ドキュメントのフィールドにインデックスが存在しないため、これらのフィールドの値を使用してテーブルを結合したり、これらの値を使用してドキュメントを選択したりすることさえ困難になります。 ただし、そのようなフィールドに対して計算列を作成し、その列にインデックスを作成することは可能です。

さらに、MS SQL Server は、演算子を使用してテーブルの内容から JSON ドキュメントを簡単に構築する機能を提供します。 FOR JSON PATH - ある意味、これまでの従来のストレージとは逆の可能性。 RDBMS がどれほど高速であっても、このアプローチがドキュメント DBMS のイデオロギーと矛盾していることは明らかです。ドキュメント DBMS は基本的に、一般的なクエリに対する既成の回答を保存しており、開発の容易さの問題のみを解決できますが、速度の問題は解決できません。

最後に、MS SQL Server を使用すると、ドキュメント構築の逆の問題を解決できます。次を使用して JSON をテーブルに分解できます。 OPENJSON。 ドキュメントが完全に平らでない場合は、次の方法を使用する必要があります。 CROSS APPLY.

MS SQL Serverのグラフモデル

グラフ (LPG) モデルのサポートも Microsoft SQL Server に完全に実装されています 予想通り: ノードを格納し、グラフのエッジを格納するために特別なテーブルを使用することが提案されています。 このようなテーブルは式を使用して作成されます CREATE TABLE AS NODE и CREATE TABLE AS EDGE それぞれ。

最初のタイプのテーブルは、レコードを格納するための通常のテーブルに似ていますが、唯一の外部的な違いは、テーブルにシステム フィールドが含まれていることです。 $node_id — データベース内のグラフ ノードの一意の識別子。

同様に、XNUMX 番目のタイプのテーブルにはシステム フィールドがあります。 $from_id и $to_id、このようなテーブルのエントリは、ノード間の接続を明確に定義します。 各タイプの関係を保存するために別個のテーブルが使用されます。

これを例で説明してみましょう。 グラフデータを図のようなレイアウトにします。 次に、データベースに対応する構造を作成するには、次の DDL クエリを実行する必要があります。

CREATE TABLE Person (
  ID INTEGER NOT NULL,
  name VARCHAR(100)
) AS NODE;

CREATE TABLE Cafe (
  ID INTEGER NOT NULL, 
  name VARCHAR(100), 
) AS NODE;

CREATE TABLE likes (
  rating INTEGER
) AS EDGE;

CREATE TABLE friendOf
  AS EDGE;

ALTER TABLE likes
  ADD CONSTRAINT EC_LIKES CONNECTION (Person TO Cafe);

このようなテーブルの主な特徴は、テーブルに対するクエリで、Cypher のような構文でグラフ パターンを使用できることです (ただし、「*」などはまだサポートされていません）。 パフォーマンス測定に基づいて、これらのテーブルにデータが格納される方法は、通常のテーブルにデータが格納される方法とは異なり、そのようなグラフ クエリの実行に最適化されていると想定することもできます。

SELECT Cafe.name
  FROM Person, likes, Cafe
  WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
  AND Person.name = 'John';

さらに、このようなテーブルを操作するときにこれらのグラフ パターンを使用しないことは非常に困難です。通常の SQL クエリで同様の問題を解決するには、システムの「グラフ」ノード識別子を取得するために追加の努力が必要になるためです ($node_id, $from_id, $to_id; 同様の理由で、データを挿入するクエリは不必要に煩雑になるため、ここでは示していません)。

MS SQL Server におけるドキュメント モデルとグラフ モデルの実装の説明を要約すると、主に言語設計の観点から、あるモデルを別のモデルの上に重ねて実装することは成功しているようには見えないことに注意してください。 ある言語を別の言語で拡張する必要がありますが、言語は完全に「直交」ではなく、互換性ルールが非常に奇妙な場合があります。

ドキュメントモデルに基づくマルチモデルDBMS

このセクションでは、ドキュメント DBMS の中で最も人気のない MongoDB の例を使用して、ドキュメント DBMS でのマルチモデルの実装を説明したいと思います (前述したように、条件付きグラフ演算子しかありません) $lookup и $graphLookup、シャード化されたコレクションでは動作しません)、より成熟した「エンタープライズ」DBMS の例を使用します。 MarkLogic.

したがって、コレクションには次のタイプの XML ドキュメントのセットが含まれます (MarkLogic では JSON ドキュメントを保存することもできます)。

<Person INN="631803299804">
  <name>John</name>
  <surname>Smith</surname>
</Person>

MarkLogicのリレーショナルモデル

ドキュメントのコレクションのリレーショナル ビューは、次を使用して作成できます。 表示テンプレート (要素の内容 value 以下の例では、任意の XPath を使用できます)。

<template >
  <context>/Person</context>
  <rows>
    <row>
      <view-name>Person</view-name>
      <columns>
        <column>
          <name>SSN</name>
          <value>@SSN</value>
          <type>string</type>
        </column>
        <column>
          <name>name</name>
          <value>name</value>
        </column>
        <column>
          <name>surname</name>
          <value>surname</value>
        </column>
      </columns>
    </row>
  <rows>
</template>

作成されたビューは、SQL クエリ (たとえば、ODBC 経由) でアドレス指定できます。

SELECT name, surname FROM Person WHERE name="John"

残念ながら、表示テンプレートによって作成されたリレーショナル ビューは読み取り専用です。 リクエストを処理する際、MarkLogic は次の使用を試みます。 ドキュメントインデックス。 以前、MarkLogic のリレーショナル ビューは完全に制限されていました。 インデックスベース 書き込み可能ですが、現在は非推奨とみなされています。

MarkLogicのグラフモデル

グラフ (RDF) モデルのサポートにより、すべてがほぼ同じになります。 またまた助けを借りて 表示テンプレート 上記の例から、ドキュメントのコレクションの RDF 表現を作成できます。

<template >
  <context>/Person</context>
    <vars>
      <var>
        <name>PREFIX</name>
        <val>"http://example.org/example#"</val>
      </var>
    </vars>
  <triples>
    <triple>
      <subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
      <predicate><value>sem:iri( $PREFIX || surname )</value></predicate>
      <object><value>xs:string( surname )</value></object>
    </triple>
    <triple>
      <subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
      <predicate><value>sem:iri( $PREFIX || name )</value></predicate>
      <object><value>xs:string( name )</value></object>
    </triple>
  </triples>
  </template>

結果として得られる RDF グラフは、SPARQL クエリを使用して処理できます。

PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
  :631803299804 :name ?name ; :surname ?surname .
}

リレーショナル モデルとは異なり、MarkLogic は他の XNUMX つの方法でグラフ モデルをサポートします。

1. DBMS は、RDF データの本格的な別個のストレージになります (その中のトリプレットは と呼ばれます)。 マネージド 上記のものとは対照的に 抜かれた).
2. 特別なシリアル化の RDF は、XML または JSON ドキュメントに簡単に挿入できます (その後、トリプレットが呼び出されます) 管理されていない）。 これはおそらくメカニズムの代替手段です idref 等

MarkLogic で物事が「実際に」どのように機能するかについての良いアイデアは、次のとおりです。 光APIこの意味では、これは低レベルですが、その目的はむしろ逆で、使用されるデータ モデルから抽象化を試み、異なるモデルのデータ、トランザクション性などの一貫した作業を確保することです。

「メインモデルを持たない」マルチモデルDBMS

市場には、継承されたメイン モデルを持たず、当初はマルチモデルとして位置付けられている DBMS もあります。 これらには以下が含まれます アランゴDB, OrientDB (2018年より開発会社はSAPに所属) コスモスDB (Microsoft Azure クラウド プラットフォームの一部としてのサービス)。

実際、ArangoDB と OrientDB には「コア」モデルがあります。 どちらの場合も、これらは独自のデータ モデルであり、ドキュメント XNUMX を一般化したものです。 一般化は主に、グラフとリレーショナルの性質のクエリを実行できるようにすることを目的としています。

これらのモデルは、指定された DBMS で使用できる唯一のモデルであり、独自のクエリ言語はそれらと連携するように設計されています。 もちろん、そのようなモデルや DBMS は有望ですが、標準モデルや言語との互換性がないため、これらの DBMS をレガシー システムで使用すること、つまりそこで既に使用されている DBMS を置き換えることは不可能になります。

Habré には、ArangoDB と OrientDB に関する素晴らしい記事がすでにありました。 NoSQL データベースでの JOIN.

アランゴDB

ArangoDB はグラフ データ モデルのサポートを主張しています。

ArangoDB のグラフのノードは通常のドキュメントであり、エッジは通常のシステム フィールドとともに (_key, _id, _rev) システムフィールド _from и _to。 ドキュメント DBMS 内のドキュメントは、伝統的にコレクションに結合されます。 エッジを表すドキュメントのコレクションは、ArangoDB ではエッジ コレクションと呼ばれます。 ちなみに、エッジコレクションドキュメントもドキュメントなので、ArangoDBのエッジもノードとして機能します。

初期データ

コレクションをしましょう persons、ドキュメントは次のようになります。

[
  {
    "_id"  : "people/alice" ,
    "_key" : "alice" ,
    "name" : "Алиса"
  },
  {
    "_id"  : "people/bob" ,
    "_key" : "bob" ,
    "name" : "Боб"  
  }
]

コレクションもさせてください cafes:

[
  {
    "_id" : "cafes/jd" ,
    "_key" : "jd" ,
    "name" : "Джон Донн"  
  },
  {
    "_id" : "cafes/jj" ,
    "_key" : "jj" ,
    "name" : "Жан-Жак"
  }
]

それからコレクション likes このように見えるかもしれません：

[
  {
    "_id" : "likes/1" ,
    "_key" : "1" ,
    "_from" : "persons/alice" ,
    "_to" : "cafes/jd",
    "since" : 2010 
  },
  {
    "_id" : "likes/2" ,
    "_key" : "2" ,
    "_from" : "persons/alice" ,
    "_to" : "cafes/jj",
    "since" : 2011 
  } ,
  {
    "_id" : "likes/3" ,
    "_key" : "3" ,
    "_from" : "persons/bob" ,
    "_to" : "cafes/jd",
    "since" : 2012 
  }
]

クエリと結果

ArangoDB で使用される AQL 言語のグラフ スタイル クエリは、誰がどのカフェを好むかに関する情報を人間が判読できる形式で返します。これは次のようになります。

FOR p IN persons
  FOR c IN OUTBOUND p likes
  RETURN { person : p.name , likes : c.name }

関係を保存するのではなく「計算」するリレーショナル スタイルでは、このクエリは次のように書き直すことができます (ちなみに、コレクションは使用しません) likes なしでもできます):

FOR p IN persons
  FOR l IN likes
  FILTER p._key == l._from
    FOR c IN cafes
    FILTER l._to == c._key
    RETURN { person : p.name , likes : c.name }

どちらの場合でも結果は同じになります。

[
  { "person" : "Алиса" , likes : "Жан-Жак" } ,
  { "person" : "Алиса" , likes : "Джон Донн" } ,
  { "person" : "Боб" , likes : "Джон Донн" }
]

さらに多くのクエリと結果

上記の結果形式がドキュメント DBMS よりもリレーショナル DBMS の方が一般的であると思われる場合は、このクエリを試すことができます (または、次のクエリを使用できます) COLLECT):

FOR p IN persons
  RETURN {
    person : p.name,
    likes : (
      FOR c IN OUTBOUND p likes
      RETURN c.name
    )
}

結果は次のようになります。

[
  { "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"]  } ,
  { "person" : "Боб" , likes : ["Джон Донн"] }
]

OrientDB

OrientDB でドキュメント モデルの上にグラフ モデルを実装するための基礎は次のとおりです。 機会 ドキュメント フィールドには、多かれ少なかれ標準的なスカラー値に加えて、次のような型の値もあります。 LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG。 これらのタイプの値は、へのリンクまたはリンクのコレクションです。 システム識別子 ドキュメント

システムによって割り当てられる文書識別子には、データベース内のレコードの位置を示す「物理的な意味」があり、次のようになります。 @rid : #3:16。 したがって、参照プロパティの値は実際には (リレーショナル モデルのような) 選択条件ではなく (グラフ モデルのような) ポインターです。

ArangoDB と同様、OrientDB のエッジは別個のドキュメントとして表されます (ただし、エッジに独自のプロパティがない場合は、 軽量、別文書には対応しません）。

初期データ

に近い形式で ダンプ形式 OrientDB データベースの場合、ArangoDB の前の例のデータは次のようになります。

[
     {
      "@type": "document",
      "@rid": "#11:0",
      "@class": "Person",
      "name": "Алиса",
      "out_likes": [
        "#30:1",
        "#30:2"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#12:0",
      "@class": "Person",
      "name": "Боб",
      "out_likes": [
        "#30:3"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#21:0",
      "@class": "Cafe",
      "name": "Жан-Жак",
      "in_likes": [
        "#30:2",
        "#30:3"
      ],
      "@fieldTypes": "in_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#22:0",
      "@class": "Cafe",
      "name": "Джон Донн",
      "in_likes": [
        "#30:1"
      ],
      "@fieldTypes": "in_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#30:1",
      "@class": "likes",
      "in": "#22:0",
      "out": "#11:0",
      "since": 1262286000000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    },
    {
      "@type": "document",
      "@rid": "#30:2",
      "@class": "likes",
      "in": "#21:0",
      "out": "#11:0",
      "since": 1293822000000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    },
    {
      "@type": "document",
      "@rid": "#30:3",
      "@class": "likes",
      "in": "#21:0",
      "out": "#12:0",
      "since": 1325354400000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    }
  ]

ご覧のとおり、頂点には、入ってくるエッジと出ていくエッジに関する情報も格納されます。 で の使用 Document API は参照整合性自体を監視する必要があり、Graph API がこの作業を引き受けます。 しかし、プログラミング言語に統合されていない「純粋な」クエリ言語で OrientDB へのアクセスがどのように見えるかを見てみましょう。

クエリと結果

OrientDB の ArangoDB の例のクエリと目的が似ているクエリは次のようになります。

SELECT name AS person_name, OUT('likes').name AS cafe_name
   FROM Person
   UNWIND cafe_name

結果は次の形式で取得されます。

[
  { "person_name": "Алиса", "cafe_name": "Джон Донн" },
  { "person_name": "Алиса", "cafe_name": "Жан-Жак" },
  { "person_name": "Боб",  "cafe_name": "Жан-Жак" }
]

結果の形式が再び「リレーショナル」すぎると思われる場合は、次の行を削除する必要があります。 UNWIND():

[
  { "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
  { "person_name": "Боб",  "cafe_name": [ "Жан-Жак" ' }
]

OrientDB のクエリ言語は、Gremlin のような挿入を備えた SQL として説明できます。 バージョン2.2ではCypher風のリクエストフォームが登場しましたが、 MATCH :

MATCH {CLASS: Person, AS: person}-likes->{CLASS: Cafe, AS: cafe}
RETURN person.name AS person_name, LIST(cafe.name) AS cafe_name
GROUP BY person_name

結果の形式は前のリクエストと同じになります。 最初のクエリのように、より「リレーショナル」にするために何を削除する必要があるかを考えてください。

アズール コスモスDB

程度は低いですが、ArangoDB と OrientDB について上で述べたことは、Azure CosmosDB にも当てはまります。 CosmosDB は、SQL、MongoDB、Gremlin、Cassandra のデータ アクセス API を提供します。

SQL API と MongoDB API は、ドキュメント モデル内のデータにアクセスするために使用されます。 Gremlin API と Cassandra API - それぞれグラフ形式と列形式のデータにアクセスします。 すべてのモデルのデータは、CosmosDB 内部モデル形式で保存されます。 ARS (「atom-record-sequence」)、これもドキュメント XNUMX に近いものです。

ただし、ユーザーが選択したデータ モデルと使用する API は、サービスでのアカウント作成時に固定されます。 次のように、あるモデルにロードされたデータに別のモデルの形式でアクセスすることはできません。

したがって、今日の Azure CosmosDB のマルチモデルは、XNUMX つのメーカーの異なるモデルをサポートする複数のデータベースを使用できるだけであり、マルチバリアント ストレージの問題をすべて解決するわけではありません。

グラフモデルに基づくマルチモデルDBMS?

注目すべきは、グラフ モデルに基づくマルチモデル DBMS がまだ市場に存在しないという事実です (ただし、RDF と LPG という XNUMX つのグラフ モデルを同時にサポートするマルチモデル サポートは除きます。これについては、「 以前の出版物）。 最大の問題は、リレーショナル モデルではなく、グラフ モデルの上にドキュメント モデルを実装することによって引き起こされます。

グラフ モデルの上にリレーショナル モデルを実装する方法の問題は、グラフ モデルの形成中にも検討されました。 どうやって 彼は言い​​ました例えば デビッド・マクガバン:

グラフ アプローチには、(1) 通常のキー値ペアからのタプルの回復と (2) グループ化によるリレーショナル ビューを可能にする、グラフ データベース上でのレイヤーの作成 (たとえば、適切なインデックス付けによる) を妨げる本質的なものは何もありません。リレーションタイプ別のタプル。

グラフ モデルの上にドキュメント モデルを実装する場合は、たとえば次のことに留意する必要があります。

• JSON 配列の要素は順序付けされていると見なされますが、グラフのエッジの頂点から発せられる要素は順序付けされていません。
• ドキュメント モデル内のデータは通常非正規化されており、同じ埋め込みドキュメントの複数のコピーを保存することは望ましくなく、サブドキュメントには通常識別子がありません。
• 一方、ドキュメント DBMS のイデオロギーは、ドキュメントは毎回新たに構築する必要のない既成の「集合体」であるということです。 完成した文書に対応するサブグラフを迅速に取得する機能をグラフ モデルに提供する必要があります。

いくつかの広告

この記事の著者は NitrosBase DBMS の開発に関係しており、その内部モデルはグラフであり、外部モデル (リレーショナル モデルとドキュメント) はその表現です。 すべてのモデルは同等です。自然なクエリ言語を使用して、ほぼすべてのデータをどのモデルでも利用できます。 さらに、どのビューでもデータを変更できます。 変更は内部モデルに反映され、それに応じて他のビューにも反映されます。

NitrosBase でのモデル マッチングがどのようなものであるかについては、次の記事のいずれかで説明できればと思います。

まとめ

マルチモデリングと呼ばれるものの概要が読者にとって多かれ少なかれ明らかになったことを願っています。 マルチモデル DBMS はまったく異なるものであり、「マルチモデルのサポート」も異なって見える場合があります。 それぞれの特定のケースにおける「マルチモデル」と呼ばれるものを理解するには、次の質問に答えることが役立ちます。

1. 従来のモデルのサポートについて話しているのでしょうか、それともある種の「ハイブリッド」モデルのサポートについて話しているのでしょうか?
2. モデルは「等しい」のでしょうか、それともモデルの XNUMX つが他のモデルの主題になっているのでしょうか?
3. モデルたちはお互いに「無関心」なのでしょうか？ あるモデルに書き込まれたデータを別のモデルで読み込んだり、上書きしたりすることはできますか?

マルチモデル DBMS の関連性についての質問にはすでに前向きに答えられると思いますが、興味深いのは、どのタイプの DBMS が近い将来より需要が高まるかということです。 従来のモデル、主にリレーショナル モデルをサポートするマルチモデル DBMS の需要がさらに高まると思われます。 さまざまな従来の DBMS の利点を組み合わせた新しいモデルを提供するマルチモデル DBMS が普及するのは、さらに遠い将来の話です。

登録ユーザーのみがアンケートに参加できます。 ログインお願いします。

マルチモデル DBMS を使用していますか?

• 私たちはそれを使用せず、すべてを XNUMX つの DBMS と XNUMX つのモデルに保存します。

• 従来の DBMS のマルチモデル機能を使用します

• 私たちは多言語永続性を実践します

• 新しいマルチモデル DBMS (Arango、Orient、CosmosDB) を使用します

19 人のユーザーが投票しました。 4名のユーザーが棄権した。

出所： habr.com