我有大约3.5M节点带有标签A和大约400个带有标签B的节点。
标签B的节点已经有(b1:B)-(c:CONNECTS)->(b2:B)
之类的有向关系,现在我需要通过比较节点属性和:CONNECTS
关系属性来添加3.5M其他类型的关系。
我的陈述如下:
MATCH (a:A)
MATCH (c:C)
MATCH (b1:B {id: a.a1_id})-[rl:CONNECTS*1..21]->(b2:B {id: a.b2_id}) WHERE ALL(x in rl WHERE x.connect_id = c.connect_id)
MATCH (new_a:B)-[r:TO]->(new_b:B) WHERE r in rl
CREATE (new_a)-[:TICKET {ticket_id: ID(a)}]->(new_b)
这句话非常慢,只是挂断了。我甚至试图做一些提到here的性能调优,特别是我将堆大小分配到16GB。
我觉得很奇怪它无法处理这么大的数据。我错过了什么?我试图以不同的方式建模并减少关系查询并使用更多的模式索引,但由于我拥有的数据类型以及我想在所有数据存在后执行的查询类型,我没有做太多不同。
我还尝试使用csv import创建A节点时使用定期提交。它有同样的问题。
我希望我足够清楚。我真的很感激一些投入。谢谢。
答案 0 :(得分:1)
标签A,B,C是什么? CONNECTS关系也没有意义。 像这样的查询是可以理解的而不是相反的!
// generates 3.5M rows
MATCH (a:A)
// generates x-times 3.5M rows
// you never use that C except for checking an connect id?
MATCH (c:C)
// many million times execute this variable length expand
MATCH (b1:B {id: a.a1_id})-[rl:CONNECTS*1..21]->(b2:B {id: b2_id})
WHERE ALL(x in rl WHERE x.connect_id = c.connect_id)
// lookup by relationship is very bad esp. as you looking over a cross product of all 400x400 B's
MATCH (new_a:B)-[r:TO]->(new_b:B) WHERE r in rl
// why do you store the id of a on this self!!-relationship?
CREATE (new_b)-[:TICKET {ticket_id: ID(a)}]->(new_b);
b2_id来自哪里?
也许是这样的:
MATCH (a:A)
MATCH (b1:B {id: a.a1_id})
MATCH (b2:B {id: {b2_id}})
MATCH (b1)-[rels:CONNECTS*..21]->(b2)
WHERE ALL(x in tail(rels) WHERE x.connect_id = head(rels).connect_id)
UNWIND rels AS r
WITH a,startNode(r) as new_a, endNode(r) as new_b
CREATE (new_a)-[:TICKET {ticket_id: ID(a)}]->(new_b);