Вместо создания соответствующего индексного запроса требуется много времени, однако запись в neo4 достаточно быстрая

Question

Я использую neo4j-community-3.5.3 сервер в системе с 64 ГБ ОЗУ и 32 ядрами.

Размер моей базы данных в настоящее время составляет 160 ГБ, и он растет как 1,5 ГБ каждый день.Я держу 12 ГБ в кэше страниц и 8 ГБ в куче.

Помимо ограничения уникальности, я также создаю индексы для некоторых свойств моего узла.Поскольку в текущей neo4j версии lucene_native-1.0 индексация устарела, я использую значение по умолчанию native-btree-1.0.

. Поэтому проблема, с которой я сталкиваюсь, заключается в том, что моя производительность записи очень хорошая.Но при чтении результата запроса вместо запроса с использованием индексов результат приходит около 1 минуты.

Мой размер индекса почти 21 ГБ.Размер моей базы данных постоянно растет, но я не получаю производительность запросов, как я ожидал.

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

Вот пример моего запроса с индексированием и некоторыми профилями:

PROFILE
OPTIONAL MATCH (u1:USER)<-[p:MENTIONS]-(tw:TWEET)<-[m:POST]-(u2:USER)
USING INDEX tw:TWEET(date)
WHERE tw.date='2019-03-03' AND u1.author_screen_name='xxx'
RETURN
  u1.author_screen_name as mentioned_author,
  u2.author_name as mentioned_by_author,
  count(*) AS weight
ORDER BY weight DESC LIMIT 20

Query_profile1_using_indexing

Query_profile2_using_indexing

Query_profile3_using_indexing

А вот запрос без индексации и некоторые профили:

PROFILE
OPTIONAL MATCH (u1:USER)<-[p:MENTIONS]-(tw:TWEET)<-[m:POST]-(u2:USER)
WHERE tw.date='2019-03-03' AND u1.author_screen_name='xxx'
RETURN
  u1.author_screen_name as mentioned_author,
  u2.author_name as mentioned_by_author,
  count(*) AS weight
ORDER BY weight DESC LIMIT 20

Query_profile1_without_using_indexing

Query_profile2_without_using_indexing

Query_profile3_without_using_indexing

1048равно 880572 мсек. Использование индексации требует времени, равного 57674 мсек для того же запроса.

Answer 1

В любом случае вы делаете свои прогнозы одновременно с агрегацией, что неэффективно.Прежде всего, так как есть только один u1, спроектируйте для этого имя author_screen_name в начале, в то время как ваша мощность будет только в одной строке.

Затем, после совпадения, выполните агрегацию, упорядочение и ограничение.на основе самих узлов и после того, как ваши результаты агрегированы, ТО делайте прогнозы, чтобы вы выполняли минимальный объем работы;вы не хотите делать доступ к свойству для тонны строк, которые вы собираетесь отбросить только тогда, когда получите ограниченный набор результатов:

MATCH (u1:USER)
WITH u1, u1.author_screen_name as mentioned_author
OPTIONAL MATCH ...
...
WITH mentioned_author, u2, count(*) AS weight 
ORDER BY weight DESC 
LIMIT 20
RETURN mentioned_author, u2.author_name as mentioned_by_author, weight