Когда база устала искать: архитектура OpenSearch для больших данных

Реляционная СУБД - это ядро консистентности, но не оптимальный инструмент для полнотекстового и фасетного поиска. Логично разграничить роли: Postgres отвечает за транзакции и связи, а специализированный поисковый слой - за быстрый отклик и фильтрацию по множеству полей. 7 терабайт перестали быть проблемой: система масштабируется, а пользователи получают ответ мгновенно. OpenSearch стал не надстройкой, а естественной частью системы. Читать дальше на Хабре.

Делаем поиск более интеллектуальным с помощью системно генерируемых поисковых конвейеров

Новая статья в блоге OpenSearch. В OpenSearch 3.3 появились системно генерируемые поисковые конвейеры — новая возможность, разработанная для разработчиков плагинов. Она позволяет OpenSearch автоматически обрабатывать поисковые запросы, генерируя и подключая системные поисковые процессоры во время выполнения на основе контекста и параметров запроса.

Пошаговая настройка вывода логов из .NET-автотестов в ELK (Filebeat → Logstash → Elasticsearch → Kibana)

В этой статье разобран процесс вывода логов из приложения c автотестами на .NET в ELK с последующей визуализаций в Kibana.

ELK представляет из себя достаточно массивный инструмент для сбора, хранения, обработки и анализа логов, организации мониторингов. С наскоку разобраться с ним вряд ли получится, поэтому подготовили небольшую инструкцию с примерами - на базе простого теста прокинуть результаты до Kibana.

Интеграция OpenSearch: от функционального тестирования до проверки интеллекта поиска

В этой статье автор на реальном примере интеграции OpenSearch в LMS iSpring Learn рассказывает, как протестировать полнотекстовый поиск, сохранив баланс между качеством и трудозатратами. Будут разобраны не только базовые проверки, но и тестирование стемминга, релевантности, работы в распределённой системе и отказоустойчивости. Материал будет полезен тестировщикам и разработчикам, которые хотят понять, что скрывается за фразой «протестировать поиск». Читать дальше.

Better observability, deeper insights: OpenSearch’s new Piped Processing Language capabilities

Начиная с OpenSearch 3.3, язык конвейерной обработки (Piped Processing Language, PPL) включает новые и улучшенные возможности, упрощающие анализ логов и процессы наблюдения.

В этой статье рассмотрены новые команды и функции PPL на практических примерах распространённых сценариев использования аналитики логов. Вы узнаете, как эти улучшения помогают объединять несколько источников данных, обрабатывать неструктурированные данные логов и выполнять анализ временных рядов.

Вышел OpenSearch 3.4

Не успели мы опомниться от 3.3 как уже выходит новая версия.

🚀 Новый пользовательский интерфейс для агентного поиска.

🚀 Множество новых инструментов для повышения релевантности результатов поиска.

🚀 Расширенный набор  команд языка конвейерной обработки (PPL) для аналитических задач и задач мониторинга.

🚀 Значительное повышение производительности для задач агрегирования.

Подробности в блоге OpenSearch

@elasticsearch_ru

Introducing resource sharing: A new access control model for OpenSearch

Начиная с OpenSearch 3.3, плагин Security дополнился системой совместного использования ресурсов и контроля доступа , которая позволяет пользователям обмениваться ресурсами с другими пользователями или ролями. Эта модель переносит авторизацию на уровне ресурсов на объекты более высокого уровня, определенные плагинами, и создает согласованный опыт совместной работы в OpenSearch.

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

Ссылка на документацию

Новый Продвинутый курс по OpenSearch

📅 Когда: 18-20 марта 2026 года

👨‍💻 Для кого: для тех, кто уже имеет опыт работы с OpenSearch и хочет углубить знания, а также улучшить кругозор в продукте.

📖 Что ждет на курсе:

🔎 День 1

🚀 Безопасность в OpenSearch. Работа с ролевой моделью. Ограничения для пользователей: настройка безопасности на уровне документов и полей документов. Аудит-лог. Интеграция с LDAP.

🚀 Распределенная архитектура OpenSearch. Кросс-кластерная репликация. Кросс-кластерный поиск. Отказоустойчивая архитектура OpenSearch. Кворум мастер-нод. Split-brain.

🚀 Продвинутые технологии репликации данных: подокументная и сегментная репликации. Разделение шардов по назначениям: индексация и поиск. Контроль рабочей нагрузки.

🚀 Доступность и восстановление. Продвинутая настройка политики ISM. Создание снапшотов и восстановление из них. Работа с searchable snapshots в хранилище S3.

🔎 День 2

