Тренинги 🔍ElasticSearch и 🔍OpenSearch c нуля до администратора в июне — отличный способ прокачать скиллы в начале лета!

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

За время курса вы:

🔎 разберетесь в принципах работы ElasticSearch/OpenSearch
🔎 установите и настроите кластер
🔎 настроите сбор и обработку неструктурированных данных
🔎 получите опыт работы с политикам жизненного цикла индексов
🔎 научитесь проработке архитектуры будущего кластера в зависимости от нагрузки
🔎 поймете как оптимизировать хранение данных
🔎 узнаете много интересного, о чём не написано в документации

Ближайшие курсы в июне:

▶️ Программа ElasticSearch 2-4 июня

▶️ Программа OpenSearch 9-11 июня

Тренинг состоит из теоретической и практической части. Для практической части мы предоставляем лабораторные стенды. Оставить заявку, узнать стоимость обучения и другие детали можно через бот @gals_education_bot. Также заявку можно оставить через форму обратной связи на соответствующей странице тренинга (выше) либо написать на почту welcome@gals.software.

Это просто праздник какой-то! Вслед за Elastic и его релизом версии 9.0, OpenSearch также объявил о релизе версии 3.0.

Пишут, что работает в 9,5 раз быстрее, чем OpenSearch 1.3 при поиске по ключевым типам запросов. Под капотом 3.0 работает Lucene 10, что привносит дополнительную производительность в частности для векторного поиска. А еще OpenSearch научили работать по модели pull. Это означает, что он теперь может сам затягивать данные, например, из Kafka.

Статья в блоге с описанием нововведений

Песочница

Заметки к выпуску

Скачать OpenSearch

Вышел Data Prepper 2.11

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

Star-tree индексы — технология, которая предварительно вычисляет агрегации в OpenSearch. Функционал появился начиная с версии 2.18 и пока находится в экспериментальном формате. Если вы активно используете агрегации в работе, рекомендуем обратить внимание на эту технологию. Можно использовать только для неизменяемых индексов (подойдет для логов). Однако, есть и другие ограничения.

На приложенном изображении сравнение времени на выполнение агрегаций при традиционном способе и при помощи star-tree. Преимущество налицо.

Статья в блоге OpenSearch

Подробности в документации

Курс по поиску в ElasticSearch/OpenSearch

Мы готовим курс по поиску и подготовили программу тренинга. Тренинг будет длится два дня и охватит максимально подробно тематику поиска, агрегаций, создание оптимального индекса для поиска, формирование релевантности и многого другого.

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

Описание курса ElasticSearch/OpenSearch Поиск

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

Планируем проведение этого тренинга в июле-августе.

Заранее большое спасибо за обратную связь!

Get started with OpenSearch 3.1

Не успели мы опомнится от версии 3.0, как OpenSearch анонсировал 3.1. Лихо, что тут скажешь.

Статья в блоге OpenSearch

Загрузка

Заметки к выпуску

Redline-тестирование теперь доступно в OpenSearch Benchmark

Тестирование Redline содержит в себе:

🚀 Модуль управления для мониторинга пропускной способности запросов и сбоев в режиме реального времени.

🚀Саморегулирующийся механизм нагрузки, позволяющий приостанавливать и возобновлять работу клиентов на основе поведения кластера.

Читать в блоге OpenSearch

Making ingestion smarter: System ingest pipelines in OpenSearch

В OpenSearch 3.1 представлен системный ingest pipepline — новая возможность, сделанная специально для разработчиков плагинов. Она позволяет автоматически обрабатывать документы во время заливки данных, определяя системные процессоры, которые запускаются на основе полей или параметров при сопоставлении индекса. Это позволяет встраивать логику обработки непосредственно в плагин, не требуя от пользователей ручной настройки ingest pipeline. Читать в блоге OpenSearch.

Вышли Elastic 9.1/8.19

Интересный подход получается с релизами двух мажорных версий. Похоже, что в Elastic не хотят расстраивать пользователей, который уже основательно сжились с 8 версией. Но, как пишут, это в последний раз. Дальнейшего развития версии 8.х не будет. Подробности в блоге Elastic.

Пошаговое руководство по миграции из одного кластера в другой

В статье в блоге Elastic разобраны 3 способа миграции данных:

🚀 Переиндексация из удаленного кластера

🚀 Передача данных с использованием снимков

🚀 Перенос данных с помощью Logstash

Elasticsearch plugin for UBI: Analyze user behavior from search queries

UBI (User Behavioral Insights) — это стандарт, помогающий собирать и отслеживать статистику использования поисковых приложений. В этой статье рассматривается стандарт UBI и объясняется, как собирать аналитику с помощью плагина Elasticsearch.

VRL — просто, подробно и понятно

Vector является очень гибким агрегатором сообщений и поддерживает собственный язык для обработки событий - VRL. В статье разобраны примеры конфигурации Vector.

Introducing a more powerful, resilient, and observable ES|QL in Elasticsearch 8.19 & 9.1

