我之前使用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%(与之前CPU使用率为100%相比),并且未使用磁盘。进度条根本没有显示任何改进,因此导入根本没有进展。
更新2: 我已将neo4j更新为3.4,因为发布说明状态批量导入已进一步优化以加快导入速度但问题仍然存在。对于上述1/4节点文件,达到50%后需要花费数小时才能移动1%
答案 0 :(得分:0)
我有类似的问题。解决方案位于重复节点上。我对其进行了预处理,以删除所有重复项,并且一切正常。我希望这是有用的