Доброго времени суток!
Пропущу предысторию про тормоза )
В общем, решил понять куда уходит время в запросе.
Контрольный запрос выполняется за 1,14сек,.
Запустил его с прифилированием, и получается, что на каждой шарде:
"Родительский query time" + "rewrite_time" + "collector time" не превышает 10мс.
Т.е. даже если последовательно выполнять запрос на каждой шарде до 1,14 секунд очень далеко.
Как понять куда еще ушло время?
Профайлер запросов не всегда хорошо работает, к сожалению. Я обычно пытаюсь запускать запросы по частям - например, убираем все аггрегации, смотрим сколько времени занял запрос, добавляем одну, сравниваем, и т.д.
Более-менее разобрался... Пришлось теорию почитать. Ведь читал, но забыл. 
https://www.elastic.co/guide/en/elasticsearch/guide/current/_query_phase.html
Поиск осуществляется в две фазы, собственно поиск и получение документов.
Я сдампил трафик и сопоставил его с полученным профилем (по последней ответившей шарде).
Получается, что в профиль поиска по шарде попадет только непосредственно поиск.
query.time+rewrite_time+collector.time+agregations.time.
Поднятие документов с диска сюда не входит, что собственно логично, хотя и можно было бы и отразить.
1521195638.920560 - Начало запроса
1521195638.920597 - последний пакет с запросом
1521195638.921435 - indices:data/read/search[phase/query]
1521195638.941408 - начало ответа шарды
1521195638.941888 - конец ответа
1521195638.973933 - indices:data/read/search[phase/fetch/id]
1521195639.337249 - начало ответа шарды
1521195641.282545 - конец ответа шарды
1521195641.283771 - Начало ответа
1521195641.363141 - Весь ответ получен
Весь запрос (От начала запроса до начала ответа): 2.36321115494
От получения запроса до запроса на дата-ноды: 0.000838041305542
Фаза поиска:
Запросы ушли на все ноды в течение: 0.00032901763916 сек.
Поиск за: 0.0199728012085 сек <-- Только это попадает в профиль
Вся фаза: 0.0204529762268
Между фазами: 0.0320448875427 сек
Фаза получения:
Все fetch запросы ушли за: 0.000550031661987 сек.
От запроса до ответа: 0.363316059113
Вся фаза подъема: 2.30861210823 <- Не попадает в профилировщик
Получается, что дольше всего я отдаю сами документы.
Насколько критично, что один индекс 40 млн документов 700Г (без реплики)?
Может пора резать?
P.S. Вопрос именно про поиск, складываю медленно, но верно )
А что вы получаете в этом запросе?
Грубо говоря - это реестр документов.
Соответственно два индексируемых поля:
- Имя документа
- Тело документа,
И несколько не индексируемых:
- Пользователь
- Родительский документ
- Права
Запрос возвращает список: UUID'ы с именем и свойствами. т.е. без тела.
Правда полотенце получается иногда на пару мегабайт.
Меня больше инетересовало, сколько документов вы возвращаете назад, от куда поля беруться (_source, doc_values, stored fields) и какое отношение размеров uuid относительно размера всего документа.
Пропустил ответ(
В общем, _source, doc_values, stored fields - используются с дефолтными настройками (если используются). Соотношение получается 3500 хитов в 8 мегабайтовой json-ине.
Соотношение получается 3500 хитов в 8 мегабайтовой json-ине.
Это вы про вывод или исходный документ? Я просто к тому, что если вы только одно получаете, то может иметь смысл хранить это поле с doc values и вытаскивать его из doc values вместо _source
Это выдача поиска - список подходящих документов. Каждый элемент: UUID документа, имя документа и список не индексируемых свойств (владельцы,иерархия и т.п.). вот этот список получается достаточно объемный.
Конечно от запроса зависит. Тут я специально искал слово которое часто встречается, чтобы увеличить время для замера. Сами документы - всякие текстовые документы в среднем около 16К.
16K - это не так много, поэтому будет ли результат сказать сложно. А вы не могли бы запустить hot_threads пока запрос работатет (а еще лучше если несколько запросов работают паралельно и запустить hot_threads несколько раз). Было бы интересно посмотреть, где застревает.
Да, похоже, что все время тратиться на то, чтобы загрузить и парсить source. Я думаю, что имеет смысл попробовать хранить данные, которые вам нужны в большом количестве отдельно как stored fields или docvalues.
индекс на много вырастет?
Если у вас эти поля проиндексированы как keyword, то у вас уже должны быть docvalues. Если нет - то все зависит от размера и разношерстности данных. Экспериментировать надо.
Ok. Спасибо большое. Последний вопрос, стоит заморачиваться с раздельными алиасами для индексации и посика?
Раздельные алиасы полезны при переиндексации данных на лету (без остановки поиска, например). Я не знаю вашу ситуацию, поэтому затрудняюсь сказать будет ли вам они полезны или нет.
Я то больше интересовался в плане производительности.
Т.е. каджый месяц я делаю новый индекс и меняю алиасы:
index_alias -> docs-2018-05
search_alias -> docs*
На производительность алиасы сами по себе никак не влияют. Создание нового индекса каждый месяц - влиять будет, но как вы к этому индексу обращаться будете - через алиас или напрямую по имени, особого значения для производительности не имеет, алиасы - они просто для удобства.
Я думаю, что бесконечно индексы не могут расти и оперировать гигантскими сегментами будет сложнее и сложнее.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.