Сюжеты: Тайлер Перкинс , Гилад Гал , Тереза Солер , Шани Сагив , Бернхард Сум , Джордж Кобар
Elastic Stack 8.9 обеспечивает значительные улучшения производительности в нескольких областях: более быстрый межкластерный поиск в Kibana®, более быстрое агрегирование в Elasticsearch® и более быстрый и релевантный векторный поиск (дополнительную информацию см. в блоге Elastic Search 8.9 ) . Эти улучшения производительности ускоряют получение информации в масштабе и делают векторный поиск Elastic® лидером по релевантности и скорости. Кроме того, воспользуйтесь несколькими улучшениями в Kibana, упрощенной агрегацией географических линий и упрощенным управлением правилами межкластерных оповещений из одного места с помощью Terraform.
Эти новые возможности позволяют клиентам:
- Скорость агрегации индекса увеличилась более чем на 90%
- Сократите задержку для межкластерного поиска до 80 раз
- Управляйте правилами оповещения в нескольких кластерах из одного места с помощью Terraform.
Elastic Stack 8.9 теперь доступен в Elastic Cloud , единственном управляемом предложении Elasticsearch, которое включает все новые функции последней версии. Вы также можете загрузить Elastic Stack и наши продукты для оркестрации облачных вычислений, Elastic Cloud Enterprise и Elastic Cloud for Kubernetes, для самостоятельного управления.
Что еще нового в Elastic 8.9? Подробнее см. в анонсе 8.9 >>
Радикальные улучшения задержки агрегирования метрик
В рамках проекта База данных временных рядов (TSDB), связанного с оптимизацией данных метрик Elasticsearch, мы работали над уменьшением задержки часто используемых агрегаций для данных метрик. Мы сосредоточились на метриках Kubernetes и добились улучшения задержки агрегации на порядок или два (т. е. до версии 8.9 для запуска связанных агрегаций требовалось от 10% до 1% времени).
Давайте рассмотрим детали и связанные с ними общедоступные ежедневные тесты:
- Мы улучшили стандартное поведение обновления Elasticsearch. По умолчанию сброс происходит только тогда, когда сегмент активен при поиске, а сегмент переходит в состояние бездействия поиска после 30 секунд активности поиска. Когда сегмент простаивает для поиска, запланированные сбросы не выполняются, что увеличивает пропускную способность индексации. Однако поиск сегмента бездействия поиска может значительно увеличить время запроса — это будет заметно при загрузке визуализаций в Kibana, так как информационные панели могут загружаться медленно после периода бездействия. Мы внесли два изменения, которые сокращают совокупную задержку поиска более чем на 90 %, поскольку сегменты простаивают для поиска.
- Мы улучшили фазу сопоставления поискового API, чтобы иногда определять, не соответствует ли запрос сегменту, без выполнения каких-либо операций ввода-вывода, связанных с поиском. Для конкретных запросов, ищущих несуществующие поля или несоответствующие постоянные ключевые поля, мы можем пропустить весь сегмент, не выполняя никаких операций ввода-вывода, связанных с поиском, на узлах данных. Это улучшает поведение сброса по умолчанию, поскольку осколки остаются незанятыми для поиска, а запланированные сбросы не выполняются.
- Когда сегмент находится в состоянии ожидания поиска и его не нужно сбрасывать, сброс выполняется немедленно, вместо того, чтобы позволить планировщику сброса сработать. Это снижает задержку при поиске свободных шардов и сокращает время запроса более чем на 1 секунду (улучшение зависит от количества шардов, выделенных на узлах данных).
- Мы улучшили способность агрегации кардинальности распознавать, что некоторые наборы документов не могут добавлять новые значения и поэтому не должны проверяться в ходе выполнения агрегации кардинальности. Эта оптимизация привела к улучшению поразрядной агрегации более чем на 85 %, а при определенных условиях — более чем на 99 %.
- Мы изменили способ использования гистограмм из дерева AVL для слияния, немного пожертвовав точностью (ошибка изменилась с примерно 0,1% до примерно 1%) для значительного улучшения задержки агрегации (агрегация выполняется в два раза быстрее до 50 в несколько раз). . Это улучшение затрагивает набор агрегаций, включая процентили, ранги процентилей и т. д.
Более быстрый поиск в кластерах с меньшим количеством сетевых подключений
Межкластерный поиск (CCS) позволяет объединить несколько кластеров Elasticsearch в единую Kibana или конечную точку поиска, чтобы удовлетворить ваши потребности в локализации данных, управлении и соответствии требованиям, а также в масштабировании. Кластеры могут быть расположены в любой точке мира, в Elastic Cloud, в вашем собственном облаке или локальном развертывании с самостоятельным управлением.
Как распределенная система, Elasticsearch подвержен сетевой задержке. Эта ситуация усугубляется в межкластерной настройке, когда поиск должен быть распределен по сети на несколько кластеров и узлов внутри этих кластеров. Чем больше сетевых отключений, тем сильнее влияние сетевой задержки на производительность. Традиционно кросс-кластерный поиск включает в себя обширные сетевые обходы без использования параметра, который мы называем «минимизация круговых обходов».
Даже с CCS поисковый API поддерживает минимизацию круговых обходов, но когда Kibana выполняет поиск через CCS, он за кулисами использует async_search API, который не поддерживает минимизацию круговых обходов. Мы устранили это ограничение в версии 8.9, добавив поддержку ccs_minimize_roundtrips=true при асинхронном поиске. Kibana 8.9 использует этот режим по умолчанию.
Прирост производительности увеличивается по мере того, как участвует больше осколков. Мы провели тесты операций поиска в кластерах, смоделировав типичные сценарии использования Kibana с различным количеством удаленных кластеров — до 150 кластеров с общим количеством 150 000 сегментов! В этих тестах мы обнаружили, что обычные задачи, такие как загрузка страницы «Обнаружение» или информационной панели, загружались в 10–80 раз быстрее, когда количество обращений туда и обратно было сведено к минимуму.
Мы также иногда видим, что среднее время (розовая полоса ниже) остается более постоянным, когда мы добавляем больше удаленных кластеров.
Он имеет тенденцию к более значительному увеличению без минимизации круговых поездок.
В целом, мы ожидаем значительных улучшений скорости при использовании CCS в версии 8.9.
Более быстрый и надежный поиск CCS холодных и замороженных слоев
Мы также улучшили удаленный поиск моментальных снимков с возможностью поиска (холодные или замороженные данные уровня) и оптимизировали пропуск сегментов. Локальный поиск (не-CCS) может фильтровать (пропускать) нерелевантные осколки, используя информацию о состоянии кластера, сравнивая временной диапазон поискового запроса с минимальной и максимальной метками времени в метаданных осколка. Пока что CCS не поддерживает этот механизм пропуска сегментов, не сводя к минимуму круговые поездки.
В версии 8.9 мы выполняем фазу can_match поиска в удаленном кластере. Это позволяет вести поиск одинаково с CCS и без него, поскольку координирующий узел может определять, какие сегменты пропускать, что особенно важно для холодных и замороженных индексов. Это может улучшить ситуацию с задержкой между локальным и удаленным кластерами за счет менее частого обращения к удаленному кластеру. Обратите внимание, что эта оптимизация актуальна только в том случае, если не минимизированы круговые поездки. Межкластерный поиск, сводящий к минимуму круговые обходы, уже имеет эту возможность. В 8.9 любой способ должен работать для ваших нужд.
Поиск политик ILM, связанных с отчетами о работоспособности
Управление жизненным циклом индекса (ILM) автоматизирует вашу работу по управлению данными, выполняя пролонгацию, сжатие, слияние, операции понижения выборки и т. д., а также перемещая данные с одного уровня на другой, чтобы вы могли оптимизировать соотношение затрат и производительности. Он делает это с помощью последовательности операций (прокрутка, сжатие и т. д.) и шагов (ожидание активных осколков и т. д.). Если ILM застревает на шаге слишком долго, данные могут накапливаться в неправильных слоях и вызывать проблемы.
Чтобы помочь вам замечать проблемы с ILM на ранней стадии, мы улучшили индикаторы работоспособности ILM в API Health Report. Новое правило будет проверять все индексы, управляемые политикой ILM, на соответствие текущему действию и процедуре в любое время. Например, если индекс находился в комбинации rollover > wait-for-active-shards более 24 часов или если шаг ожидания-active-shards был повторен более 100 раз, индикатор станет желтым. .
Время и пороги повторных попыток можно изменить с помощью настроек индикатора работоспособности .
Этот индикатор также будет отображаться в консоли Elastic Cloud Deployments . Вы можете быстрее выявлять проблемы, которые могут вызывать проблемы с производительностью или стабильностью кластера. Как и в остальной части отчета о работоспособности, мы укажем возможные последствия и добавим ссылки на соответствующие рекомендации по устранению неполадок .
упрощение географической линии
Популярный вариант использования географических данных — активы для создания временных рядов местоположений, каждое со своей собственной временной меткой, и системы, которые позволяют отслеживать активы по этому временному ряду. Elasticsearch теперь поддерживает алгоритм упрощения, который позволяет генерировать линию на основе меньшего подмножества точек местоположения (определяемого параметром «размер»), минимизируя возникающие неточности. Эта функциональность основана на инфраструктуре схемы индекса временных рядов (TSDS). Это упрощение снижает потребление памяти и поддерживает создание сложных географических линий на основе большого количества местоположений. Упрощение географических линий выпущено в виде технической предварительной версии.
Усовершенствования визуализации и управления правилами
Elastic 8.9 представляет множество улучшений существующей функциональности Kibana — мы выделяем два из них ниже. Кроме того, «Правила как код» значительно упрощают управление правилами на нескольких узлах в кластере за счет использования Terraform для репликации правил и применения контроля версий, что помогает поддерживать наблюдаемость и отслеживать правила на предмет проблем с безопасностью.
Легенда гистограммы Kibana с накоплением
Порядок легенд столбчатых диаграмм теперь основан на популярности, при этом наиболее важные элементы отображаются вверху. Вам больше не нужно прокручивать легенду до конца, чтобы найти самые популярные данные на диаграмме.
До:
Новое с версии 8.9:
Kibana Lens Ladder Curve Vision
Объектив теперь поддерживает три новых параметра линейных диаграмм. Три варианта: Straight, Smooth и Stepped. Ступенчатая линейная диаграмма может помочь пользователям четко видеть, когда данные изменяются с нерегулярными интервалами, что может помочь избежать недоразумений. При создании визуализации выберите Линия в раскрывающемся списке Тип визуализации. Затем используйте меню «Визуальные параметры», чтобы выбрать прямую, гладкую или ступенчатую в раскрывающемся списке «Линейная интерполяция».
8-9-платформа-блог-визуальные-параметры-меню
правила как код
Поставщик Terraform Elastic Stack выпустил новую функцию, которая позволяет пользователям управлять своими правилами оповещения и коннекторами в Kibana. Это позволяет пользователям автоматизировать ручные процессы, управлять несколькими кластерами из одного места и открывать дополнительные варианты использования, такие как контроль версий.
Подождите... есть еще!
Посетите блог с объявлениями о выпуске 8.9 , чтобы узнать, какие другие улучшения в поиске, наблюдаемости или безопасности могут быть вам полезны! Дополнительные сведения о ранее упомянутых функциях см. в разделах Новые возможности Elasticsearch версии 8.9 и Новые возможности Kibana версии 8.9 . Наконец, примечания к выпуску содержат полный список всех улучшений, предлагаемых Elastic 8.9.
попробуй
Существующие клиенты Elastic Cloud могут получить доступ ко многим из этих возможностей непосредственно из консоли Elastic Cloud . Не используете преимущества Elastic в облаке? Начните бесплатную пробную версию .
原文：Elastic Stack 8.9: более быстрое агрегирование и межкластерный поиск | Эластичный блог