Диагностика и устранение медленных поисковых запросов Elasticsearch

Медленный поиск в Elasticsearch обычно возникает из-за широких запросов, ресурсоемких агрегаций, выбора маппинга, распределения шардов или нехватки ресурсов в кластере. Если ваш поисковый API начинает выдавать тайм-ауты или задержки возрастают после роста индекса, необходимо определить, выполняет ли запрос, индекс или кластер слишком много работы.

Используйте медленные логи и Profile API для поиска затратной части, а затем настройте запрос, маппинг, стратегию шардирования или оборудование на основе полученных данных.

Типичные причины медленного поиска в Elasticsearch

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

1. Неэффективные запросы

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

Широкие запросы: Запросы, сканирующие большое количество документов или полей без достаточной фильтрации.
- Пример: Запрос match_all по огромному индексу.
Глубокая пагинация: Запрос очень большой страницы с использованием from и size. Для глубокой пагинации, ориентированной на пользователя, предпочтительнее использовать search_after со стабильной сортировкой и поиском по точке во времени (point-in-time). Используйте scroll в основном для пакетной обработки или рабочих нагрузок типа переиндексации.
Сложные агрегации: Чрезмерно сложные или ресурсоемкие агрегации, особенно в сочетании с широкими запросами.
Wildcard-запросы: Начальные wildcard (например, *term) особенно неэффективны, так как не могут эффективно использовать поиск по инвертированному индексу. Конечные wildcard обычно лучше, но все равно могут быть медленными на больших наборах данных.
Запросы с регулярными выражениями: Они могут быть вычислительно затратными, и их следует использовать с осторожностью.

2. Проблемы с маппингом

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

Динамические маппинги: Хотя они удобны, динамические маппинги иногда могут приводить к неожиданным типам полей или созданию ненужных проанализированных (analyzed) полей, увеличивая размер индекса и накладные расходы на поиск.
Поля text vs. keyword: Использование полей text для точного совпадения или сортировки/агрегаций, когда более подходящим было бы поле keyword. Поля text анализируются для полнотекстового поиска, в то время как поля keyword индексируются как есть, что делает их идеальными для точных совпадений, сортировки и агрегаций.
- Пример: Если вам нужно фильтровать по идентификатору продукта (PROD-123), он должен быть сопоставлен как keyword, а не text.
```
PUT my-index
{
  "mappings": {
    "properties": {
      "product_id": {
        "type": "keyword"
      }
    }
  }
}
```
Устаревшие предположения о поле _all: В старых версиях Elasticsearch было поле _all, которое индексировало содержимое других полей. В современных версиях оно удалено, поэтому используйте явные поля или copy_to, когда вам нужен комбинированный текст для поиска.
Вложенные структуры данных: Использование вложенных (nested) типов данных может быть мощным для поддержания связей, но также может быть более ресурсоемким для запросов по сравнению с типами flattened или object, если запросы не выполняются осторожно.

3. Аппаратное обеспечение и конфигурация кластера

Базовая инфраструктура и то, как настроен Elasticsearch, играют решающую роль в производительности.

Недостаточные аппаратные ресурсы:
- CPU: Высокая загрузка ЦП может указывать на неэффективные запросы или высокую нагрузку индексации/поиска.
- RAM: Недостаточный объем ОЗУ приводит к увеличению дискового ввода-вывода из-за подкачки памяти операционной системой. Elasticsearch также сильно зависит от кучи JVM и кэша файловой системы ОС.
- Дисковый ввод-вывод: Медленные диски (особенно HDD) являются основным узким местом. Для производственных кластеров Elasticsearch настоятельно рекомендуется использовать SSD.
Размер и количество шардов:
- Слишком много маленьких шардов: Каждый шард имеет накладные расходы. Очень большое количество маленьких шардов может перегрузить кластер.
- Слишком мало больших шардов: Большие шарды могут привести к длительному времени восстановления и неравномерному распределению нагрузки.
- Общая рекомендация: Шарды размером в десятки гигабайт являются обычными для многих рабочих нагрузок логирования и поиска, но правильный размер зависит от объема данных, шаблонов запросов, целей восстановления и ресурсов узла.
Реплики: Хотя реплики повышают доступность и пропускную способность чтения, они также увеличивают накладные расходы на индексацию и использование дискового пространства. Слишком большое количество реплик может нагружать ресурсы.
Размер кучи JVM: Неправильно настроенная куча JVM может привести к паузам сборки мусора. Распространенная отправная точка — не более половины системной памяти, оставляя достаточно памяти для кэша файловой системы ОС. Следуйте рекомендациям по куче для вашей версии Elasticsearch.
Сетевая задержка: В распределенных средах сетевая задержка между узлами может влиять на межузловое взаимодействие и координацию поиска.

