Оптимизация медленных запросов Elasticsearch: лучшие практики настройки производительности

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

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

Понимание узких мест производительности запросов

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

Сложные запросы: Запросы с несколькими условиями bool, вложенными запросами или дорогими операциями, такими как wildcard или regexp на больших наборах данных.
Неэффективное извлечение данных: Извлечение _source без необходимости или получение большого количества документов для пагинации.
Ограничения ресурсов: Недостаток CPU, памяти или дискового ввода-вывода на узлах данных.
Неоптимальные маппинги: Использование неправильных типов данных или отсутствие использования doc_values для агрегаций.
Дисбаланс или перегрузка шардов: Слишком много шардов, слишком мало шардов или неравномерное распределение шардов/данных.
Промахи кэша или плохая адаптация кэша: Повторение дорогих поисков без использования кэширования запросов, контекста фильтра или кэширования на уровне приложения, где это уместно.

Оптимизация структуры запроса

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

1. Извлекайте только необходимые поля (фильтрация `_source` и `stored_fields`)

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

Фильтрация _source: Используйте параметр _source, чтобы указать массив полей для включения или исключения.
```
GET /my-index/_search
{
  "_source": ["title", "author", "publish_date"],
  "query": {
    "match": {
      "content": "Elasticsearch performance"
    }
  }
}
```
stored_fields: Если вы явно сохранили определенные поля в маппинге ("store": true), вы можете извлечь их с помощью stored_fields. В большинстве развертываний поля редко сохраняются таким образом, поэтому фильтрация _source является более распространенным исправлением.
```
GET /my-index/_search
{
  "stored_fields": ["title", "author"],
  "query": {
    "match": {
      "content": "Elasticsearch performance"
    }
  }
}
```

2. Отдавайте предпочтение эффективным типам запросов

Некоторые типы запросов по своей сути более ресурсоемки, чем другие.

Избегайте ведущих подстановочных знаков и широких регулярных выражений: Запросы wildcard и regexp могут быть дорогими, особенно с ведущими подстановочными знаками, такими как *test. Префиксные запросы обычно более управляемы, чем поиск с ведущим подстановочным знаком, но они все равно требуют разумных маппингов и ограниченного ввода.
```
# Неэффективно - избегайте ведущего подстановочного знака
{
  "query": {
    "wildcard": {
      "name.keyword": {
        "value": "*search"
      }
    }
  }
}

# Лучше - если вы знаете префикс
{
  "query": {
    "prefix": {
      "name.keyword": {
        "value": "Elastic"
      }
    }
  }
}
```
Используйте match_phrase для фразового поиска: Если пользователь ищет точную фразу, match_phrase лучше выражает это намерение, чем несколько несвязанных условий match. Это не всегда дешевле, но позволяет избежать возврата документов, содержащих слова далеко друг от друга.
Контекст фильтра для условий да/нет: Когда вас интересует только то, соответствует ли документ условию, поместите это условие в контекст filter или используйте constant_score. Это позволяет избежать ненужной работы по оценке релевантности и более дружелюбно к кэшированию.
```
GET /my-index/_search
{
  "query": {
    "constant_score": {
      "filter": {
        "term": {
          "status": "active"
        }
      }
    }
  }
}
```

3. Оптимизация булевых запросов

Используйте фильтры для структурированных ограничений: Помещайте идентификаторы арендаторов, значения статусов, диапазоны дат и точные теги в filter, а не в must, если только они не требуют оценки релевантности. Elasticsearch может внутренне переупорядочивать и оптимизировать условия, поэтому не полагайтесь на порядок JSON как на основной инструмент производительности.
Используйте minimum_should_match осознанно: Это может улучшить релевантность и уменьшить количество широких совпадений, но слишком высокое значение может скрыть валидные результаты.

4. Эффективная пагинация (`search_after` и `scroll`)

Традиционная пагинация с from/size становится очень неэффективной для глубоких страниц (например, from: 10000, size: 10). Elasticsearch должен извлечь и отсортировать все документы до from + size на каждом шарде, а затем отбросить from документов.

