如何加速Neo4j Cypher中的協作過濾？

Question

這是基於從Neo4j的文檔樣本的Cypher：

MATCH (user:User)-[:ORDERS]->(:Product)<-[:ORDERS]-(otherUser:User)-[:ORDERS]->(recommended:Product) 
WHERE NOT (user)-[:ORDERS]->(recommended) 
    AND user.id = 171 
RETURN distinct recommended.id, count(distinct otherUser.id) as frequency 
ORDER BY frequency DESC 
LIMIT 200 

而下面是我所作的改進：

MATCH (user:User)-[:ORDERS]->(p:Product) 
WHERE user.id = 171 
WITH DISTINCT p, user 
MATCH (p)<-[:ORDERS]-(otherUser:User) 
WITH DISTINCT otherUser, user 
MATCH (otherUser)-[:ORDERS]->(recommended:Product) 
WHERE NOT (user)-[:ORDERS]->(recommended) 
RETURN distinct recommended.id, count(distinct otherUser.id) as frequency 
ORDER BY frequency DESC 
LIMIT 200 

兩者返回相同的結果，但第二個運行快6倍。 （但仍然3我的Macbook花了幾秒鐘）

1. 爲什麼第二個運行更快？
2. 如何進一步提高速度？

Answer 1

您的查詢獲得p產品（您不想推薦），但最終會丟棄它們。這些p節點可用於與recommended節點進行比較，避免處理WHERE NOT (user)-[:ORDERS]->(recommended)（每次必須重新掃描每個訂單的user）所需的額外數據庫命中數。這應該會顯着加快您的查詢速度。

試試這個：

MATCH (user:User)-[:ORDERS]->(p:Product)<-[:ORDERS]-(otherUser:User) 
WHERE user.id = 171 
WITH COLLECT(DISTINCT otherUser) AS others, COLLECT(DISTINCT p) AS sharedProds 
UNWIND others AS other 
MATCH (other)-[:ORDERS]->(recommended:Product) 
WHERE NOT recommended IN sharedProds 
RETURN DISTINCT recommended.id, count(DISTINCT other) as frequency 
ORDER BY frequency DESC 
LIMIT 200; 

另外，我認爲User節點具有獨特id值，所以我用count(DISTINCT otherUser)代替count(DISTINCT otherUser.id)，這應該會更快。

Answer 2

第一個查詢可能比需要的慢，因爲它適用於DISTINCT性質，而不是節點，這迫使該數據庫有可能下探之前來查找每一個節點的屬性。如果id屬性對於單個節點User是唯一的（對於Product節點也是如此），則效率會降低。這將是相同的查詢的速度更快的版本，如果你可以假設沒有User股的id與另一User，並沒有Product股的id另一個Product：

MATCH (user:User)-[:ORDERS]->(:Product)<-[:ORDERS]-(otherUser:User)-[:ORDERS]->(recommended:Product) 
WHERE NOT (user)-[:ORDERS]->(recommended) 
    AND user.id = 171 
WITH recommended, COUNT(DISTINCT otherUser) AS frequency 
RETURN recommended.id, frequency 
ORDER BY frequency DESC 
LIMIT 200 

您的查詢在適用DISTINCT到節點每個步驟，所以它避免了這個屬性查找問題（這通常是查詢中最昂貴的部分，尤其是大型的）。但是，手動切斷這樣一條長路徑可能會減慢查詢速度，因爲規劃人員可能無法看到它可能對整個路徑執行的優化。幾乎在每個實例中，單個長路徑比多個短路徑更可取。關於如何走得更快，請記住，圖表可能是資源密集型的，所以如果您在筆記本電腦或小型雲實例上並行運行它，也許可以查看performance tuning以查看是否你可能會窒息你的數據庫。

編輯：如果你有一個密集的連接圖（大量:User s之間共享:Product節點），那麼你可能會產生第一個查詢不必要的結果行。如果PROFILE顯示在您的查詢的中間大量結果行的，試試這個替代方案來代替：

MATCH (user:User {id:171})-[:ORDERS]->(:Product)<-[:ORDERS]-(otherUser:User) 
WITH DISTINCT user, otherUser 
MATCH (otherUser)-[:ORDERS]->(recommended:Product) 
WHERE NOT (user)-[:ORDERS]->(recommended) 
WITH recommended, COUNT(DISTINCT otherUser) AS frequency 
RETURN recommended.id, frequency 
ORDER BY frequency DESC 
LIMIT 200 

這確保每個otherUser節點僅建議檢查一次，而第一次查詢將處理每個otherUser每:Product一次，他們與用戶分享。這是關於你的圖表的一種信息，PROFILE可以幫助你出現;找到一個結果行數爆炸的步驟，看看是否有辦法將其分解以減少總行數。