🚀 Эффективная работа с данными. Оптимизация хранения данных. Типы полей. Продвинутый маппинг полей. Настройки индексов для оптимального хранения.

🚀 Загрузка данных. Работа с Vector, Logstash, DataPrepper, OpenTelemetry Collector, Ingest Pipeline. Настраиваем эффективные пайплайны и портируем пайлайны из одного ETL-инструмента в другой.

🚀 Работа с PPL, DQL и DSL. Эффективный поиск по данным.
Мониторинг кластера. Сбор ключевых метрик. Prometheus, Zabbix, Performance Analyzer.

🔎 День 3

🚀 Работа в OpenSearch Dashboards. Ролевая модель. Мультитенантность. Продвинутые визуализации. Создание PNG и PDF-отчетов.

🚀 Работа с Observability. Создание визуализаций для данных наблюдаемости (логи, трейсы, метрики). Работа с Notebooks.

🚀 Оповещения. Настройка уведомлений из OpenSearch и OpenSearch Dashboards.

Подробнее о курсе на специальной странице. Там же можно оставить заявку на обучение и узнать другие подробности. Вопросы по курсу вы можете задать по почте hello@gals.software или в телеграм @galssoftware.

Создание системы мониторинга Logstash с использованием Prometheus и Grafana (пошаговое руководство)

Мониторинг Logstash — это суровая необходимость. Есть множество вариантов, когда что-то может пойти не так. В этой статье пошаговая инструкция по настройке мониторинга Logstash при помощи Prometheus, Prometheus-logstash-exporter и Grafana.

🎓 Приходите на наш тренинг OpenSearch Advanced, где мы будем в том числе ставить на мониторинг Logstash и изучать его ключевые метрики.

@elasticstack_ru

Decrease your storage costs with Amazon OpenSearch Service index rollups

В этой статье в блоге AWS рассмотрен механизм rollup в OpenSearch, который позволяет выполнять агрегацию данных в индексах для снижения объема хранимых данных. Это один из способов оптимизации.

@elasticstack_ru

Приглашаем вас на совместный вебинар Yandex Cloud и Галс Софтвэр, посвящённый возможностям и практическим аспектам работы с сервисом Managed OpenSearch.

📅 Дата: 2 февраля 2026 года
🕒 Формат: онлайн
🎙 Участие: бесплатное, по предварительной регистрации

👉 Зарегистрируйтесь на вебинар заранее, чтобы получить ссылку на трансляцию и материалы участников.

⚡️Спикеры вебинара:

🗣 Владислав Таболин, руководитель группы разработки Yandex Cloud, расскажет:

🚀 об архитектуре и особенностях сервиса Managed OpenSearch;
🚀 ключевых преимуществах управляемого сервиса;
🚀 сценариях использования OpenSearch в корпоративных и высоконагруженных системах;
🚀 вопросах надёжности, масштабирования и эксплуатации.

🗣Антон Касимов, основатель компании Галс Софтвэр, поделится:

🚀 методами оптимизации хранения данных в OpenSearch;
🚀 подходами к снижению затрат на хранение;
🚀 подробностями хранения данных в OpenSearch;
🚀 типичными ошибками и best practices из реальных проектов.

Кому будет полезен вебинар:

🚀 инженерам и архитекторам;
🚀 DevOps и SRE-специалистам;
🚀 руководителям ИТ-подразделений;
🚀 всем, кто использует или планирует использовать OpenSearch в продуктивных системах.

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

👉 Зарегистрируйтесь на вебинар, чтобы:

🚀 получить доступ к трансляции;
🚀 задать вопросы экспертам Yandex Cloud и Галс Софтвэр;
🚀 получить материалы и запись после мероприятия.

❗️ Будем рады видеть вас на вебинаре!

Совет дня (JVM)

ElasticSearch как и OpenSearch используют JVM для своей работы, и лучшие практики рекомендуют выделять около 50% доступной на узле памяти для JVM. JVM использует память для обеспечения быстрого доступа процесса Lucene к значениям индексов. Остальные 50% остаются для кэша файловой системы, который хранит в памяти данные, к которым часто обращаются. И еще одна рекомендация — не более 30 Гб на JVM Heap, это пороговое значение на использование сжатых указателей (ordinary object pointers (oops)). В противном случае JVM будет работать неоптимально.

Ниже мы собрали несколько статей, в которых есть полезные советы по настройке и мониторингу JVM.

Elasticsearch memory usage guide

High JVM memory pressure

JVM settings

Elasticsearch Circuit Breaker Exceptions: How to Handle Circuit Breakers

@elasticstack_ru