4. Проблемы производительности индексации, влияющие на поиск

Хотя эта статья посвящена поиску, проблемы во время индексации могут косвенно влиять на скорость поиска.

Высокая нагрузка индексации: Если кластер с трудом справляется с запросами на индексацию, это может повлиять на производительность поиска. Это часто связано с недостаточным аппаратным обеспечением или плохо оптимизированными стратегиями индексации.
Большое количество сегментов: Частая индексация без регулярного слияния сегментов может привести к большому количеству маленьких сегментов. Хотя Elasticsearch автоматически объединяет сегменты, этот процесс требует много ресурсов и может временно замедлить поиск.

Диагностика медленных запросов

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

1. Медленные логи Elasticsearch

Настройте Elasticsearch на логирование медленных запросов. Это самый прямой способ выявить проблемные поисковые запросы.

Конфигурация: Установите пороговые значения медленных логов для каждого индекса. Используйте суффиксы уровней логирования, которые ожидает Elasticsearch, такие как warn, info, debug или trace.
```
PUT _settings
{
  "index": {
    "search": {
      "slowlog": {
        "threshold": {
          "query": {
            "warn": "1s"
          },
          "fetch": {
            "warn": "1s"
          }
        }
      }
    }
  }
}
```
- query: Логирует запросы, выполнение фазы запроса которых занимает больше указанного порога.
- fetch: Логирует запросы, выполнение фазы выборки (извлечение фактических документов) которых занимает больше указанного порога.
Расположение логов: Медленные логи записываются через логирование Elasticsearch и часто появляются в отдельных файлах медленных логов поиска в зависимости от вашего пакета, платформы развертывания и конфигурации логирования.

2. Инструменты мониторинга Elasticsearch

Используйте инструменты мониторинга для получения информации о состоянии и производительности кластера.

Мониторинг Elastic Stack: Предоставляет панели мониторинга для загрузки ЦП, памяти, дискового ввода-вывода, использования кучи JVM, задержки запросов, скорости индексации и многого другого при настройке.
APM (Мониторинг производительности приложений): Может помочь отследить запросы от вашего приложения до Elasticsearch, выявляя узкие места на уровне приложения или Elasticsearch.
Сторонние инструменты: Многие внешние инструменты предлагают расширенные возможности мониторинга и анализа.

3. API Analyze

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

Пример: Посмотрите, как обрабатывается строка запроса.
```
GET my-index/_analyze
{
  "field": "my_text_field",
  "text": "Quick brown fox"
}
```

4. Profile API

Для очень специфической настройки производительности запросов Profile API может предоставить подробную информацию о времени выполнения каждого компонента поискового запроса.

Пример:

GET my-index/_search
{
  "profile": true,
  "query": {
    "match": {
      "my_field": "search term"
    }
  }
}

Исправление медленных запросов: решения и оптимизации

После того как вы определили коренную причину, вы можете внедрить целевые решения.

1. Оптимизация запросов

