31

これはやや抽象的で一般的な質問です。多くの内部参照 (グラフのような) と多くのプロパティ (JSON のような) の両方を持つ非構造化データを永続化するためのさまざまなアプローチの固有の (および実装固有の) プロパティに興味があります。

  • グラフはツリーのスーパーセットであるため、グラフ DB (Neo4j など) をドキュメント DB (MongoDB など) のスーパーセットと見なすことができます。つまり、グラフ DB はドキュメント DB のすべての機能を提供し、さらにループを許可したり、ネイティブ ポインター型を持っているため、外部キー/ID を手動で逆参照する必要はありません。オブジェクト/リソースへの参照を追加する際に、以前はドキュメント ストアを使用した方がグラフ DB の方が優れていた場合に、到達する転換点はありますか? ドキュメント DB には利点がありますか (ストレージ容量、パフォーマンス?)、それとも、将来さらに参照が必要になる場合に備えて、常にグラフ DB を使用する必要がありますか?

  • 同様に、グラフ DB とトリプルストア (RDF ストアなど) はどのように比較されますか? グラフ DB (ノードとエッジにプロパティがある) は、単純なトリプルストアのスーパーセットのようです。では、Neo4j と言うよりも実際にトリプルストアを実行する問題 (ある場合) は何ですか? (RDF ストアの利点の 1 つは、標準化されたクエリ言語である SPARQL があることです。ただし、SPARQL を好まず、短所と呼ぶ人が多いようです。)

私の質問だと思います: グラフ モデル (プロパティ付き) はあらゆる種類のデータをきれいに表現できるようですが、現実に入ったときのキャッチは何ですか? グラフ DB の問題点はパフォーマンスだと思うので、データのロード、クエリ、変更、メモリ、および永続的なストレージの要件 (ドキュメントトリプルストア）。また、水平方向のスケーラビリティはどうですか? 競技場は非常に平らであるという印象を受けました。

表現可能性を備えたグラフが、超大規模データを持たないプロジェクトの新しいデフォルト ストレージ モデルになる可能性があると思いますか? それとも、RDBMS、JSON ストア、グラフ DB が共存する 10 年間のPolyglot Persistenceの運命にあると思いますか?さらに多くのグルーコードと統合する必要がありますか?

4

3 に答える 3

12

多くの人がSPARQLを嫌うという感情に同意するかどうかはわかりません。SPARQL 1.0にはいくつかの欠点がありましたが、設計の目的に非常にうまく対応しており、新しいイテレーションであるSPARQL 1.1は、サブクエリや集計など、元の仕様で見られると予想されるSQLからの多くの構造を追加して構築されています。 ＆セマンティクスを更新します。これは標準であり、SQLの方言とは対照的に、すべてのトリプルストアで同じ構文解析とセマンティクスを期待できるという事実は素晴らしい機能だと思います。

また、すべてのトリプルストアはグラフデータベースであると主張します。Neo4jを使用した場合ほどうまくはいきませんが、RDFの特定のエッジにプロパティを配置できます。ただし、トリプルストアには、実際のクエリ言語、データを別のトリプルストアに簡単に移動できるw3c標準データ表現、および多くのトリプルストアでOWLに基づいて推論を実行できるという利点があります。

ほとんどのグラフデータベースのスケーラビリティについては何も知りませんが、一般的に、商用RDFデータベースは非常にうまくスケーリングします。すべてが数十億のトリプルに拡張でき、非常に多くのユースケースを処理します。スケールの処理方法はベンダーごとに大きく異なりますが、スケールアップまたはスケールアウト、クラスタリングなどがあります。また、それぞれの実装に合わせて、かなり異なるメモリとハードウェアの要件が表示されます。私にとっては、EC2インスタンス（通常は2XLまたは4XL）を取得し、データを保持するのに十分な大きさのEBSをマウントする傾向があり、かなりうまく設定されています。

さらに、一部のトリプルストアは、Luceneまたは同様のテクノロジーと統合して、データに転置インデックスを提供します。現在、多くのストアに地理空間インデックスと時間インデックスが含まれ始めています。これらは非常に便利な機能であり、Neo4jのようなもので利用できるかどうかはわかりません。

そうは言っても、それらはリレーショナルデータベースほど拡張されることはなく、成熟していないだけです。ただし、「実際の」量のデータがある場合でも、混乱することはありません。もちろん、トリプルストアの利点の1つは推論であり、大規模な実行には注意が必要ですが、それがさまざまなOWLプロファイルが作成された理由の多くです。しかし、先を考えなければ、自分を隅に追いやることができます。

グラフデータベース、特にトリプルストアは、構築されている多くのアプリケーションにかなり適していると思いますが、それはすべてがそれらで行われるべきだという意味ではないと思います。他のものと同様に、それらは長所と短所を備えたツールであるため、アプリケーションに基づいて正しい選択を行う必要があります。しかし、彼らはおそらく、最近は少なくとも考慮に値するでしょう。

于 2012-08-20T19:37:53.543 に答える
11

amk の回答に対するちょっとした修正: Tinkerpop には ArangoDB 用のアダプターも含まれています。 https://github.com/triAGENS/blueprints-arangodb-graph/wiki/Gremlinを参照してください。したがって、ArangoDB で Gremlin クエリを使用できます。

一般に、ArangoDB や OrientDB などのマルチモデル データベースでは、ドキュメント データベースのすべての優れた機能 (スキーマフリー、インデックス) をグラフ構造と共に使用できます。頂点またはエッジは、ドキュメント データベースのような単なるドキュメントです。プロパティや埋め込みドキュメントを好きなだけ持つことができます。これらのドキュメントには、ハッシュ、範囲、フルテキスト、または地理インデックスを定義できます。または、ドキュメント構造を忘れて、ドキュメントを頂点とエッジとして表示し、Gremlin やトラバーサル言語を使用して基になるグラフを調査することもできます。

「ポリグロットの永続化は運命づけられているか」という質問については、ドキュメント/グラフ データベースの質問とは別に、RDBMS はもう少し長く使用されると思います。したがって、その質問に対する答えは、「はい、その可能性は非常に高い」です。

于 2013-02-22T15:00:23.637 に答える
6

グラフ データベースには、ArangoDB 以外のほぼすべてでサポートされている Gremlin (命令型) クエリ言語を含むTinkerpopというアドホックな標準があります。

状況をさらに悪化させるために、ドキュメントとグラフのハイブリッド データベースである OrientDB と ArangoDB もあります。

エッジを使用して子関係をグラフ データベースに保存する場合と、ドキュメント データベースに埋め込みオブジェクトとして保存する場合の主な違いは、前者では子を別の親に安価に移動でき、別の親に表示されるリスクがないことです。 2 つの異なる場所を持つ 2 つの場所。

于 2012-08-21T09:26:13.730 に答える