2016-11-06 11 views
0

私は3Mノードと5M以上のリレーションシップを含むこのデータセットを持っています。約8種類のリレーションシップタイプがあります。ここで、2つのノードが相互接続されている場合、2つのノードを返したいと思います。ここでは2つのノードはA & Bであり、それらが相互接続されているかどうかを確認したいと思います。リターンリレーションシップリストに属します。Neo4j cypher

MATCH (n:WCD_Ent) 
USING INDEX n:WCD_Ent(WCD_NAME) 
WHERE n.WCD_NAME = "A" 
MATCH (m:WCD_Ent) 
USING INDEX m:WCD_Ent(WCD_NAME) 
WHERE m.WCD_NAME = "B" 
MATCH (n) - [r*] - (m) 
RETURN n,r,m 

これにより、Javaヒープスペースエラーが発生します。

2つのノードA & Bの間の関係に少なくとも1つの特定のリレーションシップタイプ(NAME_MATCH)が少なくとも1回含まれているかどうかを調べるために、別の条件を使用します。 A同じことに私が手伝ってもらえますか?

答えて

1

;:ので、私は、クエリから次の2行を削除しました開始する行のデカルト積を生成してから、パターンを使用して除外するため、ヒープスペースが爆発しています。パターンを使用して行を生成すれば、より効率的な空間を作成できます。インデックスがWCD_Ent(WCD_NAME)の場合、インデックスを指定する必要はありません。これは、クエリが非常に遅く実行されていて、PROFILEがクエリプランナがインデックスをスキップしていることを示している場合にのみ行うことです。代わりにこの方法を試してください。

MATCH (n:WCD_Ent { WCD_NAME: "A" })-[r*..5]-(m:WCD_Ent { WCD_NAME: "B" }) 
WHERE ANY(rel IN r WHERE TYPE(rel) = 'NAME_MATCH') 
RETURN n, r, m 

ここWHEREフィルタは、(コレクション、あなたがそれを割り当てた方法である)rに関係のすべてをチェックし、それらの少なくとも1は、所望のタイプと一致することを確認します。

+0

こんにちは、私はこのエラーが発生します。あなたは私に同じことを助けてくれますか? タイプの不一致:期待された関係ですが、コレクション<関係>(行2、列31(オフセット:140)) 「どこにもありません(TYPE(r)= 'NAME_MATCH')」) "Type(r)"の – Sharath

+0

のrは、 'TYPE'呼び出しの' r'ではなく 'rel'でなければなりません。 (上に固定)今日は何も入力できません:)申し訳ありません:) –

+0

上記のクエリを実行すると、Javaヒープスペースエラーが発生します。( – Sharath

0

いくつかの機能強化:

  1. 代わりWHERE状態で、あなたはパターン内のプロパティ値をバインドすることができます。
  2. 3つのMATCH条件を1つにまとめると、クエリーエンジンがnmのデカルト積を計算しないようにすることができます。 (また、クエリプランを視覚化し、これを確認するためにEXPLAINを使用することができます。)

結果のクエリ:

MATCH (n:WCD_Ent { WCD_NAME: "A" })-[r*]-(m:WCD_Ent { WCD_NAME: "B" }) 
RETURN n, r, m 

更新:Eschlimanあなたがインデックスを指定する必要がないことを指摘とれガボールの提案は、最も重要な修正です

USING INDEX n:WCD_Ent(WCD_NAME) 
USING INDEX m:WCD_Ent(WCD_NAME) 
+0

こんにちは..私はまだ「Javeヒープスペース」エラー – Sharath

+0

を取得する。また、「EXPLAIN」使用方法については、何も出力はありませんでした。したがって、クエリプランを視覚化できませんでした – Sharath

1

Toreの答え(可変関係の上限を含む)は、2つのノードが接続されているかどうか、それらを接続するパスに特定の関係が存在するかどうかを調べるのに最適です。

これまでに説明したソリューションのほとんどの弱点は、変数のリレーションシップに制限がないということです。つまり、クエリは、可能性のあるすべてのパスを照合しようとするグラフ全体をクロールすることになりますそのようなパスが存在し、その後停止します。これはおそらくヒープスペースエラーの原因です。

Toreの提案では、2つのノードが接続されていない場合でもグラフ全体をクロールする必要がないため、マッチで可変長関係に上限を追加することをお勧めします。どの場合でも、上限ではヒープが爆発するのを防ぐ必要があります。

ここにいくつかの可能性があります。私は関係の上限を離れていますが、必要に応じて簡単に追加できます。

// this one won't check for the particular relationship type in the path 
// but doesn't need to match on all possible paths, just find connectedness 
MATCH (n:WCD_Ent { WCD_NAME: "A" }), (m:WCD_Ent { WCD_NAME: "B" }) 
RETURN EXISTS((n)-[*]-(m)) 

// using shortestPath() will only give you a single path back that works 
// however WHERE ANY may be a filter to apply after matches are found 
// so this may still blow up, not sure 
MATCH (n:WCD_Ent { WCD_NAME: "A" }), (m:WCD_Ent { WCD_NAME: "B" }) 
RETURN shortestPath((n)-[r*]-(m)) 
WHERE ANY(rel IN r WHERE TYPE(rel) = 'NAME_MATCH') 

// Adding LIMIT 1 will only return one path result 
// Unsure if this will prevent the heap from blowing up though 
// The performance and outcome may be identical to the above query 
MATCH (n:WCD_Ent { WCD_NAME: "A" }), (m:WCD_Ent { WCD_NAME: "B" }) 
MATCH (n)-[r*]-(m) 
WHERE ANY(rel IN r WHERE TYPE(rel) = 'NAME_MATCH') 
RETURN n, r, m 
LIMIT 1