Контекст фильтра: Используйте предложение filter для условий, которые не требуют оценки релевантности (scoring). Elasticsearch может выполнять их как фильтры да/нет и может кэшировать часто используемые фильтры.
```
GET my-index/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "title": "elasticsearch" } }
      ],
      "filter": [
        { "term": { "status": "published" } },
        { "range": { "publish_date": { "gte": "now-1M/M" } } }
      ]
    }
  }
}
```
Избегайте начальных wildcard: Переписывайте запросы, чтобы избежать начальных wildcard (*term), если это возможно. Рассмотрите возможность использования ngram токенизаторов или альтернативных методов поиска.
Ограничьте сканирование полей: Указывайте только те поля, которые вам нужны в запросе и в фильтрации _source вашего ответа.
Используйте search_after для глубокой пагинации: Для интерактивной пагинации за пределами неглубоких страниц используйте search_after с детерминированной сортировкой. Для больших выгрузок используйте scroll или point-in-time плюс search_after, в зависимости от вашей версии Elasticsearch и рабочей нагрузки.
Упростите агрегации: Проверьте и оптимизируйте сложные агрегации. Рассмотрите возможность использования составных (composite) агрегаций для глубокой пагинации агрегаций.
keyword для точных совпадений/сортировки: Убедитесь, что поля, используемые для точного совпадения, сортировки или агрегаций, сопоставлены как keyword.

2. Улучшение маппингов

Явные маппинги: Определяйте явные маппинги для ваших индексов, а не полагайтесь исключительно на динамические маппинги. Это гарантирует, что поля индексируются с правильными типами.
Будьте осторожны с _source и doc_values: Отключение _source может нарушить обновления, переиндексацию, подсветку и рабочие процессы отладки. Отключение doc_values для полей, используемых для сортировки или агрегаций, навредит этим рабочим нагрузкам. Относитесь к этому как к оптимизации хранения, а не как к стандартному исправлению поиска.
index_options: Для полей text настройте index_options для хранения только необходимой информации (например, позиций для фразовых запросов).

3. Настройка оборудования и кластера

Модернизируйте оборудование: Инвестируйте в более быстрые процессоры, больше оперативной памяти и, особенно, SSD.
Оптимизируйте стратегию шардирования: Проверьте количество и размер шардов. При необходимости рассмотрите возможность переиндексации данных в новый индекс с оптимизированной стратегией шардирования. Используйте такие инструменты, как Index Lifecycle Management (ILM), для управления индексами на основе времени и их шардированием.
Настройте кучу JVM: Убедитесь, что размер кучи JVM установлен правильно (например, 50% ОЗУ, максимум 30-32 ГБ), и отслеживайте сборку мусора.
Роли узлов: Распределяйте роли (master, data, ingest, coordinating) по разным узлам, чтобы предотвратить конкуренцию за ресурсы.
Увеличьте количество реплик (для рабочих нагрузок с интенсивным чтением): Если ваше узкое место — пропускная способность чтения, а не индексация, рассмотрите возможность добавления большего количества реплик, но отслеживайте влияние на индексацию.

4. Оптимизация индекса

Force Merge: Запускайте _forcemerge только на индексах, доступных только для чтения, где меньшее количество сегментов поможет поиску и хранению. Это ресурсоемкая операция, которая может создавать очень большие сегменты, дорогие для перезаписи, если индекс продолжает получать записи.
```
POST my-index/_forcemerge?max_num_segments=1
```
Index Lifecycle Management (ILM): Используйте ILM для автоматического управления индексами, включая фазы оптимизации, такие как принудительное слияние на старых неактивных индексах.

Лучшие практики для поддержания производительности

Регулярно мониторьте: Непрерывный мониторинг является ключом к раннему выявлению регрессий производительности.
Тестируйте изменения: Перед внедрением значительных изменений в производство тестируйте их в среде staging.
Понимайте свои данные и запросы: Лучшие оптимизации зависят от контекста. Знайте, какие у вас данные и как вы их запрашиваете.
Обновляйте Elasticsearch: Новые версии часто включают улучшения производительности и исправления ошибок.
Правильно подбирайте размер кластера: Избегайте избыточного или недостаточного выделения ресурсов. Регулярно оценивайте потребности вашего кластера.

Вывод

Исправляйте медленный поиск в Elasticsearch, сначала проводя измерения. Медленные логи сообщают вам, какие запросы вызывают проблемы, Profile API показывает, куда уходит время, а метрики кластера показывают, конкурирует ли запрос с давлением на кучу, дисковым вводом-выводом, индексацией или накладными расходами шардов. Вносите одно изменение, повторно запускайте тот же запрос и сохраняйте результат, только если задержка и использование ресурсов улучшились.