NEO4Jのパフォーマンスを複数回実行クエリ

Question

ノードとしてSerieと関係としてEDGEで構成されたneo4jグラフがあります。私は2つのノード間のallShortestaPathsを計算することができるクエリを持っています。

MATCH (serie1:Serie {serie_id: 'id1'}), 
     (serie2:Serie {serie_id: 'id2'}), 
     p = allShortestPaths((serie1)-[EDGE*..6]-(serie2)) 
RETURN p as shortestPath 

私のアプリケーションは、数回の繰り返しをしている各反復でそれは2つの異なるノード（serie1、serie2）でクエリを複数回実行して、グラフ上のいくつかの新しいエッジを書き込みます。

最初の反復（20回のクエリ）は非常に高速に実行されますが、2回目の反復で応答時間が増加し始め、クエリは実行ごとに3分以上かかります。

私はserie_idプロパティのインデックスを作成しました。また、8GBのスペースとページキャッシュサイジングにも十分なスペースがあるまでヒープスペースを増やしました。

また、クエリが別の方法で書き換えられるかどうかを調べていますが、これがより良い方法だと思われます。

問題は実行回数に関係していると思いますが、最適化の方法は不明です。

Answer 1

私のアプリケーションは、それが2つの異なるノード （serie1、serie2）でクエリを複数回実行して、グラフ上のいくつかの新しいエッジを書き込ん 各反復で、数回の反復を行っています。

新しい書き込みがpathsまたは反復中に一致しているnodesに影響を与える場合は、x回後に失効としてクエリをマーキングクエリサンプリングが発生する場合があります。

私はあなたがそのような行を見れば、あなたがlogs/debug.logファイルをチェック示唆している：もちろん

2016-09-22 09:32:39.178+0000 INFO [o.n.k.i.a.i.s.OnlineIndexSamplingJob] Sampled index :WithIndex(id) with 1001 unique values in sample of avg size 1001 taken from index containing 1001 entries 
2016-09-22 09:32:49.179+0000 INFO [o.n.k.i.a.i.s.OnlineIndexSamplingJob] Sampled index :WithIndex(id) with 1001 unique values in sample of avg size 1001 taken from index containing 1001 entries 

AND 

2016-09-22 07:26:01.359+0000 INFO [o.n.c.i.ExecutionEngine] Discarded stale query from the query cache: CREATE (n:Node {id: {i} }) 
2016-09-22 07:26:01.361+0000 INFO [o.n.c.i.CypherCompiler] Discarded stale query from the query cache: CREATE (n:Node {id: {i} }) 
2016-09-22 07:26:10.403+0000 INFO [o.n.c.i.ExecutionEngine] Discarded stale query from the query cache: CREATE (n:Node {id: {i} }) 
2016-09-22 07:26:10.404+0000 INFO [o.n.c.i.CypherCompiler] Discarded stale query from the query cache: CREATE (n:Node {id: {i} }) 

これらの行は、私は自分のアプリケーションで行うクエリを反映して、あなたのクエリが代わりに表示されます。これらのログ中にGCの一時停止も表示されます。

クエリが失効しているとみなされるしきい値を調整できます。設定がここで説明されています

https://neo4j.com/docs/operations-manual/current/reference/#config_cypher.statistics_divergence_threshold

、ここ

https://neo4j.com/docs/operations-manual/current/reference/#config_cypher.min_replan_interval

を一切アウト・オブ・ボックスの値がありませんが、私は多分0.8に最初の1を増やすだろうが、そうではありません他のクエリに影響する可能性があるため、簡単です。