Медленный запрос индекса lucene neo4j

Я извлекаю данные из индекса в моей базе данных neo4j, и у меня возникают проблемы со временем выполнения. Я пытаюсь выполнить запрос, в котором я просто подсчитываю полученные значения. В моей производственной базе данных я делаю более сложные вычисления. Во всяком случае, мой запрос выглядит примерно так,

START person = node:user_index('muncipalityCode:(1278 OR 1285 OR 1283 OR 1293 OR 1284 OR 1261 OR 1282 OR 1262 OR 1281 OR 1280 OR 1273) ')
return count(person)

Счетчик возвращает 278418 примерно через 20 секунд (2,5-3 секунды во второй раз, когда кэш теплый). Конечно, я возвращаю довольно большой набор данных. Однако он не огромен.

Могу ли я где-нибудь уменьшить это узкое место или некоторые параметры конфигурации, которые мне следует изучить? Я пытался разогреть кеш при запуске, но не могу поместить все данные в оперативную память на моем рабочем сервере, поэтому это имеет неприятные последствия (у моего сервера 16 ГБ ОЗУ).

Моя база данных имеет следующие атрибуты. 10 329 245 узлов 97 923 564 свойства 50 697 532 связи


java neo4j cypher
person Silfverstrom    schedule 06.02.2013    source источник
comment
Можете ли вы перевести этот код в Java API и определить время, чтобы увидеть, является ли он индексом или счетчиком?   -  person Nicholas    schedule 07.02.2013
comment
я думаю, что условие ИЛИ может быть проблемой (по крайней мере, это в sql, где иногда индекс опускается, когда есть много условий ИЛИ). Если вы разделите запрос на отдельные фазы START, как это, это поможет? START person1 = node:user_index('muncipalityCode:1278), person2=node:user_index('muncipalityCode:1285 ),person3 = .... RETURN count(person1)+count(person2)+count(person3)...   -  person ulkas    schedule 07.02.2013
comment
Сколько человек возвращено? И можете ли вы смоделировать почтовые индексы как индексированные узлы и подключить к ним людей? Тогда запрос lucene должен вернуть только 15 записей. Lucene также хранит свои результаты, поэтому они также могут быть связаны с использованием памяти и GC.   -  person Michael Hunger    schedule 20.02.2013
comment
@MichaelHunger Как вы думаете, было бы быстрее смоделировать почтовые индексы как узлы, чем использовать индекс Lucene? Почтовые индексы будут иметь от 10 до 100 тыс. отношений каждый. Из того, что я видел, извлечение больших наборов отношений из одного узла довольно сильно замедляет шифровальные запросы (хотя я уверен, что могу ошибаться =))   -  person Silfverstrom    schedule 23.02.2013
comment
На самом деле часть соответствия запроса Cypher выполняется довольно быстро. Вы просто хотите избежать использования предложений where. Итак, проиндексируйте почтовые индексы, загрузите те, которые вам нужны, в START, как вы сделали сейчас, за исключением того, что загрузите почтовые индексы вместо людей, затем выполните MATCH person-[:muncipality_code]-›zipcode RETURN count(person) и посмотрите, будет ли это быстрее, но я верю, что это будет.   -  person Pieter-Jan    schedule 12.04.2013

Ответы (1)


arrow_upward
2
arrow_downward

Я бы использовал Luke, чтобы проверить, связана ли проблема с индексом или где-то еще в коде. Если соответствующий запрос Luke выполняется быстро, то, скорее всего, проблема заключается в чем-то другом.

person Mark Leighton Fisher    schedule 07.02.2013