Раньше я использовал массовый импорт neo4j для набора прототипов данных малого / среднего размера, и он работал как шарм.Сейчас я использую его для импорта полного набора данных, который состоит из ~ 100 ГБ, разделенных на 7 файлов CSV: файлы CSV с 4 узлами (каждый файл с отдельной меткой) и 3 файла CSV с краями.Заголовок - это первая строка каждого файла, и я использую следующую команду (в Neo4j Desktop Terminal в Windows 10):
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 минут, но после начала сортировки,это максимизировало использование ЦП (постоянное значение 100%) и продолжалось более 24 часов (технически оно не зависло, поскольку ЦП по-прежнему используется на уровне 100%. Я больше не могу видеть состояние, хотя, поскольку терминал полностью пуст)из-за высокой загрузки процессора - вероятно, ошибка).
Я сталкивался с подобными запросами на SO с ответами, подсказывающими: «В общем, в идеале всегда наличие отдельных файлов для каждого типа узла и rel даст самые быстрые результаты (по крайней мере, в моих тестах) "именно так структурированы мои данные.Это также отличается от этого SO вопроса тем, что узлы были успешно импортированы, и я также проверил мой файл на наличие кавычек - что является ответом на этот вопрос.Заголовки для каждого файла:
node_chunk.csv (30 ГБ)
id:ID(chunk),:LABEL
node_term.csv (15 ГБ)
id:ID(term),:LABEL
node_article.csv (5 ГБ)
id:ID(article),title,filename,:LABEL
node_assoc.csv (11 ГБ)
id:ID(assoc),:LABEL
dge_IN_CHUNK.csv (15 ГБ)
:START_ID(assoc),:END_ID(chunk)
dge_IN_ARTICLE.csv (2 ГБ)
:START_ID(chunk),:END_ID(article)
dge_IN_ASSOC.csv (2 ГБ)
:START_ID(term),:END_ID(assoc)
ОБНОВЛЕНИЕ:
Я удалил дубликаты из каждого файла, чтобы убедиться, что это не ограничивающий шаг,но проблема все еще сохраняется.Ресурсы больше не ограничиваются, поскольку загрузка ЦП и памяти ниже 30% (в отличие от ранее, когда ЦП использовался на 100%), а диск не использовался.Индикатор выполнения не показывает никаких улучшений, поэтому импорт вообще не выполняется.
ОБНОВЛЕНИЕ 2: Я обновил neo4j до 3.4, так как массовый импорт состояния примечаний к выпуску был дополнительно оптимизирован для более быстрого импорта, но проблема сохраняется.Для указанных выше 1/4 узловых файлов требуется час для перемещения на 1% после достижения 50%