2

7340 ノードの Neo4j データベースがあります。各ノードには、ラベル (新生物) と 2 つのプロパティ (conceptID と fullySpecifiedName) があります。両方のプロパティで自動インデックス作成が有効になっており、neoplasm:conceptID と neoplasm:fullySpecifiedName にスキーマ インデックスを作成しました。ノードは、用語ツリーの概念です。単一のルート ノードがあり、他のノードは複数のパスを経由して最大 13 レベルの深さまで下降します。SQL Server の実装から、階層構造は次のようになります...

Depth Relationship Count
0     1
1     37
2     360
3     1598
4     3825
5     6406
6     7967
7     7047
8     4687
9     2271
10    825
11    258
12    77
13    3

このような暗号クエリを構築して実行する C# プログラムと neo4jclient を使用して関係を追加しています...

MATCH (child:neoplasm), (parent:neoplasm)
WHERE child.conceptID = "448257000"   AND parent.conceptID="372095001"   
CREATE child-[:ISA]->parent

レベル 3 までの関係の追加は非常に高速で、レベル 4 自体は悪くありませんでしたが、レベル 5 では非常に遅くなり始め、関係ごとに平均 9 秒以上かかりました。

上記のサンプル クエリはhttp://localhost:7474/browser/インターフェイスを介して実行され、12917 ミリ秒かかりました。したがって、実行時間の短さは C# コードや neo4jclient API の特徴ではありません。

グラフ データベースは驚くほど高速であり、パフォーマンスはサイズに依存しないと考えていました。

これまでのところ、35362 の関係のうち 9033 だけを追加しました。関係が増えても速度が落ちなくても、残りを足すのに3日以上かかる！

このパフォーマンスが非常に悪い理由を誰かが示唆できますか? または、この性質の書き込みパフォーマンスは正常であり、非常に優れているのは読み取りパフォーマンスだけです。レベル 5 ノードの親を返す Cypher クエリのサンプルは、ストップ ウォッチで測定できる時間よりも短い時間で、23 個の完全に指定された名前のプロパティのリストを返します。（1秒未満）。

4

3 に答える 3

2

同時にラベルに異なるインデックスを使用する場合、Cypher は (まだ) クエリを高速化するためにこれらを選択しません。代わりに、それらを使用するためのヒントを提供してみてください。 -using.html#using-query-using-multiple-index-hints

PROFILE
MATCH (child:neoplasm), (parent:neoplasm)
WHERE child.conceptID = "448257000"   AND parent.conceptID="372095001"   
USING INDEX child:neoplasm(conceptID)
USING INDEX parent:neoplasm(conceptID)
CREATE child-[:ISA]->parent

それは物事を改善しますか？また、より良い洞察のために PROFILE 出力を投稿してください。

于 2013-10-23T09:39:54.157 に答える