Вышли 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.
👍5🔥4
Интеграция OpenSearch: от функционального тестирования до проверки интеллекта поиска
В этой статье автор на реальном примере интеграции OpenSearch в LMS iSpring Learn рассказывает, как протестировать полнотекстовый поиск, сохранив баланс между качеством и трудозатратами. Будут разобраны не только базовые проверки, но и тестирование стемминга, релевантности, работы в распределённой системе и отказоустойчивости. Материал будет полезен тестировщикам и разработчикам, которые хотят понять, что скрывается за фразой «протестировать поиск». Читать дальше.
В этой статье автор на реальном примере интеграции OpenSearch в LMS iSpring Learn рассказывает, как протестировать полнотекстовый поиск, сохранив баланс между качеством и трудозатратами. Будут разобраны не только базовые проверки, но и тестирование стемминга, релевантности, работы в распределённой системе и отказоустойчивости. Материал будет полезен тестировщикам и разработчикам, которые хотят понять, что скрывается за фразой «протестировать поиск». Читать дальше.
🔥7👍4