我正在使用LOAD CSV
命令合并大批约500,000个关系:
LOAD CSV WITH HEADERS FROM 'http://file.csv'
MATCH (a:Label {uid: csv.uid1}),(b:Otherlabel {uid: csv.uid2})
MERGE (a)-[:TYPE {key1: csv.key1}]->(b)
uid
个属性都有UNIQUE
个约束。
CSV文件如下所示:
uid1,uid2,key1
123,abc,some_value
456,def,some_value
当每边有许多不同的节点时,通常非常快(<1分钟)。
但是当我加载一个a
节点连接到许多不同b
节点的批处理时,性能会急剧下降。 uid1
始终相同,但架构约束仍然存在。 ~30,000个关系需要~8分钟才能加载。
我在这里遗漏了什么吗?什么可以解释MERGE
多对多&#39;中的巨大性能差异?人际关系与一对多&#39;?
答案 0 :(得分:0)
正如我在该问题的评论中所提到的,我使用uid1和uid2的唯一随机值创建的~300,000行CSV文件验证了此行为。 @MartinPreusse然后提到,如果您将查询更改为使用CREATE而不是MERGE,则查询速度很快。这一观察让我意识到发生了什么。
减速是由于需要扫描&#39; a&#39;的关系列表所致。每次执行MERGE时节点。执行CREATE时,将添加关系而不先测试以查看关系是否已存在。当关系列表保持简短(第一种情况)时,扫描关系列表几乎没有影响。当关系列表增长很长时(第二种情况),重复扫描不断增长的列表主导着这个过程。在我的测试中,我使用MERGE子句将所有300,000个节点链接到单个节点,并且花费了数小时。
如果您不必担心创建重复关系,则可以毫无顾虑地使用CREATE。即使重复是一个问题,使用CREATE然后制作一个将删除重复项的查询可能会更快。