search_after: Для глубокой пагинации в реальном времени рекомендуется search_after. Он использует порядок сортировки последнего документа предыдущей страницы для поиска следующего набора результатов, аналогично курсорам в традиционных базах данных. Он не сохраняет состояние и лучше масштабируется.
```
# Первый запрос
GET /my-index/_search
{
  "size": 10,
  "query": {"match_all": {}},
  "sort": [{"timestamp": "asc"}, {"_id": "asc"}]
}

# Последующий запрос, использующий значения сортировки последнего документа из первого запроса
GET /my-index/_search
{
  "size": 10,
  "query": {"match_all": {}},
  "search_after": [1678886400000, "doc_id_XYZ"],
  "sort": [{"timestamp": "asc"}, {"_id": "asc"}]
}
```
API scroll: Для массового извлечения больших наборов данных, таких как переиндексация или экспорт, scroll все еще может быть полезен. Для более новых версий Elasticsearch и длительных полных сканирований индекса также рассмотрите point-in-time в сочетании с search_after. Scroll не подходит для пользовательской пагинации в реальном времени.

5. Оптимизация агрегаций

Агрегации могут быть ресурсоемкими, особенно для полей с высокой кардинальностью.

Предварительное вычисление агрегаций: Рассмотрите возможность выполнения сложных, не в реальном времени агрегаций во время индексации или по расписанию для предварительного вычисления результатов и их хранения в отдельном индексе.
doc_values: Убедитесь, что для полей, используемых в агрегациях, включены doc_values (это значение по умолчанию для большинства не текстовых полей). Это позволяет Elasticsearch эффективно загружать данные для агрегаций без загрузки _source.
eager_global_ordinals: Для полей keyword, часто используемых в агрегациях terms, установка eager_global_ordinals: true в маппинге может улучшить производительность за счет предварительного построения глобальных ординалов. Это увеличивает затраты во время обновления индекса, но ускоряет агрегации во время запроса.

Использование методов кэширования

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

1. Кэш запросов узла

Механизм: Кэширует результаты условий фильтра в запросах bool, которые часто используются. Это кэш в памяти на уровне узла.
Эффективность: Наиболее эффективен для повторяющихся условий фильтра. Не рассчитывайте на него для каждого запроса; Elasticsearch решает, что стоит кэшировать.
Конфигурация: Включен по умолчанию. Вы можете контролировать его размер с помощью indices.queries.cache.size (по умолчанию 10% кучи).

2. Кэш запросов шарда

Механизм: Кэширует результаты поиска на уровне шарда, чаще всего для запросов с большим количеством агрегаций и size=0. Он хорошо подходит для повторяющихся запросов дашбордов к данным, которые не меняются каждую секунду.
Эффективность: Отлично подходит для запросов дашбордов или аналитических приложений, где один и тот же запрос (включая агрегации) выполняется повторно с идентичными параметрами.

Как использовать: Включите его явно в своем запросе с помощью "request_cache": true.

GET /my-index/_search?request_cache=true
{
  "size": 0,
  "query": {
    "bool": {
      "filter": [
        {"term": {"status.keyword": "active"}},
        {"range": {"timestamp": {"gte": "now-1h"}}}
      ]
    }
  },
  "aggs": {
    "messages_per_minute": {
      "date_histogram": {
        "field": "timestamp",
        "fixed_interval": "1m"
      }
    }
  }
}

Предостережения: Кэш сбрасывается всякий раз, когда шард обновляется (индексируются новые документы или обновляются существующие). Полезен только для запросов, которые часто возвращают идентичные результаты.

3. Кэш файловой системы (уровень ОС)

Механизм: Кэш файловой системы операционной системы играет критическую роль. Elasticsearch сильно полагается на него для кэширования часто используемых сегментов индекса.
Эффективность: Критически важен для производительности запросов. Если сегменты индекса находятся в оперативной памяти, дисковый ввод-вывод полностью исключается, что приводит к гораздо более быстрому выполнению запросов.
Лучшая практика: Оставляйте значительный объем оперативной памяти для кэша файловой системы. Распространенная отправная точка — держать кучу JVM около половины системной памяти, учитывая обычные ограничения кучи Elasticsearch, а затем проверять на своей рабочей нагрузке.

4. Кэширование на уровне приложения

Механизм: Реализация кэша на уровне вашего приложения (например, с использованием Redis, Memcached или кэша в памяти) для часто запрашиваемых результатов поиска.
Эффективность: Может обеспечить самое быстрое время ответа, полностью обходя Elasticsearch для повторяющихся запросов. Лучше всего подходит для статических или медленно меняющихся результатов поиска.
Соображения: Стратегия инвалидации кэша является ключевой. Требует тщательного проектирования для обеспечения согласованности данных.

Использование Profile API для выявления узких мест

Profile API — это бесценный инструмент для точного понимания того, как Elasticsearch выполняет запрос и где тратится время. Он разбивает время выполнения для каждого компонента вашего запроса и агрегации.

