【发布时间】:2018-11-06 06:01:46
【问题描述】:
我之前使用过 neo4j 的批量导入来处理中小型原型数据集,它的效果非常棒。我现在使用它来导入包含约 100 GB 的完整数据集,分为 7 个 csv 文件:4 个节点 csv 文件(每个文件具有不同的标签)和 3 个边缘 csv 文件。标题是每个文件的第一行,我使用以下命令(在 Windows 10 上的 Neo4j 桌面终端中):
SET DATA=D:\Neo4jdb\data
.\bin\neo4j-admin import ^
--mode=csv ^
--database=full_kb.db ^
--ignore-duplicate-nodes true ^
--nodes %DATA%\nodes_assoc.csv ^
--nodes %DATA%\nodes_article.csv ^
--nodes %DATA%\nodes_term.csv ^
--nodes %DATA%\nodes_chunk.csv ^
--relationships %DATA%\edges_IN_ASSOC.csv ^
--relationships %DATA%\edges_IN_ARTICLE.csv ^
--relationships %DATA%\edges_IN_CHUNK.csv
节点在大约 40 分钟后成功导入,但是一旦 SORTING 开始,这已经最大化 CPU 使用率(恒定 100%),并且已经持续了超过 24 小时(技术上它没有卡住,因为 CPU 仍在使用中为 100%。但我无法再看到状态,因为由于 CPU 使用率高,终端全部空白 - 可能是一个错误)。
我遇到similar queries on SO 的答案表明“所以基本上,理想情况下,每种类型的节点总是有单独的文件,而 rel 将给出最快的结果(至少在我的测试中)”这正是我的数据的结构.这也与this SO question 不同,因为节点已成功导入,并且我还验证了我的文件是否有引号——这就是该问题的答案。每个文件的标题如下:
nodes_chunk.csv (30 GB)
id:ID(chunk),:LABEL
nodes_term.csv (15 GB)
id:ID(term),:LABEL
nodes_article.csv (5 GB)
id:ID(article),title,filename,:LABEL
nodes_assoc.csv (11 GB)
id:ID(assoc),:LABEL
edges_IN_CHUNK.csv (15 GB)
:START_ID(assoc),:END_ID(chunk)
edges_IN_ARTICLE.csv (2 GB)
:START_ID(chunk),:END_ID(article)
edges_IN_ASSOC.csv (2 GB)
:START_ID(term),:END_ID(assoc)
更新:
我已从每个文件中删除重复项,以确保这不是限制步骤,但问题仍然存在。资源现在不再受到限制,因为 CPU 和内存使用率低于 30%(与之前使用 100% 的 CPU 相比),并且未使用磁盘。进度条显示没有任何改进,因此导入根本没有进行。
更新 2: 我已将 neo4j 更新到 3.4,因为发行说明状态批量导入已进一步优化以加快导入速度,但问题仍然存在。对于上述 1/4 节点文件,达到 50% 后需要数小时才能移动 1%
【问题讨论】:
标签: neo4j