Работа с преобразованиями в масштабе

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

В этом руководстве вы узнаете, как:

Предварительные условия:

Эти рекомендации предполагают, что у вас есть преобразование, которое вы хотите настроить, и вы уже знакомы с:

Следующие соображения не являются последовательными – номера помогают перемещаться между пунктами списка; вы можете принять меры по одному или нескольким из них в любом порядке. Большинство рекомендаций применимы как к непрерывным, так и к пакетным преобразованиям. Если пункт списка относится только к одному типу преобразований, это исключение выделено в описании.

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

Для оптимизации производительности преобразований начните с определения областей, где выполняется наибольшая работа. Интерфейс Статистики на странице Преобразования в Kibana содержит информацию, охватывающую три основные области: время индексирования, поиска и обработки (как альтернатива, вы можете использовать API статистики преобразований). Например, если результаты показывают, что наибольшая часть времени тратится на поиск, то сосредоточьтесь на оптимизации запроса поиска преобразования. Преобразования также поддерживают Rally, что позволяет выполнять проверки производительности конфигураций преобразований, если это необходимо. Если вы оптимизировали ключевые факторы, и все еще наблюдаются проблемы с производительностью, вы также можете рассмотреть возможность улучшения вашего оборудования.

В непрерывном преобразовании параметр конфигурации frequency устанавливает интервал между проверками изменений в исходных индексах. Если изменения обнаружены, то исходные данные ищутся, а изменения применяются к целевому индексу. В зависимости от вашего сценария использования, вы можете уменьшить частоту применения изменений. Установив frequency на более высокое значение (максимум один час), рабочая нагрузка может быть распределена во времени за счет менее актуальных данных.

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

Если у вас определен исходный индекс преобразования query, убедитесь, что он максимально эффективен. Используйте Профилировщик поиска в Инструментах разработчика Kibana, чтобы получить подробную информацию о времени выполнения отдельных компонентов в запросе поиска. В качестве альтернативы вы можете использовать профилирование. Результаты дают представление о том, как выполняются запросы поиска на низком уровне, чтобы вы могли понять, почему определенные запросы медленные, и принять меры по их улучшению.

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

Представьте, что ваше непрерывное преобразование настроено на группировку по IP и вычисление суммы bytes_sent. На каждой контрольной точке непрерывное преобразование обнаруживает изменения в исходных данных с момента предыдущей контрольной точки, определяя IP-адреса, для которых были получены новые данные. Затем оно выполняет второй поиск, отфильтрованный для этой группы IP-адресов, для вычисления общей суммы bytes_sent. Если этот второй поиск сопоставляется со многими фрагментами, это может быть ресурсоемко. Рассмотрите возможность ограничения области, на которую будут распространяться шаблон исходного индекса и запрос.

Чтобы ограничить доступ к историческим индексам, исключите определенные слои (например, "must_not": { "terms": { "_tier": [ "data_frozen", "data_cold" ] } }) и/или используйте абсолютное значение времени в качестве фильтра диапазона дат в вашем исходном запросе (например, больше 2024-01-01T00:00:00). Если вы используете относительное значение времени (например, gte now-30d/d), убедитесь, что применяется округление дат для использования кэша запросов и что относительное время намного больше наибольшего из frequency или time.sync.delay или корзины гистограммы дат, иначе данные могут быть пропущены. Не используйте фильтры дат, которые меньше значения даты (например, lt: меньше или lte: меньше или равно), так как это противоречит логике, применяемой при каждом выполнении контрольной точки, и данные могут быть пропущены.

Рассмотрите возможность использования date math в именах индексов для уменьшения количества индексов, разрешаемых в ваших запросах. Добавьте шаблон даты – например, yyyy-MM-dd – в имена индексов и используйте его для ограничения запроса определенной датой. Пример ниже запрашивает индексы только со вчерашнего и сегодняшнего дня:

  "source": {
    "index": [
        "<mydata-{now/d-1d{yyyy-MM-dd}}*>",
        "<mydata-{now/d{yyyy-MM-dd}}*>"
    ]
  },

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

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

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

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

Динамические поля и поля со скриптами не являются индексированными полями; их значения извлекаются или вычисляются только во время поиска. Хотя эти поля обеспечивают гибкость в доступе к данным, они увеличивают затраты на производительность во время поиска. Если производительность преобразования с использованием динамических полей или полей со скриптами вызывает опасения, вы можете рассмотреть возможность использования индексированных полей вместо них. По причинам производительности не рекомендуется использовать динамическое поле в качестве поля времени, синхронизирующего непрерывное преобразование.

Сортировка индексов позволяет хранить документы на диске в определенном порядке, что может улучшить эффективность запросов. Идеальная логика сортировки зависит от вашего сценария использования, но общим правилом может быть сортировка полей в порядке убывания (высокая к низкой кардинальности), начиная с полей, основанных на времени. Сортировка индексов может быть определена только один раз при создании индекса. Если у вас еще нет сортировки индексов в индексе, который вы хотите использовать в качестве источника, рассмотрите возможность повторной индексации в новый отсортированный индекс.

Поле _source содержит исходный документ JSON, который был передан во время индексирования. Само поле _source не индексируется (и, следовательно, не является поисковым), но оно все равно хранится в индексе и создает издержки на хранение. Рассмотрите возможность отключения поля _source для экономии дискового пространства, если у вас большой целевой индекс. Отключение поля _source возможно только при создании индекса.