Как использовать Profile API

Просто добавьте "profile": true в тело вашего поискового запроса.

GET /my-index/_search
{
  "profile": true,
  "query": {
    "bool": {
      "must": [
        {"match": {"title": "Elasticsearch"}},
        {"term": {"status.keyword": "published"}}
      ],
      "filter": [
        {"range": {"publish_date": {"gte": "2023-01-01"}}}
      ]
    }
  },
  "aggs": {
    "top_authors": {
      "terms": {
        "field": "author.keyword",
        "size": 10
      }
    }
  }
}

Интерпретация результатов Profile API

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

description: Конкретный компонент запроса или агрегации.
time_in_nanos: Время, затраченное на выполнение этого компонента.
breakdown: Детальные подметрики, такие как build_scorer_time, collect_time, set_weight_time для запросов и reduce_time для агрегаций.
children: Вложенные компоненты, показывающие, как время распределяется внутри сложных запросов.

Пример интерпретации:

Если вы видите высокое значение time_in_nanos для WildcardQuery, это подтверждает, что это дорогая часть вашего запроса. Если collect_time высок, это предполагает, что извлечение и обработка документов после совпадения является узким местом, возможно, из-за парсинга _source или глубокой пагинации. Высокое значение reduce_time в агрегациях может указывать на высокую нагрузку во время финальной фазы слияния.

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

Общие лучшие практики для производительности

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

1. Оптимальные маппинги индекса

text vs. keyword: Используйте text для полнотекстового поиска и keyword для точного совпадения значений, сортировки и агрегаций. Несоответствие типов может привести к неэффективным запросам.
doc_values: Убедитесь, что doc_values включены для полей, по которым вы собираетесь сортировать или агрегировать. Они включены по умолчанию для большинства типов полей, поддерживающих сортировку и агрегации, таких как keyword, числовые, дата, булевы и IP-поля. Обычные поля text предназначены для полнотекстового поиска; используйте подполе keyword, когда требуется точное совпадение или агрегация.
norms: Отключите norms ("norms": false) для полей, где вам не нужна нормализация длины документа (например, поля ID). Это экономит дисковое пространство и улучшает скорость индексации с минимальным влиянием на производительность запросов для неоценочных запросов.
index_options: Для полей text используйте index_options: docs, если вам нужно только знать, существует ли термин в документе, и index_options: positions (по умолчанию), если вам нужны фразовые запросы и поиск по близости.

2. Мониторинг здоровья кластера и ресурсов

Статус кластера: Зеленый — цель. Желтый означает, что одна или несколько реплик шардов не назначены; поиск все еще может работать, но отказоустойчивость снижена, и производительность может страдать. Красный означает, что первичные шарды отсутствуют и некоторые данные недоступны.
Мониторинг ресурсов: Регулярно отслеживайте использование CPU, RAM, дискового ввода-вывода и сети на ваших узлах данных. Спайки в этих метриках часто коррелируют с медленными запросами.
Куча JVM: Следите за использованием кучи JVM. Высокая загрузка может привести к частым паузам сборки мусора, что замедляет запросы. Оптимизируйте запросы, чтобы снизить давление на кучу.

3. Правильное распределение шардов

Слишком много шардов: Каждый шард потребляет ресурсы. Много маленьких шардов создают накладные расходы. Шарды размером в десятки гигабайт распространены, но правильный размер зависит от кучи, шаблона запросов, целей восстановления и оборудования.
Слишком мало шардов: Ограничивает параллелизм. Запросы к индексу со слишком малым количеством шардов не смогут эффективно использовать все доступные узлы данных.

4. Стратегия индексации

Интервал обновления: Более низкий refresh_interval (по умолчанию 1 секунда) делает данные видимыми быстрее, но увеличивает нагрузку на индексацию. Для рабочих нагрузок с интенсивным поиском рассмотрите возможность его небольшого увеличения (например, 5-10 секунд), чтобы уменьшить нагрузку на обновление.

Практический рабочий процесс прост: найдите реальный медленный запрос, профилируйте его, уменьшите объем данных, которые он затрагивает, и сделайте маппинг соответствующим тому, как пользователи ищут. Если запрос уже чистый, посмотрите на расположение шардов, давление на кучу, кэш файловой системы и дисковый ввод-вывод. Elasticsearch быстр, когда дизайн индекса, форма запроса и ресурсы кластера согласованы друг с другом.