Уже пробовали использовать ES|QL в Elasticsearch/Kibana? Штука упрощает написание запросов, когда от json уже рябит в глазах. В этой статье в блоге Elastic рассказывают об улучшениях этого языка в последний версиях продукта.

Вдогонку к предыдущему посту:

Tutorial: Threat hunting with ES|QL

Это уже ссылка на документацию.

5 Essential considerations for an Elasticsearch to OpenSearch migration

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

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

Diving deep into distributed microservices with OpenSearch and OpenTelemetry

В этой статье из блога OpenSearch рассказывают про новые функции, представленные в плагине Trace Analytics в версии 3.1: улучшенная визуализация карты сервисов, расширенная группировка интервалов и диаграммы распределения задержек. Также вы узнаете как использовать OpenTelemetry (OTel) Collector с OpenSearch Data Prepper для инструментирования, сбора и загрузки данных телеметрии в OpenSearch и как использовать OpenSearch Dashboards для изучения, визуализации и анализа процесса наблюдаемости.

Совет дня

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

С появлением сегментной репликации и удалённого хранилища в OpenSearch эта модель получила изменения. При репликации сегментов только основной узел сегмента выполняет операции индексации и записывает файлы сегментов в удалённое хранилище объектов, например, S3-совместимое хранилище, Google Cloud Storage или Azure Blob Storage. Затем сегменты-реплики параллельно загружают файлы сегментов из хранилища объектов, устраняя необходимость повторного выполнения операций индексации на каждой реплике. Удивительно, что в ElasticSearch так и не добавили этот функционал.

С версии OpenSearch 3.0 появились новые типы шардов: реплики для записи и реплики для поиска:

Реплики записи: резервные копии основного шарда. В случае сбоя основного шарда реплика записи может быть повышена до основного для сохранения доступности записи.

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

Читайте подробности о том как это устроено в блоге OpenSearch.

Описание в документации.

Векторный поиск в Elasticsearch: dense_vector, HNSW и фильтрация по атрибутам

В Elasticsearch поддержка векторного поиска реализована через поле dense_vector и алгоритм HNSW (Hierarchical Navigable Small World) для быстрого приближённого поиска ближайших соседей. В этой статье разобрано, как настроить индекс с векторным полем, добавить документы с векторами и выполнять запросы kNN с возможностью фильтрации по дополнительным атрибутам.

Какие улучшения сделал Яндекс в OpenSearch

Яндекс значительно улучшил OpenSearch, который они предоставляют в своем облаке.

Посмотрели всем коллективом доклад про OpenSearch с конференции Yandex NeuroScale 2025. Коллеги улучшили OpenSearch собственным алгоритмом балансировки, ускоренной индексацией, расширенным сжатием данных и поддержкой морфологии. Причем последнее они взяли из своего яндексового поиска.

Запись доклада по ссылке (смотреть с 4:27:00), там все подробности.

Пользуясь случаем приглашаем вас на наш интенсив по OpenSearch, который состоится уже

📅 29-31 октября. Программа тренинга.

На нем мы также поговорим о разных интересных фичах OpenSearch и вы на практике освоите это решение за максимально сжатый срок. Заявки на обучение присылайте на hello@gals.software или в @gals_education_bot.

Совет дня: как рассчитать сайзинг кластера

Расчет состоит из 3 формул (ниже). В первой формуле мы рассчитываем сколько нам нужно места для хранения, во второй накидываем 20% на дополнительные нужды, а в 3 формуле уже считаем количество нод, которое нужно предусмотреть для размещения такого количества данных. Этими формулами поделился Elastic на одном из вебинаров.

Формулы

1. Общее количество данных (Гб) = Сырые данные в день * Количество дней хранения * фактор трансформации данных * (количество реплик +1)

2. Общее хранилище данных (Гб) = Общее количество данных (Гб) *(1 + 0,15 запаса + 0,05 дополнительные нужды)

3. Общее количество нод = ОКРВВЕРХ (Общее хранилище данных (Гб) / Объём памяти на ноду / соотношение памяти к данных)

Пояснения по формулам:

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

ОКРВВЕРХ — округление вверх до ближайшего целого числа

Объем памяти на ноду берем стандартный 64 Гб (можно меньше). По CPU рекомендация использовать серверы с 16 ядрами.

Соотношение памяти к данным. В зависимости от фазы хранения (относительно политики управления жизненным циклом индексов, ILM), мы берем его равным 1/30 для горячей фазы, 1/100 для теплой и 1/500 для холодной.

Пример расчета

Допустим, к нам приходит 100 Гб/день и нам нужно хранить эти данные 30 дней с использованием 1 реплики. В итоге поучаем, что при таком раскладе нам нужно 4 ноды.

Общее количество данных (Гб) = 100 Гб* 30 * 1 * 2 = 6000 Гб
Общее хранилище данных (Гб) = 6000 Гб * 1,2 = 7200 Гб
Общее количество нод = ОКРВВЕРХ (7200 Гб / 64 / 30) = 4

@elasticstack_ru