Neo4j：使用Cypher批量关联节点的最佳方法？

当我运行一个脚本试图批量合并特定类型的所有节点时，我得到了一些奇怪的性能结果

合并2个节点集合~42k和~26k时，性能良好且快速。 但当我将~42和~5合并时，性能会显著降低。我正在对ParentNodes进行批处理，因此~42k分为500个批。当批处理集相同但批处理集的源较高而目标集较低时，本质上合并较少的节点时，为什么性能会下降

关系查询： 业绩结果： 进程启动

开始插入联系人项目 [+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++]

42149个联系人项目的总时间：19176.87ms 每批平均时间500:213.4ms 最长批处理时间：663ms 开始插入ContactPlayer项目 [++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++]

27970个ContactPlayer项目的总时间：9419.2106ms 每批平均时间500:167.75ms 最长批处理时间：689ms 开始将联系人与ContactPlayer关联 [++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++]

将联系人与ContactPlayer关联所用的总时间：7907.4877ms 每批500的平均时间：141.151517857143ms 批次号为0的最长批次时间：883.0918ms 开始插入ContactPrefixType项目 [+]

5个ContactPrefixType项目的总时间：22.0737毫秒 每批平均时间500:22ms 最长批处理时间：22ms 已插入联系人的数据

开始将ContactPrefixType与Contact关联 [+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++]

将ContactPrefixType与Contact关联所用的总时间：376540.8309ms 每批平均时间500:4429.78643647059ms 批号为63的最长批处理时间：14263.1843ms

---

您是否可以将ID作为参数传入，而不是从图形中获取它们？查询可能看起来像

MATCH (s:ContactPlayer {ContactPrefixTypeId:{cptid})
MERGE (c:ContactPrefixType {ContactPrefixTypeId:{cptid})
MERGE c-[:CONTACT_PLAYER]->s

如果您使用RESTAPI密码资源，我认为实体应该如下所示

{
    "query":...,
    "params": {
        "cptid":id1
    }
}

如果您使用事务端点，它应该是这样的。您可以通过每个调用中的语句数以及提交前的调用数来控制事务大小。更多

---

到目前为止，我能想到的最好的方法是以下内容，这是一种针对我的环境的黑客攻击：

如果/否则条件：

如果childrenNodes.count<200->假定它们是父节点的类型标识符。。。i、 e.ContactPrefixType

否则，假设它是一个将多个项目类型关联在一起的矩阵，即ContactAddress

如果子节点<200

每个关系类型大约需要3-5秒才能完成

否则

我不确定这是最有效的方法，但在尝试了许多不同的选择之后，这似乎是最快的

统计数据：

插入带有2070977属性的225018个节点 创建464606个关系 总计：331秒

因为这是一个直接导入，我还没有处理更新，所以我假设所有关系都是正确的，不需要担心无效数据。。。但是，我将尝试将属性设置为关系类型，以便以后能够执行清理功能，即将关系类型中的父Id和子Id存储为属性以供以后参考

---

如果有人能在这方面有所改进，我会喜欢的

嗯。。我开始认为这与~42k->~26k查询中的1:1关系和另一个查询中的1:many关系有关。。。除了将源代码切换为两个集合集中最小的集合之外，我不确定如何对此进行优化。有没有一种方法可以强制执行某种不同的机制？1:many？5前缀类型id在42k个项目中平均拆分了多少个。最高关系比率为：1:41275，其中contactprefixttypeid=1。其他的包括其余的部分。我可以试着做嵌套批处理。为每个contactprefixtypeid创建一个批处理，并按范围批处理联系人列表？我会使用RANGEX，Y，但有时父节点没有我尝试匹配的属性，这将导致创建一组仅具有该属性的节点，而不是匹配0和跳过这是一个非常有趣的想法。我想我已经试过了，但我会再试一次，看看能不能让它发挥作用。我会把一些数字发回来比较。我会在几个小时后开始做这件事。快速问题：如果我没有在节点上设置唯一约束，那么如果我指定MERGE c:node{SomePropertyId:{arrayIds}，它会创建一个节点吗？在使用MERGE之前，我得到了一些奇怪的结果，其中会创建ID为的节点，最后我得到了重复的ID节点-直到我指定了唯一的constraintOk，所以这似乎不起作用：匹配父对象：Contact{ContactPrefixtTypeId:{propIdArray}}合并子对象：ContactPrefixtType{ContactPrefixtTypeId:{propIdArray}合并子对象-[r:联系人]

---

->即使我可以验证数据库中是否存在这些项，也不会创建任何关系。propIdArray是一个包含5项的数组，因为我正在发送不同的值-1-5[1,2,3,4,5]匹配c:Contact{ContactPrefixtTypeId:[1,2,3,4,5]}返回c limit 10返回0个结果，但匹配c:Contact{ContactPrefixtTypeId:1}返回c limit 10返回10。我认为它期望它是一个数组，实际上并没有捕获数组中的项。我的缺点是，我考虑的是参数映射，但它们只适用于CREATE。我已经编辑了我的答案。我不知道这是否是嵌入db的最佳方式，主要的一点是将值作为参数提供，而不是从图中逐块读取它们，或者在创建节点的同时创建关系。

{
    "query":...,
    "params": {
        "cptid":id1
    }
}

{
    "statements":[
        "statement":...,
        "parameters": {
            "cptid":id1
        },
        "statement":...,
        "parameters": {
            "cptid":id2
        }
    ]
}

MATCH (parent:{parentLabel}), 
(child:{childLabel} {{childLabelIdProperty}:parent.{parentRelationProperty}})
CREATE child-[r:{relationshipLabel}]->parent

MATCH (child:{childLabel}), 
(parent:{parentLabel} {{parentPropertyField : child.{childLabelIdProperty}})
WITH collect(parent) as parentCollection, child
WITH parentCollection[{batchStart}..{batchEnd}] as coll, child
FOREACH (parent in coll | 
CREATE child-[r:{relationshipLabel}]-parent )