私はRDFのようなグラフデータ構造を持っています。つまり、さまざまな種類のエッジ（プロパティ、リレーション）によって接続されたノード（エンティティ）で構成されています。ユーザーはそのグラフでノード（数百万のノード、数億のエッジ）を選択し、選択したノード（つまり、そこから1つまたは2つのレベルのノード）の「近接性」を表示する高速な方法を探しています。は、最初に選択されたノードへの、指定された可能性のある一連の関係を経由するパスです）。
私はいくつかの調査を行い、RDFに特化したトリプルストアと、neo4jやallegroなどのより一般的なグラフデータベースに出くわしました。次に、イエナやゴマなどのミドルウェア製品もあります。
近くに接続されているノードのクエリを効率的にするために、トリプルストアまたはグラフデータベースをお勧めしますか？ミドルウェアはここで役割を果たしますか？いずれの場合も、完全なグラフをメモリに保持することがおそらく有利になることを理解しています。
アレクサンダー
RDFストアの1つ（Jena、Sesame、4store、Virtuoso、OWLim、Oracleなど）をお勧めします。次に、ソリューションのSPARQLクエリを学習し、さまざまなAPIをコーディングしなくても、さまざまなシステムで試すことができます。
いくつかのアプローチがあります。最も簡単なのは、おそらくパスが異なるUNIONクエリです。エッジURIに変数を使用し、FILTERを追加して、関心のあるものだけに制限することができます。
明確にするために、私は Jena や Sesame をミドルウェアとして分類しません。どちらもネイティブ ストレージとインデックスを備えています。
Jena には、B+Tree インデックスを使用するTDBがあります。特にデフォルトのグラフでは、SPO、POS、OSP の 3 つのインデックスがあります。
あなたの場合、SPO インデックスは、特定のサブジェクトのすべてのトリプルを提供するために使用されます。2 レベルの深さが必要な場合は、インデックスを複数回タッチする必要があります。最初の主題に対して 1 回、主題に修正された各オブジェクトに対して 1 回です。
TDB はメモリ マップ ファイルを使用してインデックスをキャッシュするため、十分な RAM があれば問題ありません。
やりたいことは、RDF コミュニティの人々がConcise Bounded Description (CBD) と呼んでいたものに非常に近いものですが、2 レベル以上の深さが必要な場合は、それを自分で実装する必要があります。SPARQL クエリ言語は、使用できる DESCRIBE を提供します (ただし、1 レベルの深さです)。
最後になりましたが、RDF のようなグラフ データ構造を持っていると言いますが、それは RDF ではありません。このため、データを RDF に変換するか、RDF データをロードして管理するように設計されているトリプル ストアの使用をあきらめる必要があります。実際には、ストレージとインデックス作成レイヤーの一部だけを使用して、独自のカスタム インデックスを作成して使用できる場合でも.
あなたにとって最善の方法は、データを使って実験を行い、さまざまなソリューションがユース ケースでどのように機能するかを比較することです。