Neo4J сохранить производительность запросов (GrapheneDB) - PullRequest
0 голосов
/ 10 марта 2020

Я создал приложение. Net, которое использует графическую базу данных Neo4J (с GrapheneDB в качестве поставщика). У меня возникают проблемы с производительностью при сохранении нового графического объекта. Я не храню историю графика, поэтому каждый раз, когда я сохраняю, я сначала удаляю старый, включая узлы и отношения, а затем сохраняю новый. Я еще не проиндексировал свои узлы. Я не думаю, что это проблема, потому что загрузка нескольких из этих графиков за один раз очень быстрая.

Мой метод сохранения проходит по каждой ветви и объединяет узлы и связи. (Я оставил отношения из каждого шага для чистоты). После создания полного запроса код выполняется за один раз.

  1. объединить узел root 37 и узел 4
  2. объединить узел типа 12-17 с 4
  3. объединить узел типа 2 18-22 с 4
  4. объединить 2 с 37
  5. объединить 7-11 с 2
  6. объединить 5 с 37 (создает отношения)
  7. объединить 23-26 с 5
  8. объединить 6 с 37 (создает отношения)
  9. объединить 30-27 с 6

Узлы 2, 4, 5 6 могут иметь 100-200 листовых узлов. У меня есть около 100 таких графиков в моей базе данных. Это сохранение может занять 10-20 секунд на производстве, а иногда и время ожидания.

enter image description here

Я пытался сохранить другой способ, и это занимает больше времени но время ожидания не такое частое. Сначала я создаю группы узлов. Каждый узел хранит идентификатор root 37. Каждая группа создается в отдельном исполнении. После создания узлов я создаю отношения, выбирая дочерние узлы и узел root. Это разбивает запрос на отдельные меньшие запросы.

Как я могу улучшить производительность этого сохранения? Загрузка 30 из этих графиков занимает 3-5 секунд. Следует также отметить, что сохранение стало значительно менее производительным, поскольку было добавлено больше данных.

1 Ответ

1 голос
/ 11 марта 2020

Поскольку вы заранее удаляете все узлы (и их связи), вам вообще не следует использовать MERGE, так как для этого требуется много сканирования (без соответствующих индексов), чтобы определить, существует ли каждый узел.

Попробуйте вместо этого использовать CREATE (если CREATE s не создают дубликаты).

...