2017-12-02 12 views
0

私はノードの階層構造を持っています。これらはすべて、カスタム割り当てのソートプロパティ(数値)を持っています。ここでは簡単なサイファークエリは再作成します:neo4j - ノードのランクに基づいてクエリを制限する

merge (p {my_id: 1})-[:HAS_CHILD]->(c1 { my_id: 11, sort: 100}) 
merge (p)-[:HAS_CHILD]->(c2 { my_id: 12, sort: 200 }) 
merge (p)-[:HAS_CHILD]->(c3 { my_id: 13, sort: 300 }) 
merge (c1)-[:HAS_CHILD]->(cc1 { my_id: 111 }) 
merge (c2)-[:HAS_CHILD]->(cc2 { my_id: 121 }) 
merge (c3)-[:HAS_CHILD]->(cc3 { my_id: 131 }); 

私は苦労してる問題は、多くの場合、私はこの種の識別子にregadsで、いくつかの親ノードに子ノードのランク相対に基づいて意思決定を行うために必要があるということです。たとえば、ノードc1は、ノードp(それは少なくともsortプロパティを持つため)に対してランク1を持ち、はランク2を持ち、c3はランク3(最大はsort)です。

この情報に基づいて決定する必要のある種類:最初の2つのcXノードの子のみを表示します。

graph

cc1cc2が存在するが、c3(親)が第一またはpの第二子ではないので、cc3ではありません。ここに私が取得したいものです。ここではそのためのダムのクエリです:

match (p {my_id: 1 })-->(c) 
optional match (c)-->(cc) where c.sort <= 200 
return p, c, cc 

問題は、これらのsortプロパティは、カスタム設定および輸入されている、ですので、私は子供の数2

私のために開催される値知る方法はありません現在のソリューションはインポート時にランク付けすることです.Oracleを使用しているので、これは非常に単純です - ちょうどrankウィンドウ関数を使用する必要があります。しかし、それは私にとっては厄介なようで、私はそこにもっと洗練された解決策があるように感じます。私は次のクエリを試してみましたが、それは動作しますが、それは奇妙に見える、それは大きなグラフにはかなり遅いです:

match (p {my_id: 1 })-->(c) 
optional match (c)-->(cc) 
where size([ (p)-->(c1) where c1.sort < c.sort |c1]) < 2 
return p, c, cc 

は、ここでは、このクエリのプランだと最も高価な部分は、実際にsize式です:

query plan

答えて

2

クエリでインデックスルックアップを実行していないため、表示される速度が遅いため、すべてのノードスキャンを実行しており、グラフ内のすべてのノードのmy_idプロパティにアクセスして、id 1(お客様のpノード)。

ノードにラベルを追加し、クエリにこれらのラベルを使用する必要があります(少なくともpノードの場合)。my_idのラベルにインデックス(またはこの場合はおそらく一意制約)を作成する必要があります。検索が高速になります。

クエリのPROFILEを実行することで、何が起きているかを確認できます(プロファイルプランを説明に追加でき、計画のすべての要素が拡張され、さらに最適化が判断されます)。これはノードだけではなく、パスや関係を返すこと

match (p:Node {my_id: 1 })-->(c) 
with p, c 
order by c.sort asc 
with p, collect(c) as children // children are in order 
unwind children[..2] as child // one row for each of the first 2 children 
optional match (child)-->(cc) // only matched for the first 2 children 
return p, children, collect(cc) as grandchildren 

注:

はあなたのクエリのように、このような作業をする必要があります(実際のラベルの代役としてのノードラベル私が使用しています)。グラフィカルビューで結果グラフを表示するのは、ブラウザ設定タブ(左下のメニューの歯車アイコン)の下部に Connect result nodesが表示されているためです。

+0

拡張レスポンスをいただきありがとうございます。プロファイルプランを私の質問に追加しました。実際のところ実際のDBでは、計画で見られるように索引とラベルが必要であり、計画の中で最も高価な部分は実際にはそのサイズの節です。あなたの質問は非常に実績がありますので、私はそれがトリックだと言います!再度、感謝します! –

関連する問題