Cypher 加载 CSV 急切且动作持续时间长

Question

我正在加载一个包含 85K 行 - 19M 的文件， 服务器有 2 个内核，14GB RAM，运行 centos 7.1 和 oracle JDK 8 使用以下服务器配置可能需要 5-10 分钟：

dbms.pagecache.memory=8g                  
cypher_parser_version=2.0  
wrapper.java.initmemory=4096  
wrapper.java.maxmemory=4096

安装在 /etc/fstab 中的磁盘：

UUID=fc21456b-afab-4ff0-9ead-fdb31c14151a /mnt/neodata            
ext4    defaults,noatime,barrier=0      1  2

将此添加到 /etc/security/limits.conf：

*                soft      memlock         unlimited
*                hard      memlock         unlimited
*                soft      nofile          40000
*                hard      nofile          40000

将此添加到 /etc/pam.d/su

session         required        pam_limits.so

将此添加到 /etc/sysctl.conf：

vm.dirty_background_ratio = 50
vm.dirty_ratio = 80

通过运行禁用日志：

 sudo e2fsck /dev/sdc1
 sudo tune2fs /dev/sdc1
 sudo tune2fs -o journal_data_writeback /dev/sdc1
 sudo tune2fs -O ^has_journal /dev/sdc1
 sudo e2fsck -f /dev/sdc1
 sudo dumpe2fs /dev/sdc1

除此之外， 在运行分析器时，我得到了很多“渴望”，我真的不明白为什么：

 PROFILE LOAD CSV WITH HEADERS FROM 'file:///home/csv10.csv' AS line
 FIELDTERMINATOR '|'
 WITH line limit 0
 MERGE (session :Session { wz_session:line.wz_session })
 MERGE (page :Page { page_key:line.domain+line.page }) 
   ON CREATE SET page.name=line.page, page.domain=line.domain, 
 page.protocol=line.protocol,page.file=line.file


Compiler CYPHER 2.3

Planner RULE

Runtime INTERPRETED

+---------------+------+---------+---------------------+--------------------------------------------------------+
| Operator      | Rows | DB Hits | Identifiers         | Other                                                  |
+---------------+------+---------+---------------------+--------------------------------------------------------+
| +EmptyResult  |    0 |       0 |                     |                                                        |
| |             +------+---------+---------------------+--------------------------------------------------------+
| +UpdateGraph  |    9 |       9 | line, page, session | MergeNode; Add(line.domain,line.page); :Page(page_key) |
| |             +------+---------+---------------------+--------------------------------------------------------+
| +Eager        |    9 |       0 | line, session       |                                                        |
| |             +------+---------+---------------------+--------------------------------------------------------+
| +UpdateGraph  |    9 |       9 | line, session       | MergeNode; line.wz_session; :Session(wz_session)       |
| |             +------+---------+---------------------+--------------------------------------------------------+
| +ColumnFilter |    9 |       0 | line                | keep columns line                                      |
| |             +------+---------+---------------------+--------------------------------------------------------+
| +Filter       |    9 |       0 | anon[181], line     | anon[181]                                              |
| |             +------+---------+---------------------+--------------------------------------------------------+
| +Extract      |    9 |       0 | anon[181], line     | anon[181]                                              |
| |             +------+---------+---------------------+--------------------------------------------------------+
| +LoadCSV      |    9 |       0 | line                |                                                        |
+---------------+------+---------+---------------------+--------------------------------------------------------+

所有标签和属性都有索引/约束 谢谢您的帮助 利奥

Answer 1

何利奥，

我们试图在这里解释 Eager Loading：

Marks 原博文在这里：http://www.markhneedham.com/blog/2014/10/23/neo4j-cypher-avoiding-the-eager/

Rik 试图用更简单的方式解释它：

http://blog.bruggen.com/2015/07/loading-belgian-corporate-registry-into_20.html

试图理解“急切操作”

我之前读过这方面的内容，但直到 Andres 再次向我解释时才真正理解它：在所有正常操作中，Cypher 都会延迟加载数据。例如，参见手册中的这个页面 - 它基本上只是在执行操作时尽可能少地加载到内存中。这种懒惰通常是一件非常好的事情。但它也会给你带来很多麻烦——正如迈克尔向我解释的那样：

“Cypher 试图履行不同操作的合同 一个语句内不相互影响。否则你可能 出现不确定的行为或无限循环。想象一个 像这样的声明：
MATCH (n:Foo) WHERE n.value > 100 CREATE (m:Foo {m.value = n.value + 100});

如果这两个语句不是 隔离，那么 CREATE 生成的每个节点都会导致 MATCH 再次匹配等等。一个无限循环。这就是为什么在这种情况下，Cypher 急切地运行所有 MATCH 语句以耗尽所有 中间结果被累积并保存（在内存中）。

通常 大多数操作都不是问题，因为我们大多只匹配少数几个 最多十万个元素

使用 LOAD CSV 导入数据时， 但是，此操作将拉入 CSV 的所有行（其中 可能是数百万），急切地执行所有操作（可能是 数以百万计的创建/合并/匹配）并保留中间 导致内存为行中的下一个操作提供信息。

这也是 有效地禁用 PERIODIC COMMIT 因为当我们到达末尾时 语句执行所有创建操作都已经有了 发生了，巨大的 tx-state 已经积累。”

这就是我的加载 csv 查询的情况。 MATCH/MERGE/CREATE 导致将一个急切的管道添加到执行计划中，并且它有效地禁用了“使用定期提交”对我的操作进行批处理。显然，即使使用看似简单的 LOAD CSV 语句，也有不少用户遇到了这个问题。很多时候你可以避免它，但有时你不能。”