Making ingestion smarter: System ingest pipelines in OpenSearch
В OpenSearch 3.1 представлен системный ingest pipepline — новая возможность, сделанная специально для разработчиков плагинов. Она позволяет автоматически обрабатывать документы во время заливки данных, определяя системные процессоры, которые запускаются на основе полей или параметров при сопоставлении индекса. Это позволяет встраивать логику обработки непосредственно в плагин, не требуя от пользователей ручной настройки ingest pipeline. Читать в блоге OpenSearch.
В OpenSearch 3.1 представлен системный ingest pipepline — новая возможность, сделанная специально для разработчиков плагинов. Она позволяет автоматически обрабатывать документы во время заливки данных, определяя системные процессоры, которые запускаются на основе полей или параметров при сопоставлении индекса. Это позволяет встраивать логику обработки непосредственно в плагин, не требуя от пользователей ручной настройки ingest pipeline. Читать в блоге OpenSearch.
👍1
Вышли Elastic 9.1/8.19
Интересный подход получается с релизами двух мажорных версий. Похоже, что в Elastic не хотят расстраивать пользователей, который уже основательно сжились с 8 версией. Но, как пишут, это в последний раз. Дальнейшего развития версии 8.х не будет. Подробности в блоге Elastic.
Интересный подход получается с релизами двух мажорных версий. Похоже, что в Elastic не хотят расстраивать пользователей, который уже основательно сжились с 8 версией. Но, как пишут, это в последний раз. Дальнейшего развития версии 8.х не будет. Подробности в блоге Elastic.
🔥4👍1👎1
Пошаговое руководство по миграции из одного кластера в другой
В статье в блоге Elastic разобраны 3 способа миграции данных:
🚀 Переиндексация из удаленного кластера
🚀 Передача данных с использованием снимков
🚀 Перенос данных с помощью Logstash
В статье в блоге Elastic разобраны 3 способа миграции данных:
🚀 Переиндексация из удаленного кластера
🚀 Передача данных с использованием снимков
🚀 Перенос данных с помощью Logstash
🔥4👍2
Elasticsearch plugin for UBI: Analyze user behavior from search queries
UBI (User Behavioral Insights) — это стандарт, помогающий собирать и отслеживать статистику использования поисковых приложений. В этой статье рассматривается стандарт UBI и объясняется, как собирать аналитику с помощью плагина Elasticsearch.
UBI (User Behavioral Insights) — это стандарт, помогающий собирать и отслеживать статистику использования поисковых приложений. В этой статье рассматривается стандарт UBI и объясняется, как собирать аналитику с помощью плагина Elasticsearch.
👍2🔥1
VRL — просто, подробно и понятно
Vector является очень гибким агрегатором сообщений и поддерживает собственный язык для обработки событий - VRL. В статье разобраны примеры конфигурации Vector.
Vector является очень гибким агрегатором сообщений и поддерживает собственный язык для обработки событий - VRL. В статье разобраны примеры конфигурации Vector.
👍5🔥1
Introducing a more powerful, resilient, and observable ES|QL in Elasticsearch 8.19 & 9.1
Уже пробовали использовать ES|QL в Elasticsearch/Kibana? Штука упрощает написание запросов, когда от json уже рябит в глазах. В этой статье в блоге Elastic рассказывают об улучшениях этого языка в последний версиях продукта.
Уже пробовали использовать ES|QL в Elasticsearch/Kibana? Штука упрощает написание запросов, когда от json уже рябит в глазах. В этой статье в блоге Elastic рассказывают об улучшениях этого языка в последний версиях продукта.
👍4🔥2
5 Essential considerations for an Elasticsearch to OpenSearch migration
В этой статье опытный автор рассказывает о пяти моментах, которые, на его взгляд, являются либо наиболее важными, либо наиболее упускаемыми из виду. Таким образом, вы сможете извлечь уроки из этого опыта и исследований и использовать их при миграции с Elasticsearch на OpenSearch.
Поставьте ⚡️, если вы когда-либо выполняли такую миграцию или собираетесь ее делать.
В этой статье опытный автор рассказывает о пяти моментах, которые, на его взгляд, являются либо наиболее важными, либо наиболее упускаемыми из виду. Таким образом, вы сможете извлечь уроки из этого опыта и исследований и использовать их при миграции с Elasticsearch на OpenSearch.
Поставьте ⚡️, если вы когда-либо выполняли такую миграцию или собираетесь ее делать.
⚡4👎3🔥3👍2
Diving deep into distributed microservices with OpenSearch and OpenTelemetry
В этой статье из блога OpenSearch рассказывают про новые функции, представленные в плагине Trace Analytics в версии 3.1: улучшенная визуализация карты сервисов, расширенная группировка интервалов и диаграммы распределения задержек. Также вы узнаете как использовать OpenTelemetry (OTel) Collector с OpenSearch Data Prepper для инструментирования, сбора и загрузки данных телеметрии в OpenSearch и как использовать OpenSearch Dashboards для изучения, визуализации и анализа процесса наблюдаемости.
В этой статье из блога OpenSearch рассказывают про новые функции, представленные в плагине Trace Analytics в версии 3.1: улучшенная визуализация карты сервисов, расширенная группировка интервалов и диаграммы распределения задержек. Также вы узнаете как использовать OpenTelemetry (OTel) Collector с OpenSearch Data Prepper для инструментирования, сбора и загрузки данных телеметрии в OpenSearch и как использовать OpenSearch Dashboards для изучения, визуализации и анализа процесса наблюдаемости.
👍4🔥4👎1
Совет дня
В OpenSearch для индекса вы можете создать два типа шардов: основные шарды и шарды-реплики. Основные шарды отвечают за индексацию и поиск, а шарды-реплики хранят копию данных основных шардов для обеспечения избыточности и обслуживания поисковых запросов. Количество основных шардов настраивается при создании индекса, и его нельзя изменить позже без переиндексации.
С появлением сегментной репликации и удалённого хранилища в OpenSearch эта модель получила изменения. При репликации сегментов только основной узел сегмента выполняет операции индексации и записывает файлы сегментов в удалённое хранилище объектов, например, S3-совместимое хранилище, Google Cloud Storage или Azure Blob Storage. Затем сегменты-реплики параллельно загружают файлы сегментов из хранилища объектов, устраняя необходимость повторного выполнения операций индексации на каждой реплике. Удивительно, что в ElasticSearch так и не добавили этот функционал.
С версии OpenSearch 3.0 появились новые типы шардов: реплики для записи и реплики для поиска:
Реплики записи: резервные копии основного шарда. В случае сбоя основного шарда реплика записи может быть повышена до основного для сохранения доступности записи.
Реплики поиска: обслуживают исключительно поисковые запросы и не могут быть повышены до основных.
Читайте подробности о том как это устроено в блоге OpenSearch.
Описание в документации.
В OpenSearch для индекса вы можете создать два типа шардов: основные шарды и шарды-реплики. Основные шарды отвечают за индексацию и поиск, а шарды-реплики хранят копию данных основных шардов для обеспечения избыточности и обслуживания поисковых запросов. Количество основных шардов настраивается при создании индекса, и его нельзя изменить позже без переиндексации.
С появлением сегментной репликации и удалённого хранилища в OpenSearch эта модель получила изменения. При репликации сегментов только основной узел сегмента выполняет операции индексации и записывает файлы сегментов в удалённое хранилище объектов, например, S3-совместимое хранилище, Google Cloud Storage или Azure Blob Storage. Затем сегменты-реплики параллельно загружают файлы сегментов из хранилища объектов, устраняя необходимость повторного выполнения операций индексации на каждой реплике. Удивительно, что в ElasticSearch так и не добавили этот функционал.
С версии OpenSearch 3.0 появились новые типы шардов: реплики для записи и реплики для поиска:
Реплики записи: резервные копии основного шарда. В случае сбоя основного шарда реплика записи может быть повышена до основного для сохранения доступности записи.
Реплики поиска: обслуживают исключительно поисковые запросы и не могут быть повышены до основных.
Читайте подробности о том как это устроено в блоге OpenSearch.
Описание в документации.
👍5🔥2
Векторный поиск в Elasticsearch: dense_vector, HNSW и фильтрация по атрибутам
В Elasticsearch поддержка векторного поиска реализована через поле dense_vector и алгоритм HNSW (Hierarchical Navigable Small World) для быстрого приближённого поиска ближайших соседей. В этой статье разобрано, как настроить индекс с векторным полем, добавить документы с векторами и выполнять запросы kNN с возможностью фильтрации по дополнительным атрибутам.
В Elasticsearch поддержка векторного поиска реализована через поле dense_vector и алгоритм HNSW (Hierarchical Navigable Small World) для быстрого приближённого поиска ближайших соседей. В этой статье разобрано, как настроить индекс с векторным полем, добавить документы с векторами и выполнять запросы kNN с возможностью фильтрации по дополнительным атрибутам.
🔥4👍1
Какие улучшения сделал Яндекс в OpenSearch
Яндекс значительно улучшил OpenSearch, который они предоставляют в своем облаке.
Посмотрели всем коллективом доклад про OpenSearch с конференции Yandex NeuroScale 2025. Коллеги улучшили OpenSearch собственным алгоритмом балансировки, ускоренной индексацией, расширенным сжатием данных и поддержкой морфологии. Причем последнее они взяли из своего яндексового поиска.
Запись доклада по ссылке (смотреть с 4:27:00), там все подробности.
Пользуясь случаем приглашаем вас на наш интенсив по OpenSearch, который состоится уже
📅 29-31 октября. Программа тренинга.
На нем мы также поговорим о разных интересных фичах OpenSearch и вы на практике освоите это решение за максимально сжатый срок. Заявки на обучение присылайте на [email protected] или в @gals_education_bot.
Яндекс значительно улучшил OpenSearch, который они предоставляют в своем облаке.
Посмотрели всем коллективом доклад про OpenSearch с конференции Yandex NeuroScale 2025. Коллеги улучшили OpenSearch собственным алгоритмом балансировки, ускоренной индексацией, расширенным сжатием данных и поддержкой морфологии. Причем последнее они взяли из своего яндексового поиска.
Запись доклада по ссылке (смотреть с 4:27:00), там все подробности.
Пользуясь случаем приглашаем вас на наш интенсив по OpenSearch, который состоится уже
📅 29-31 октября. Программа тренинга.
На нем мы также поговорим о разных интересных фичах OpenSearch и вы на практике освоите это решение за максимально сжатый срок. Заявки на обучение присылайте на [email protected] или в @gals_education_bot.
👍4🔥2
Совет дня: как рассчитать сайзинг кластера
Расчет состоит из 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
Расчет состоит из 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
👍9👎4🔥4
Вышел OpenSearch 3.3
Заметки к выпуску
Песочница
В этом релизе представлена предварительная версия полностью переработанного интерфейса OpenSearch Dashboards. На изображении, прикрепленном к этому посту, вы как раз можете видеть переработанный раздел Discover.
На другом изображении вы видите раздел Service Map — карту сервисов, построенную на основе трейсов.
О других улучшениях читайте по ссылке выше.
Заметки к выпуску
Песочница
В этом релизе представлена предварительная версия полностью переработанного интерфейса OpenSearch Dashboards. На изображении, прикрепленном к этому посту, вы как раз можете видеть переработанный раздел Discover.
На другом изображении вы видите раздел Service Map — карту сервисов, построенную на основе трейсов.
О других улучшениях читайте по ссылке выше.
🔥7👍2
Приглашаем вас на осеннюю серию тренингов-интенсивов по Elasticsearch и OpenSearch.
📅 ElasticSearch База 22-24 октября 2025
📅 OpenSearch База 29-31 октября 2025
Интенсивы, в отличие от многомесячных тренингов, позволяют максимально быстро погрузиться в тему и начинать работу с соответствующей системой сразу после прохождения тренинга.
Мы опросили участников предыдущих потоков и сформулировали основные преимущества от прохождения тренингов:
📖 устранить пробелы. Часто знания по соответствующей системе ограничиваются эпизодическим изучением документации и фрагментарны. Интенсивы помогут систематизировать знания и откроют для вас новые возможности уже знакомой системы.
📖 делать своими силами. Участие подрядчиков в проектах внедрения подразумевает предоставление доступа в ваше окружение. Прохождение официальных тренингов позволит вам выполнять работы силами штатных сотрудников.
📖 распространять знания. Сотрудники, прошедшие тренинг, не просто совершенствуют свои собственные технические навыки — они привносят полученные знания в коллектив и делятся ими со своими коллегами.
❗️Полное расписание тренингов.
Подробную информацию вы можете запросить, написав @galssoftware или через почту [email protected].
📅 ElasticSearch База 22-24 октября 2025
📅 OpenSearch База 29-31 октября 2025
Интенсивы, в отличие от многомесячных тренингов, позволяют максимально быстро погрузиться в тему и начинать работу с соответствующей системой сразу после прохождения тренинга.
Мы опросили участников предыдущих потоков и сформулировали основные преимущества от прохождения тренингов:
📖 устранить пробелы. Часто знания по соответствующей системе ограничиваются эпизодическим изучением документации и фрагментарны. Интенсивы помогут систематизировать знания и откроют для вас новые возможности уже знакомой системы.
📖 делать своими силами. Участие подрядчиков в проектах внедрения подразумевает предоставление доступа в ваше окружение. Прохождение официальных тренингов позволит вам выполнять работы силами штатных сотрудников.
📖 распространять знания. Сотрудники, прошедшие тренинг, не просто совершенствуют свои собственные технические навыки — они привносят полученные знания в коллектив и делятся ими со своими коллегами.
❗️Полное расписание тренингов.
Подробную информацию вы можете запросить, написав @galssoftware или через почту [email protected].
🔥5👍3
Когда база устала искать: архитектура OpenSearch для больших данных
Реляционная СУБД - это ядро консистентности, но не оптимальный инструмент для полнотекстового и фасетного поиска. Логично разграничить роли: Postgres отвечает за транзакции и связи, а специализированный поисковый слой - за быстрый отклик и фильтрацию по множеству полей. 7 терабайт перестали быть проблемой: система масштабируется, а пользователи получают ответ мгновенно. OpenSearch стал не надстройкой, а естественной частью системы. Читать дальше на Хабре.
Реляционная СУБД - это ядро консистентности, но не оптимальный инструмент для полнотекстового и фасетного поиска. Логично разграничить роли: Postgres отвечает за транзакции и связи, а специализированный поисковый слой - за быстрый отклик и фильтрацию по множеству полей. 7 терабайт перестали быть проблемой: система масштабируется, а пользователи получают ответ мгновенно. OpenSearch стал не надстройкой, а естественной частью системы. Читать дальше на Хабре.
🔥7👍3
Elastic Stack recipes
Приглашаем вас на осеннюю серию тренингов-интенсивов по Elasticsearch и OpenSearch. 📅 ElasticSearch База 22-24 октября 2025 📅 OpenSearch База 29-31 октября 2025 Интенсивы, в отличие от многомесячных тренингов, позволяют максимально быстро погрузиться в…
Дополнительный тренинг OpenSearch
Приходите на дополнительный тренинг по OpenSearch в этом году 22-24 декабря. Мы обновили программу до версии 3.3 и добавили новые блоки:
🚀 сегментная репликация
🚀 мониторинг (Performance Analyzer)
🚀 отправка оповещений
🚀 работа с Vector
🚀 работа с Ingest pipelines
❗️ Вы получите опыт работы с самой последней версией OpenSearch.
Программа тренинга
Подробную информацию вы можете запросить, написав @galssoftware или через почту [email protected].
Приходите на дополнительный тренинг по OpenSearch в этом году 22-24 декабря. Мы обновили программу до версии 3.3 и добавили новые блоки:
🚀 сегментная репликация
🚀 мониторинг (Performance Analyzer)
🚀 отправка оповещений
🚀 работа с Vector
🚀 работа с Ingest pipelines
❗️ Вы получите опыт работы с самой последней версией OpenSearch.
Программа тренинга
Подробную информацию вы можете запросить, написав @galssoftware или через почту [email protected].
🔥5👍3
Делаем поиск более интеллектуальным с помощью системно генерируемых поисковых конвейеров
Новая статья в блоге OpenSearch. В OpenSearch 3.3 появились системно генерируемые поисковые конвейеры — новая возможность, разработанная для разработчиков плагинов. Она позволяет OpenSearch автоматически обрабатывать поисковые запросы, генерируя и подключая системные поисковые процессоры во время выполнения на основе контекста и параметров запроса.
Новая статья в блоге OpenSearch. В OpenSearch 3.3 появились системно генерируемые поисковые конвейеры — новая возможность, разработанная для разработчиков плагинов. Она позволяет OpenSearch автоматически обрабатывать поисковые запросы, генерируя и подключая системные поисковые процессоры во время выполнения на основе контекста и параметров запроса.
🔥7👍2
Пошаговая настройка вывода логов из .NET-автотестов в ELK (Filebeat → Logstash → Elasticsearch → Kibana)
В этой статье разобран процесс вывода логов из приложения c автотестами на .NET в ELK с последующей визуализаций в Kibana.
ELK представляет из себя достаточно массивный инструмент для сбора, хранения, обработки и анализа логов, организации мониторингов. С наскоку разобраться с ним вряд ли получится, поэтому подготовили небольшую инструкцию с примерами - на базе простого теста прокинуть результаты до Kibana.
В этой статье разобран процесс вывода логов из приложения c автотестами на .NET в ELK с последующей визуализаций в Kibana.
ELK представляет из себя достаточно массивный инструмент для сбора, хранения, обработки и анализа логов, организации мониторингов. С наскоку разобраться с ним вряд ли получится, поэтому подготовили небольшую инструкцию с примерами - на базе простого теста прокинуть результаты до Kibana.
👍4🔥3