1

私は GraphDB の概念に慣れていないので、誤解があればご容赦ください。この質問は主に OrientDB に関するもので、ハイブリッド ドキュメント + グラフ DB として使用することに興味があります。

OrientDB の Raw API のドキュメントでは、ルート ノードを宣言して名前を付ける必要があることが示唆されているようですが... http://code.google.com/p/orient/wiki/GraphDatabaseRaw

しかし、これは絶対に必要なのだろうか。OrientDB のアーキテクチャ (GraphDB はドキュメント ベースのデータベースの上に構築されている) を考えると、独立したグラフはより一般的な実用的な使用法であると考えています。確かに、クラスター/クラス タイプ内に複数の独立したグラフを作成し、「開始」ノードを指定してグラフをトラバースできるはずです。

データの「タイプ/クラス」に対する単一の「ルート」ノードの理想は、制限が厳しすぎるようです。

Raw Graph API を使用して OrientDB を処理するためのより良い例を持っている人はいますか? このページhttp://code.google.com/p/orient/wiki/JavaAPIによれば、 Tinkerpop API は Raw Graph API よりもはるかに遅いため、Tinkerpop の使用には消極的です (そして、パフォーマンス指向のアプリケーションを構築しています)。しかし、典型的な使用方法の実装例が見つかりません。

4

1 に答える 1

1

ルート ノードは、クエリなしでグラフを横断する方法としてオプションです。使用を避け、クエリを実行してグラフ要素を取得できます。

TinkerPop ブループリントの使用法については、(いくつかのベンチマークの後) パフォーマンスが本当に必要な場合にのみネイティブ API を使用し、ほとんどのトラバースを Gremlin に任せることで、このレベルでもハイブリッドを維持できます。

于 2012-05-22T13:10:12.123 に答える