Cypher 中的意外急切查询配置文件

Unexpected Eager Query profile in Cypher

所以我正在生成一个相当大的 Neo4J 实例,我正在使用 LOAD_CSV 加载它。我已经阅读了尽可能多的关于优化查询以从查询计划中删除 Eager reads 的博客,但是我遇到了一个我无法解释的例子。

假设我们有两种类型的节点,A 和 B。每个节点都有一个唯一的 属性,名称,并带有约束条件:

CREATE CONSTRAINT ON (a:A) ASSERT a.name IS UNIQUE
CREATE CONSTRAINT ON (b:B) ASSERT b.name IS UNIQUE

现在,如果我们希望在任一类型的节点之间创建关系,如下所示:

MERGE (a:A {name:1})
MERGE (b:B {name:2})
MERGE (a)-[:REL]->(b)

我们的查询计划完全没有任何渴望。

但是,如果我们想在 2 个相同类型的节点之间创建关系:

MERGE (a:A {name:1})
MERGE (b:A {name:2})
MERGE (a)-[:REL]->(b)

个人资料返回时热切阅读!

我们可以通过将两个节点合并更改为匹配来摆脱急切,但这使我们有可能不创建我们想要创建的关系!

我的问题是为什么在同一标签的两个节点之间创建关系的这种特定情况下会发生这种情况?

我在 Neo 2.3.2 上发现了这个。

可能的解决方法:处理 csv 文件 3 次:

  1. LOAD CSV WITH HEADERS FROM <whateverurl> AS line MERGE (a:A {name:line.column1})
  2. LOAD CSV WITH HEADERS FROM <whateverurl> AS line MERGE (a:A {name:line.column2})
  3. LOAD CSV WITH HEADERS FROM <whateverurl> AS line MATCH (a:A {name:line.column1}) MATCH (b:A {name:line.column2}) MERGE (a)-[:REL]->(b)

这个应该是"eager free"。

这是预期的行为,因为 MERGEMATCHCREATE

因此,如果您在同一个标​​签上合并,第一个 MERGE 将创建 第二个 MERGE 需要查看才能正常工作。这就是为什么第一个变成了一个急切的操作。

In general eagerness happens when a preceding operations modifies the graphs so that subsequent MATCH operations are affected by it.

这与您建立的关系完全无关,即没有关系也会发生 MERGE

通常情况下,将这些操作分成多个过程是有帮助的。

然后您还可以最大限度地减少每个操作必须考虑的行数,从而减少索引查找的数量。

WITH distinct row.column as col 
MERGE (:Lable {id:col}) ...