Elasticsearch улучшает производительность запросов

Question

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

curl "http://searchbox:9200/global/user/_search?n=0&sort=influence:asc&q=user.name:Bill%20Smith" 

Даже без сортировки требуется несколько секунд. Вот подробности кластера:

1.4TB index size. 
210m documents that aren't nested (About 10kb each) 
500m documents in total. (nested documents are small: 2-5 fields). 
About 128 segments per node. 
3 nodes, m2.4xlarge (-Xmx set to 40g, machine memory is 60g) 
3 shards. 
Index is on amazon EBS volumes. 
Replication 0 (have tried replication 2 with only little improvement) 

Я не вижу каких-либо заметных скачков в CPU/памяти и т.д. Любые идеи, как это можно было бы улучшить?

Answer 1

Хорошо, несколько вещей здесь:

1. Уменьшить размер кучи, у вас есть размер кучи свыше 32gb, посвященный каждому экземпляру Elasticsearch на каждой платформе. Java не сжимает указатели на 32gb. Бросьте узлы только на 32gb, и если вам нужно, открутите еще один экземпляр.
2. Если разворачивание экземпляра другого экземпляра не является опцией, а 32gb на 3 узлах недостаточно для запуска ES, тогда вам придется ударить память кучи где-то более 48 ГБ!
3. Я бы, вероятно, придерживался настроек по умолчанию для осколков и реплик. 5 осколков, 1 реплика. Однако вы можете настроить настройки осколков, чтобы они соответствовали требованиям. Я бы сделал переиндексацию данных по нескольким индексам в нескольких разных условиях. У первого индекса будет только 1 осколок, у второго индекса будет 2 осколка, я сделаю это до 10 осколков. Запросите каждый индекс и посмотрите, какая из них лучше всего работает. Если индекс 10 осколков лучше всего работает, продолжайте увеличивать количество осколков до тех пор, пока не получите худшую производительность, тогда вы достигли предела осколка.

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

У вас также есть довольно много данных, возможно, вам стоит посмотреть и на Custom Routing.

Answer 2

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

С вашей текущей конфигурацией вы получите менее 60 ГБ кэша страниц для индекса 1,5 ТБ. С менее чем 4,2% вашего индекса в кеше страницы существует большая вероятность, что вам понадобится нажать диск для большинства ваших поисков.

Возможно, вы захотите добавить больше памяти в свой кластер, и вам также нужно тщательно подумать о количестве осколков. Просто придерживаться значения по умолчанию может привести к перекосу распространения. Если бы у вас было пять осколков в этом случае, у вас было бы две машины с 40% данных каждый, а третья - всего 20%. В любом случае вы всегда будете ждать самую медленную машину или диск при распределенных поисковых запросах. Эта статья о Elasticsearch in Production идет немного глубже, чтобы определить правильный объем памяти.

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