Neo4j的創建邊緣

的列表我有雙，其中ID是節點的數字小id和ID的流是相鄰節點的ID的列表。我使用此查詢從這樣的流UPSERT節點：Neo4j的創建邊緣

WITH ${ids.mkString("[", ",", "]")} as ids 
UNWIND ids as u2id 
MERGE (u1:User {Id:${id}}) 
MERGE (u2:User {Id:u2id}) 
CREATE UNIQUE p = (u1) - [:FRIEND] -> (u2)

，我有索引標識標籤上

CREATE INDEX ON :User(Id)

的IDS列表長度平均約爲100-200。

現在有約6000萬個節點和mil。數據庫中的邊。插入的速度大約是每秒對。 Neo4j運行在Core i5,28Gb RAM和2Tb WD Black的專用機器上。

我不知道如何優化插入查詢或改善硬件的任何提示。

來源

2017-08-03 De Pizzottri

幾個問題... 1）是流不變（這並不是說你可以在一個CSV文件中的所有更新說的和做LOAD CSV）？ 2）用戶（Id）僅僅是一個索引還是唯一的約束？ 3）你是否真的創建了新用戶（MERGE暗示）？ 4）你可以添加一個這樣的執行PROFILE的擴大圖像？ –

對不起，遲來的答案，1）是真正的流2）索引3）是，創建4）不幸的是數據庫目前無法訪問 –

這些漸進式更改應使查詢更快。

執行MERGEu1的只是一次

通過UNWIND之前移動的u1的MERGE，它只會被執行一次（而不是每一次u2id值）。

MERGE (u1:User {Id:${id}}) 
WITH u1, ${ids.mkString("[", ",", "]")} as ids 
UNWIND ids as u2id 
MERGE (u2:User {Id:u2id}) 
CREATE UNIQUE (u1)-[:FRIEND]->(u2)

此外，使用MERGE代替CREATE UNIQUE

您的關聯性創建使用情況應該是MERGE以及CREATE UNIQUE滿足的（因爲你確保事先存在的兩個端點）。在我的分析中，我看到MERGE使用較少的數據庫命中（您的里程可能會有所不同，具體取決於您的數據庫特性和neo4j版本）。
```
MERGE (u1:User {Id:${id}}) 
WITH u1, ${ids.mkString("[", ",", "]")} as ids 
UNWIND ids as u2id 
MERGE (u2:User {Id:u2id}) 
MERGE (u1)-[:FRIEND]->(u2) 
```

來源

2017-08-03 22:32:44 cybersam

感謝您的建議，移動MERGE以外UNWID真的加快查詢。但是，當節點的數量變成~1億密爾。 Node4j進程開始交換並且速度急劇下降，所以我們決定寫入文件並稍後處理它們:( –

Neo4j的創建邊緣

回答

相關問題