Neo4j 空间层插入性能差

所以我试着将一些邮政编码和地址数据加载到neo4j中。我提出了一个唯一的约束，实际上有三个标签。邮政编码、地址和地区。地区和邮政编码对其单个属性具有唯一的约束。我们用于插入的查询将合并区域、合并邮政编码、创建地址，然后创建关系。这样做的目的是能够看到哪个地区有哪些邮政编码，以及有多少地址共享一个邮政编码，因此合并行为很重要

然而，我们发现，一旦数据库达到相当中等的大小，这将非常缓慢。现在我们预料到了这一点，但我们预计约束检查应该扩展为log（n）。相反，性能与数据库大小成线性关系，这是非常意外的

在不放弃合并行为的情况下，我可以做些什么来改进这一点？这是唯一约束的结果吗？理论上，当您使用merge时，具有唯一约束和仅具有索引之间应该没有区别，因为只有一个属性。无论采用哪种方式合并，都需要知道属性是否存在，以决定是否合并

我知道我可以做各种事情来加速插入，使用csv加载器，等等。我对改进渐进性能感兴趣。我认为唯一约束的时间开销应该是O（log（n）），而不是O（n），这可能会产生巨大的差异

编辑：进一步的调查表明，问题不是索引查找，而是R树插入到空间层。用于插入的特定代码使用嵌入式API，而不是密码，以及代码段：

graphDB.index().forNodes(s).add(node, "dummy", "variable");

随着树的扩展，在O（n）处逐渐变慢。这显然是R-树的预期行为。这将占用层中约0.0005*个节点。删除空间插入后，速度会加快几个数量级，并且不会显示缩放行为。我假设下降只是由于启动后缓存预热所致

顺便说一句，我使用以下代码启动空间索引：

Map<String, String> config = SpatialIndexProvider.SIMPLE_POINT_CONFIG;
            Transaction tx = graphDB.beginTx();
            IndexManager indexMan = graphDB.index();
            try{
                indexMan.forNodes(lab.name(), config);
                tx.success();
            } finally {
                tx.close();
            }

Map config=SpatialIndexProvider.SIMPLE\u POINT\u config；
事务tx=graphDB.beginTx（）；
IndexManager indexMan=graphDB.index（）；
试一试{
indexMan.forNodes（lab.name（），config）；
成功（）；
}最后{
tx.close（）；
}

因为这会给你一个密码入口点，但是索引和层之间有质量上的区别吗？一个层是否比索引具有更好的性能，或者它们都由相同的R树支持

这个问题的建议是：我应该在启动空间层之前将所有节点放入数据库，因为它的索引速度要比增量插入快得多

---

我明天再试试。

你用哪种Neo4j版本

是，请分享您的疑问。

如果使用

LOAD CSV

，则首先使用

MERGE

单独创建节点，然后在第二步中使用

MATCH创建关系时，将具有更好的性能。。。匹配。。。创建…

另见：

如果不使用LOAD CSV，您是否运行单个小型事务？ 如果是这样的话，将它们批处理到每个事务的1000个操作中是有意义的

您还可以使用浏览器中的“：schema”或shell中的“schema”验证约束是否已就位吗

并通过在shell中分析查询来检查是否实际使用了索引/约束？

---

只需在它前面加上

profile

一个唯一的约束也会添加一个索引，所以你应该在那里做得很好。这是您正在使用

加载CSV

执行的操作吗？如果您可以共享一些代码/查询，那么查看这些代码/查询会很有帮助。我们需要查看一些查询。MERGE自然会在创建之前进行查找，因此，标签和索引等加快查找速度的东西的存在似乎是相关的。还有缓存问题——你应该考虑发布配置和缓存设置的外观。最后，你能告诉我们你正在融入什么新东西吗？这总是在创造新的东西，还是只是偶尔？（参考位置也是相关的）y轴测量“加载200个图形的时间”。1图中有什么？是否只有1-6个邮政编码？它们是如何联系在一起的？您是否只是合并了邮政编码、先前存在的邮政编码之间的关系，还是什么？