Оптимизация поиска
Тема дорожной карты · Elasticsearch
Оптимизация поиска в Elasticsearch сочетает в себе решения по дизайну индекса, лучшие практики Query DSL и настройку конфигурации кластера, совокупно минимизирующие задержку запросов и максимизирующие пропускную способность поиска. Одна из наиболее эффективных оптимизаций — размещение часто используемых условий фильтрации (таких как диапазоны дат или флаги статусов) в блоке filter bool-запроса вместо must: Elasticsearch кеширует битовые множества фильтров и пропускает вычисление релевантности, что значительно снижает нагрузку на CPU для каждого запроса. Решения по дизайну индекса также имеют значение: поддержание размера шардов в диапазоне от 10 ГБ до 50 ГБ (проверяется через GET /_cat/shards?v) обеспечивает эффективное объединение сегментов, а применение force_merge к неизменяемым историческим индексам для сведения их к единственному сегменту устраняет накладные расходы от нескольких сегментов во время поиска. Использование фильтрации _source или docvalue_fields для получения только нужных полей снижает сетевые расходы и расходы на десериализацию, особенно для результирующих наборов с высокой мощностью. Оптимизация поиска в Elasticsearch — итеративный процесс: используйте Profile API ("profile": true в запросе _search) для определения, какие условия запросов и шарды потребляют больше всего времени, и отслеживайте перцентили задержки поиска через GET /_nodes/stats/indices/search для установления базовых показателей производительности.
Как это работает
Оптимизация поиска: JVM тюнинг — heap = 50% RAM, max 31GB (граница compressed oops), G1GC на современных JDK. Bulk indexing — отключите refresh во время bulk (-1), увеличьте translog flush threshold, batch 5-15MB. Search optimisation — filter context (cacheable), ограничивайте specific индексами через aliases, избегайте wildcards на big-индексах, profile API для slow queries. Мониторинг через Stack Monitoring app (или Prometheus exporter — prometheus-es-exporter).
Когда применять
Меряйте до тюнинга — profile API + slow log для идентификации проблем. Для ingest bottleneck: больше bulk batches + больше клиентов + refresh off. Для search bottleneck: cache (filter context), trim полей через _source filtering, force-merge cold-индексов. Для cluster stability: dedicate роли, тюньте thread_pool sizes, мониторьте circuit_breakers.
Типичные ошибки
Ловушки Оптимизация поиска: heap = 100% RAM (нет OS file cache — медленные queries); heap > 32GB (теряет compressed oops); выключают refresh + забывают включить обратно; force-merge hot-индексов (locks + I/O storm).