python - 子图与neo4j和py2neo的缓慢合并

Question

我正在做一个项目，我需要对远程图执行许多子图合并操作。子图的某些元素可能已经存在于远程图中。我正在使用 py2neo v3 和 neo4j。

我尝试使用 neo4j 的 create 和 merge 功能，但两者的表现都出奇的差。更令人惊讶的是，合并子图所花费的时间似乎随着节点数和关系数呈二次方增长!当子图太大时，事务挂起。我应该说的一件事是我检查了一下，并不是 py2neo 生成了许多随子图的大小呈二次方增长的密码语句。因此，如果出现问题，要么与我使用这些技术的方式有关，要么与 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 月)的某个时候发布。