web-dev-qa-db-ja.com

グラフデータベースとトリプルストア-どちらを使用するか

Stackoverflowについても同様の質問があることは知っていますが、次の質問に答えるとは思いません。

主にこのスキーマに従って、データベースをグラフに保存して理解します。

Table/Collection 1: store nodes with UID
Table/Collection 2: store relations referencing nodes via UID

これにより、任意のタイプのグラフを保存できます。私が理解しているように、トリプルストアはトリプル以外の何も保存しません:

Triple/Collection 1: store triples (2 nodes, 1 relation)

今、私はユースケースに関して次の区別を見ます:

  • グラフデータベース:既知の静的接続がある場合
  • トリプルストア:緩やかに接続されたノードがあり、新しい接続を頻繁に探している場合

私は、人々がこれらの基準に従ってどちらを使用するかについて議論していないようであるという事実に混乱しています。私が見つけたほとんどの記事は、速度や互換性などの議論について話している。しかし、これは最も重要なポイントではありませんか?

他の方法を回して:

  • 明確に接続されたユーザー定義のグラフがあると想像してください。一体どうしてそれをトリプルとしてのみ保存し、接続に関するすべての情報を失いたいのでしょうか?または、トリプルsubjectにIDを格納するカスタムソリューションを実装する必要があります。
  • SPARQLを使用して不明な関係を照会するノードを大まかに収集したとします。グラフデータベースはそれをサポートします。しかし、このために、彼らは私が推測する別のインデックスを構築する必要があり、より遅くなるでしょうか?

編集:「接続に関する情報を失う」ことは間違った方法だと思います。受け入れられた回答に示されているように行い、2つのノードと1つのリレーションにいくつかのトリプルを挿入すると、すべての情報、特に正確に接続されているノードの情報を保持します。

48
B M

グラフデータベースとトリプルストアの主な違いは、グラフのモデル化方法です。トリプルストア(またはクアッドストア)では、データは非常にatomicになる傾向があります。つまり、グラフの「ノード」は、文字列、整数、日付などのプリミティブデータ型である傾向があります。関係はプリミティブをリンクするため、トリプルストアの「談話単位」はトリプルであり、通常、ノードまたは関係。

対照的に、ノードはドメイン内のオブジェクトに対応するデータコンテナであるため、他のグラフデータベースはしばしば「プロパティストア」と呼ばれます。ノードはオブジェクトを表し、プロパティがあります。これらは、単なるプリミティブデータ型ではなく、グラフモデラーによって指定されたリッチデータ型として機能します。これらのグラフデータベースでは、ノードと関係が「談話の単位」です。

「スーザン」を知っている「ボブ」という名前の人がいるとしましょう。 RDFでは、次のようなものになります。

<http://example.org/person/1> :hasName "Bob".
<http://example.org/person/1> foaf:knows <http://example.org/person/2>.
<http://example.org/person/2> :hasName "Susan".

Neo4jのようなグラフデータベースでは、次のようになります。

(a:Person {name: "Bob"})-[:KNOWS]->(b:Person {name: "Susan"})

RDFでは、3つの関係ですが、実際にはそれらの関係の1つだけが2つのエンティティ間のセマンティクスを表現していることに注意してください。他の2つの関係は、単一の上位レベルエンティティ(個人)の追跡プロパティです。 neo4jでは、2つのノード間の1関係であり、各ノードにはプロパティがあります。 RDFでは、URIによって物事を識別する傾向があります。neo4jでは、データベースIDを自動的に取得するデータベースオブジェクトです。これは、よりアトミック/プリミティブストア(トリプル店舗)と豊富なプロパティグラフ。

RDFとトリプルストアは、セマンティックWebで遭遇するようなアーキテクチャ上の課題に対応するために構築されています。たとえば、多くの異なるボキャブラリと名前空間の使用を組み合わせて一致させるというアーキテクチャ上の前提に基づいて、XMLネームスペースが組み込まれています。 (まさに、「セマンティックWeb」の仮定があります)。したがって、SPARQLおよびRDFでは、通常表示されます少なくともxsdrdf、およびrdfs名前空間を同時に、おそらくowlskos、およびその他多数SPARQLとRDF/RDFSには、オントロジーの推論などを容易にするために明示的に存在する多くのフックと機能もあります。 「識別子の名前空間」の方法としてURIで物事を識別する傾向がありますが、一部の人々はURIを逆参照したいかもしれません...ここでの仮定は、多くの関係者間の幅広いデータ共有の取り決めです。

対照的に、プロパティストアは、データの柔軟なモデリング1つのモデル/ネームスペース内、エンタープライズアプリケーションの永続性のためのオブジェクトとグラフ間のマッピング、急速な進化などのさまざまなユースケースに向けられています。独自のスキーム(または内部データベースID)で物事を識別する傾向があります。自動インクリメント整数は、Web上のランダムな消費者にとってはIDの最良の形式ではないかもしれません(URLのように間接参照することはできません)が、企業内部アプリケーションの最初の考えではないかもしれません。

どちらが良いですか?よりアトミックなトリプルストア形式、または豊富なプロパティグラフ? 1つのクエリまたはデータモデルで多くの異なる語彙を組み合わせて一致させる必要がありますか? OWLオントロジーを作成する必要がありますか、それとも推論を行う必要がありますか?メモリー内のJavaオブジェクトをデータベースに大量にシリアル化する必要がありますか?長いパスを高速にトラバースする必要がありますか?これらのタイプの質問が選択を導きます。

グラフはグラフであり、どちらもグラフを作成します。そのため、グラフが表すことができるものや、「グラフ用語」で問題をどう考えるかに関して、大きな違いはないと思います。違いは、ボンネットの下のアーキテクチャと、どのような種類のユースケースが必要だと思うかで決まります。一方が他方より優れているとは言いませんが、賢明に選択してください。

69
FrobberOfBits