26

私はグラフ データベースのシーンに不慣れで、Neo4j を調べて Cypher を学習しています。グラフ データベースをモデル化しようとしています。これはかなり単純なものです。ユーザーがいて、ムービーがあり、ユーザームービーを表示したり、ムービーを評価したりできます。プレイリストを作成し、プレイリストにはムービーを含めることができます。

質問は、スーパー ノードのパフォーマンスの問題に関するものです。そして、私が現在読んでいる非常に優れた本 - Learning Neo4j by Rik Van Bruggenから何かを引用します。

グラフの一部がすべて同じノードに接続されているデータセットでは、非常に興味深い問題が発生します。高密度ノードまたはスーパーノードとも呼ばれるこのノードは、グラフ トラバーサルの実際の問題になります。これは、グラフ データベース管理システムが、そのノードに接続されているすべての関係を評価して、次のステップを決定する必要があるためです。グラフトラバーサル。

本で提案されているこの問題の解決策は、100 の接続を持つメタ ノードを作成し、101 番目の接続を以前のメタ ノードにリンクされた新しいメタ ノードにリンクすることです。

DENSE_LIKES がファンアウト

公式の Neo4j ブログのブログ記事で、この問題は今後修正されると書かれているのを見ました (ブログ記事は 2013 年 1 月のものです) - http://neo4j.com/blog/2013-whats-coming-next- in-neo4j/

より正確には、彼らは次のように言っています。

「より大きなデータ」に関して計画しているもう 1 つのプロジェクトは、非常に多数 (数百万) の関係を持つ密に接続されたノード間のトラバーサルを処理するための特定の最適化を追加することです。(この問題は「スーパーノード」問題と呼ばれることもあります。)

この問題についてどう思いますか。メタ ノードのファンアウト パターンを使用する必要がありますか?それとも、すべてのチュートリアルで使用されているように見える基本的な関係を使用する必要がありますか? 他の提案はありますか?

4

3 に答える 3

2

再。Neo4j ブログ、高密度ノードのサポートは Neo4j 2.1 (およびそれ以降) で強化する必要があります。http://neo4j.com/blog/neo4j-2-1-graph-etl/も参照してください。

于 2014-12-26T19:20:47.363 に答える
0

(免責事項:答えではなく、いくつかの議論)

あなたが言及した2013年のneo4jブログ投稿は、意図した問題の範囲とその解決策が議論されているこのgithubコミットへのリンクを言及しました。supernode要約すると、それは一般的な問題には対処していません。代わりに、 が持つ複数のリレーションシップ タイプ (および方向) のsupernode中で、一部のタイプ (方向) のエッジが他のものより不釣り合いに少ない場合の問題を軽減します。エンジンは、タイプと方向に基づいてフィルタリングできます。

より一般的な解決策は、vertex centricTitan ( https://stackoverflow.com/a/21385213/1311956 ) からのアプローチです。これは、プロパティの 1 つまたは複合によってエッジを並べ替え、O(log(E)) 検索パフォーマンスをもたらします。 E は に出入りするエッジの数ですsupernode

Neo4j には、関係に関するインデックスの概念があります。Titan のアプローチとは異なりvertex centric、インデックスはグローバルです。ただし、リレーションシップ インデックスは Neo4j のレガシー インデックスです。これについては、別のstackoverflow スレッドで説明しています。

もう 1 つの問題Supernodeは、ストレージの問題と IO コストにつながるストレージの問題です。

于 2016-03-03T19:55:49.430 に答える