Подсчитайте производительность с Neo4j, используя встроенный API Java

Я начал тестировать Neo4j для программы и столкнулся с некоторыми проблемами производительности. Как упоминалось в заголовке, Neo4j напрямую встроен в код Java.

Мои графики содержат около 4 миллионов узлов и несколько сотен миллионов связей. Мой тест состоит в том, чтобы просто отправить запрос, подсчитывающий количество входящих отношений для узла.

Эта программа использует процедуру ExecutionEngine выполнить для отправки следующего запроса:

start n=node:node_auto_index(id="United States") match s-[:QUOTES]->n return count(s)

Просто добавив несколько отпечатков, я могу увидеть, сколько времени занял этот запрос, что обычно составляет около 900 мс, что очень много.

Что меня больше всего удивляет, так это то, что в ответ я получаю «время выполнения запроса», которое действительно отличается.

Например, запрос вернул:

+----------+
| count(n) |
+----------+
| 427738   |
+----------+
1 row
1 ms 

Согласно этому ответу, я понимаю, что Neo4j потребовал 1 мс для запроса, но когда я распечатываю некоторые сообщения журнала, я вижу, что на самом деле это заняло 917 мс.

Я предполагаю, что 1 мс равно времени, необходимому для поиска индексированного объекта «Соединенные Штаты», что означает, что Neo4j требуется около 916 мс для остальных, например, для подсчета количества отношений. В этом случае, как я могу получить производительность геттера для этого запроса?

Заранее спасибо!


person A_dit_rien    schedule 18.02.2013    source источник
comment
Вы можете сохранить количество ссылок на узле во время создания или обновить его при добавлении/удалении отношений.   -  person Michael Hunger    schedule 20.02.2013


Ответы (2)


Таймеры запросов были сломаны в 1.8.1 и 1.9.M04, когда были исправлены ленивые вещи в шифровании. (Определенно стоящая сделка для большинства случаев использования). Но да, я думаю, что это будет исправлено в ближайшее время.

А пока вам придется рассчитать время внешне.

Обновление: Что касается вашего вопроса о том, разумно ли это время... По сути, для их подсчета необходимо просканировать все ~ 400 тыс. узлов. Это, вероятно, разумно, даже если кеш прогрет и все они помещаются в оперативную память. Наличие таких «суперузлов» обычно не является лучшей практикой, если этого можно избежать, хотя в будущих версиях будет сделано много улучшений для этого случая (по крайней мере, я так слышал).

person Eve Freeman    schedule 18.02.2013
comment
Хороший улов, я на самом деле использую 1.8.1. большое спасибо! Что касается производительности, 917 мс кажется нормальным для этого типа запроса? Любая идея о том, как я могу улучшить это? - person A_dit_rien; 18.02.2013
comment
Спасибо за обновления. На самом деле этот график останется статичным в моем приложении, поэтому мне лучше хранить количество входящих и исходящих сообщений в другом месте! Лучший - person A_dit_rien; 19.02.2013

Убедитесь, что вы не измеряете первый запрос b/c, который измеряет только то, сколько времени требуется для загрузки данных с диска в память.

Убедитесь, что у Neo4j достаточно памяти для кэширования ваших данных.

И попробуйте этот запрос, если он быстрее.

start n=node:node_auto_index(id="United States") 
return length(()-[:QUOTES]->n) as cnt
person Michael Hunger    schedule 20.02.2013