子圖與neo4j和py2neo的慢速合並

Question

我正在開發一個項目，我需要在子圖上執行許多合並操作到遠程圖形上。 子圖的某些元素可能已存在於遠程圖中。 我正在使用py2neo v3和neo4j。

我嘗試使用neo4j的create和merge功能，並且兩者都得到了令人驚訝的糟糕表現。 更令人驚訝的是，合並子圖的時間似乎與節點數量和關系數量呈二次方增長！ 當子圖太大時，事務就會掛起。 我應該說的一件事是我檢查過並且不是py2neo會生成許多cypher語句，這些語句與子圖的大小成二次方。 因此，如果出現問題，可能是我使用這些技術，還是使用neo4j的實現。 我也嘗試查看py2neo生成的查詢的查詢計划，並沒有找到任何答案，為什么查詢時間如此顯着增長，但由於我相對不啟動，所以不要接受我的話。

我幾乎無法在線找到任何相關信息，所以我嘗試進行適當的基准測試，比較節點數量和子圖拓撲功能的性能，具體取決於我是使用合並還是創建操作，是否我是否使用獨特約束。 我在下面列出了我對“線性”拓撲圖得到的一些結果，這意味着關系數與節點數大致相同（它不會以二次方式增長）。 在我的基准測試中，我為隨機分配的節點和關系使用了5種不同類型的標簽，並重用了遠程圖中已存在的30％的節點。 我創建的節點只有一個屬性作為標識符，我根據是否在此屬性上添加唯一約束來報告性能。 所有合並操作都在單個事務中運行。

使用py2neo create函數查詢具有線性拓撲結構的圖形的節點數量

使用py2neo合並函數查詢具有線性拓撲的圖的節點數的函數

如您所見，所花費的時間似乎與節點（和關系）的數量呈二次方式增長。

我很難回答的問題是我是做錯了什么，還是做了我應該做的事情，或者我們應該期待neo4j對這些操作的表現。 無論如何，似乎我可以做的就是不要一次嘗試合並大的子圖，而是從批量合並節點然后關系開始。 這可能並且可行，但如果有人有任何建議或見解可以分享，我想深究這一點。

編輯

以下列出了重現上述結果的要點和其他內容。 https://gist.github.com/alreadytaikeune/6be006f0a338502524552a9765e79af6

編輯2

關注Michael Hunger的問題：

在我分享的代碼中，我嘗試為neo4j.bolt日志編寫格式化程序，以捕獲發送到服務器的查詢。 但是，我沒有系統的方法為它們生成查詢計划。

我沒有嘗試沒有docker，我沒有SSD。 但是，考慮到我為jvm分配的大小和我正在處理的圖形的大小，一切都應該適合RAM。

我使用neo4j的最新docker鏡像，所以相應的版本似乎是3.3.5

Answer 1

不幸的是，v3中的合並例程（以及其他一些例程）有點天真並且不能很好地擴展。 我為py2neo v4計划了替代方案，它構建了更高效的查詢，而不是（在合並的情況下）任意長的MERGE語句序列。 版本4應該在下個月（2018年5月）的某個時候發布。