Neo4j 2.1.0-M01严重失败，树图为830万片叶子

Question

（已经在Github上打开了一个案例#2250，但这里可能有人有解决方案？）他讲故事。我们有一个数据集，它只是一个具有

• 级别为0的单个根节点（有时它的ID（root）=0，因为我们从空数据库开始）

我们正在使用LOAD CSV加载数据，其中每一行创建一个节点和与前一级节点的关系。Neo4j是一个2.1.0-M01 Enterprise for Startups，集群有3个节点，每个实例有8Gb内存，JVM被告知使用7Gb。第一部分。我们发现，在第4级和第5级，加载的级别需要相当长的（分钟）时间才能从Cypher查询中可见。我们编写了一个简单的脚本，它只是将所有可能的路径转储到一棵树中：

START root = node(0) match path = (root)-[r*]->(b)
WITH length(path) as len, path
RETURN len, extract( n IN NODES(path) | n.payload ) AS payload_chain
ORDER BY len DESC

您很容易猜测，它返回的路径数量与数据库中的关系数量完全相等。

在第4级加载CSV完成后，web system monitor立即表示，我们有49432个关系和49433个节点，这是预期的。但上面的脚本在第一次立即运行时报告了约26k条路径，在第二次运行时报告了约35k条路径，它一步一步地准确地显示了预期的结果：49432条。到目前为止，我们使用的是周期提交5000，所以假设所有事务都应该在第一次运行脚本之前提交？同样的故事发生在第5级：第一次跑步得到了223641条路径，第二次跑步得到了293872条路径，第三次跑步得到了294482条路径，第四次跑步得到了476334条路径，第五次跑步得到了794482条路径。无论如何，我们得出结论，脚本是一个很好的诊断工具，可以确保在开始导入下一个级别之前完成上一个级别。

第二部分。我们正在将8340k节点加载到第6级（需要一些时间）。导入很好，没有错误，没有什么不好的怀疑。然后我们开始我们的测试脚本，恐怖就开始了。第一次尝试运行脚本会导致主实例失败（下面是日志）。集群告诉我们其中一个从节点已经成为主实例，并且没有发出任何错误信号。但是突然间，在下一次运行中，我们的脚本立即返回...0（零！）路径。计算关系的查询（根）-[r]-

MATCH path = (root:MyLabel {payload: 'root_payload'})-[r*]->(b)
WITH length(path) as len, path
RETURN len, extract( n IN NODES(path) | n.payload ) AS payload_chain
ORDER BY len DESC

它也返回0（零），但经过一段时间的思考。

因此，我们被（据说）损坏的数据库困住了——在重启时，实例说数据存储是正常且一致的——我们无法完成将树简单导入Neo4j的过程。我们做错了什么？或者这是一个已知的问题，在M02中已经解决了？

请你给我们提些解决方案好吗？

提前感谢！WBR，康斯坦丁

乌克兰

------ 8

Answer 1

所以你总共有大约9M个节点，这意味着对于MMIO，你需要大约

>

>

如果您的机器只有8GB RAM，您无法分配7GB堆b/c，那么您就没有空间进行内存映射

为LOAD CSV使用定期提交，例如PERIODIC COMMIT 10000 LOAD CSV...

即使加载6级（8M节点）定期提交应该只需要5分钟。

1. 如果在导入的同时运行检查脚本，它将报告已经提交的内容，因此这是预期行为

你是在主服务器还是从服务器上运行了检查脚本？您是否配置了任何推力因子？这将大大减缓进口速度？

也许在一个独立的数据库上导入数据，然后将其上载到主数据库以使用和同步？

您的查询相当昂贵，在完整的树中，它将计算8M条路径，并计算所有路径的所有负载，然后对8M行排序并返回它们。

由于超时，我不会在浏览器中执行任何操作。我可能会使用curl或具有事务endpoint的客户端来流式处理结果，并在客户端进行数据提取（如果需要的话）。

您还可以将脚本简化为：

MATCH path = (root)-[r*]->(b)
WHERE id(root) = 0
RETURN length(path) as len, extract( n IN NODES(path) | n.payload ) AS payload_chain
ORDER BY len DESC

或者像你那样更好：

MATCH path = (root:MyLabel {payload: 'root_payload'})-[r*]->(b)
RETURN length(path) as len, extract( n IN NODES(path) | n.payload ) AS payload_chain
ORDER BY len DESC

Answer 2

这是M01中的一个已知问题，将在即将发布的M02中解决。

总的来说，我们强烈鼓励尝试里程碑，但特别是编号较低的里程碑通常包含较大的更改（这一次对存储格式进行了较大修改，这就是错误的来源），因此请确保“真实”项目不依赖里程碑。