Плохая производительность вложения пространственного слоя

Question

Так что я попытался загрузить некоторые почтовые индексы и адресные данные в neo4j. Я создаю уникальное ограничение, и есть три ярлыка. POSTCODE, ADDRESS и REGION. REGION и POSTCODE имеют уникальные ограничения на их одно свойство. Запрос, который мы используем для вставки, будет MERGE REGION, MERGE POSTCODE СОЗДАТЬ АДРЕС, а затем СОЗДАТЬ ОТНОШЕНИЯ. Идея состоит в том, чтобы иметь возможность видеть, какие почтовые индексы находятся в каком регионе, и сколько адресов использует один почтовый индекс, поэтому поведение MERGE важно.

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

Что я могу сделать, чтобы улучшить это, не отказываясь от поведения MERGE? Является ли это следствием ограничения UNIQUE? Теоретически не должно быть разницы между наличием уникального ограничения и просто индексированием при использовании слияния, поскольку существует только одно свойство. В любом случае, слияние должно знать, существует ли свойство, чтобы решить, сходиться ли.

Я знаю, что могу делать разные вещи, чтобы ускорить вставку, использовать загрузчик csv и т. Д. Меня интересует улучшение асимптотической производительности. Я думал, что уникальные ограничения должны иметь временную стоимость O (log (n)), а не O (n), и это потенциально имеет огромное значение.

РЕДАКТИРОВАТЬ: Дальнейшие исследования показали, что проблема не относится к индексу, а вложение R-дерева в пространственный слой. Конкретный код используется для вставки используются встроенный API, не Cypher, и фрагмента коды:

graphDB.index().forNodes(s).add(node, "dummy", "variable"); 

постепенно становится медленнее O (N), поскольку размер дерева расширяется. Это, по-видимому, ожидаемое поведение для R-деревьев. Это занимает около 0,0005 * Количество узлов в слое. При удалении пространственной вставки он на порядок быстрее и не показывает никакого масштабирования. Я предполагаю, что уменьшение происходит только из-за прогрева кеша после запуска.

Incidentially, я использую следующий код для запуска пространственного индекса:

Map<String, String> config = SpatialIndexProvider.SIMPLE_POINT_CONFIG; 
      Transaction tx = graphDB.beginTx(); 
      IndexManager indexMan = graphDB.index(); 
      try{ 
       indexMan.forNodes(lab.name(), config); 
       tx.success(); 
      } finally { 
       tx.close(); 
      } 

Как это делает дает точку входа Cypher, но есть qualititive различия между индексами и слои? Будет ли уровень лучше, чем индекс, или оба они поддерживаются одинаковыми R-деревьями.

Предположение на этот вопрос: Neo4J huge performance degradation after records added to spatial layer кажется, что я должен поместить все узлы в базу данных, прежде чем я начну пространственный слой, так как он будет индексировать намного быстрее, чем инкрементная вставка.

Плохо Попробуй завтра.

Answer 1

Какая версия Neo4j вы используете?

Да, пожалуйста, поделитесь своими запросами.

Если вы используете LOAD CSV, вы будете иметь более высокую производительность при создании узлов в отдельности сначала MERGE, а затем во втором проходе создают отношения с MATCH ... MATCH ... CREATE ...

Смотри также: http://www.markhneedham.com/blog/2014/10/23/neo4j-cypher-avoiding-the-eager/

Если вы не» t использовать LOAD CSV, вы выполняете отдельные небольшие транзакции? Если это так, имеет смысл загрузить их, например, 1000 операций за транзакцию.

Можете ли вы также проверить, что ваши ограничения на месте, с «: схемой» в браузере или «схемой» в оболочке?

И проверьте, что индекс/ограничение фактически используется путем профилирования вашего запроса в оболочке? Просто прикрепите его profile.