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

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

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

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

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

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

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

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

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

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

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

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

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

Используйте абсолютное значение времени в качестве фильтра диапазона дат в своем исходном запросе (например, больше 2020-01-01T00:00:00), чтобы ограничить доступ к историческим индексам. Если вы используете относительное значение времени (например, now-30d), то этот диапазон дат переоценивается в момент выполнения каждой контрольной точки.

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

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

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

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

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

Если вы используете более одного group_by поля в своем преобразовании, то порядок полей в сочетании с использованием Сортировки индекса может улучшить время выполнения.

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

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