OpenSearch: стек для поиска, аналитики и ИИ‑решений

OpenSearch используют для анализа логов, мониторинга безопасности в SIEM‑системах, а также как движок полнотекстового поиска. Ещё среди сценариев — семантический и гибридный поиск, технология RAG, которая обогащает ответы больших языковых моделей данными из внешних источников.

Согласно рейтингу DB‑Engines, OpenSearch занимает пятое место среди поисковых систем и третье — среди векторных СУБД.

В статье расскажем, чем OpenSearch отличается от Elasticsearch, какие бизнес‑задачи он решает и почему его будущее связано с векторным поиском и генеративным ИИ. Также покажем, как развернуть кластер с помощью нашего сервиса Yandex Managed Service for OpenSearch.

Что такое OpenSearch и для чего он нужен

OpenSearch — это распределённая система для поиска, аналитики и визуализации данных с открытым исходным кодом. В её основе лежат два ключевых компонента: ядро OpenSearch и интерфейс визуализации OpenSearch Dashboards, а также набор дополнительных компонентов для упрощения работы с данными, например Data Prepper. Проект появился в 2021 году как форк — независимое ответвление — Elasticsearch и Kibana.

Поисковые возможности системы построены на библиотеке Apache Lucene^™, которая является корневым компонентом слоя хранения данных, реализует логику хранения и индексации данных, а также наделяет OpenSearch возможностями высокопроизводительного полнотекстового поиска. Индексация данных в OpenSearch осуществляется в режиме, близком к реальному времени — near real‑time. Это значит, что новые данные становятся доступны для поиска не мгновенно, а после операции refresh, которая по умолчанию выполняется каждую секунду и частотой которой можно управлять. При этом получение конкретного документа по его идентификатору через Get API происходит моментально.

Для чего используют OpenSearch

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

Полнотекстовый поиск

OpenSearch является платформой для организации полнотекстового поиска. Платформу используют в интернет‑магазинах, на контентных платформах, а также в корпоративных порталах. Система индексирует текстовые данные и даёт возможность выполнять сложные поисковые запросы.

Для выполнения поисковых запросов OpenSearch поддерживает несколько вариантов формирования запросов, один из самых популярных — язык Lucene Query Language. OpenSearch поддерживает разные виды поиска. Для REST API возможно использование внутреннего DSL, также существует поддержка SQL‑синтаксиса.

Платформа включает все необходимые инструменты, такие как быстрый поиск, фасетную навигацию, автодополнение и точное ранжирование. Фасетная навигация — это механизм, который помогает пользователям фильтровать результаты по заданным категориям.

Для точного ранжирования, то есть определения релевантности результатов, платформа использует алгоритм BM25. Эти возможности особенно полезны в сфере электронной коммерции и при работе с системами управления документами.

Векторный поиск и ИИ‑приложения

OpenSearch работает как векторная база данных. Платформа хранит эмбеддинги — числовые представления текста, изображений и других данных. Их размещают в специальном поле knn_vector, что позволяет искать информацию по смысловой близости.

Для этого применяют алгоритмы k‑NN и ANN. Для реализации kNN‑поиска в OpenSearch используется Faiss — библиотека, объединяющая алгоритмы точного и приближённого поиска ближайших соседей (kNN/ANN), включая HNSW, позволяющая эффективно хранить большой объём данных на диске. На основе этих механизмов работает семантический поиск. Можно также использовать гибридный поиск, который сочетает классический поиск по ключевым словам с векторным.

Эти инструменты необходимы для генеративного ИИ. Например, для технологии RAG — Retrieval‑Augmented Generation. RAG обогащает ответы больших языковых моделей данными из проверенных источников.

В сценариях RAG модель обращается к OpenSearch за релевантными документами до того, как сгенерирует ответ. Для такой работы доступны готовые инструменты, например RAG Tool в плагине ML Commons.

Гибридный поиск уже стал стандартом для ИИ‑приложений, поскольку обеспечивает высокую точность и релевантность результатов. Платформа поддерживает гибридные запросы. Для этого OpenSearch использует специальные алгоритмы, например Reciprocal Rank Fusion (RRF). Этот метод объединяет оценки релевантности, полученные из обоих видов поиска.

Мониторинг безопасности

Для мониторинга безопасности OpenSearch использует компонент Security Analytics. Этот инструмент позволяет легко построить решение класса SIEM — Security Information and Event Management.

Данная система собирает и анализирует все события, связанные с безопасностью. Благодаря ей можно эффективно выявлять потенциальные угрозы, расследовать инциденты и оперативно на них реагировать.

Аналитика логов и наблюдаемость

Платформа помогает создавать системы наблюдаемости — комплексный подход к мониторингу, известный как Observability. Этот подход позволяет собирать и анализировать логи, метрики и трейсы.

OpenSearch поддерживается большинством стандартных решений для поставки данных из логов и трейсов: logstash, file.d, vector и другими. Обилие инструментов позволяет построить надёжную систему агрегации и хранения логов и чувствительной информации.

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

В OpenSearch интегрирован специальный плагин для наблюдаемости, а сама платформа также поддерживает стандарт OpenTelemetry.

Чем OpenSearch отличается от Elasticsearch

У OpenSearch и Elasticsearch общие корни, но это два независимых проекта с разными моделями управления и лицензирования. Они развиваются по собственным дорожным картам, и различия между ними становятся всё заметнее.

История разделения: лицензии и форк

Разделение началось в 2021 году, когда компания Elastic изменила лицензионную политику для Elasticsearch и Kibana. Вместо свободной Apache^® 2.0 была введена двойная модель: Server Side Public License (SSPL) и коммерческая Elastic License 2.0 (ELv2). Лицензия SSPL не признана открытой организацией Open Source Initiative, а ELv2 прямо запрещает использовать продукты для создания управляемых облачных сервисов без отдельного соглашения с Elastic.

В ответ на эти изменения Amazon Web Services создала форк на основе последних версий, доступных под лицензией Apache 2.0. Так появился проект OpenSearch. Позже, в 2024 году, его передали под управление независимой организации OpenSearch Software Foundation, которая входит в состав Linux Foundation. Это обеспечило проекту нейтральное развитие, не зависящее от одного вендора.

Ключевые различия в функциональности

Основное различие между проектами заключается в подходе к платным функциям:

• В Elasticsearch многие расширенные возможности безопасности и машинного обучения требуют платной подписки. К ним относятся управление доступом на уровне полей и документов, а также функции для обнаружения аномалий и анализа данных.

• В OpenSearch аналогичные инструменты доступны бесплатно под лицензией Apache 2.0. Например, плагин Security обеспечивает шифрование, аутентификацию и ролевую модель доступа. А плагины Anomaly Detection и ML Commons позволяют решать задачи машинного обучения и выполнять инференс — применение обученных моделей.

Модели управления и совместимость

Проекты различаются и по модели управления. OpenSearch развивается сообществом под руководством независимого фонда — это делает процесс принятия решений прозрачным и открытым для всех участников. Elasticsearch — коммерческий продукт, стратегию развития которого определяет компания Elastic.

Ранние версии OpenSearch первой мажорной ветки были обратно совместимы с API Elasticsearch 7.10, в том числе на уровне сетевого протокола. Это позволяло старым клиентам работать с новым сервером. Но сейчас проекты развиваются независимо, и совместимость между новыми версиями не гарантируется.

Основные компоненты экосистемы OpenSearch

Экосистема OpenSearch состоит из нескольких ключевых компонентов, которые вместе обеспечивают полный цикл работы с данными: от сбора и обработки до поиска, аналитики и визуализации.

Компоненты экосистемы OpenSearch

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

• Security — обеспечивает шифрование, аутентификацию и авторизацию на основе ролей. Поддерживает интеграцию с корпоративными каталогами через SAML, LDAP и OIDC.
• Alerting — позволяет настраивать мониторинг данных и отправлять уведомления при срабатывании триггеров.
• Index Management — автоматизирует жизненный цикл индексов: создание новых по расписанию, сжатие и удаление старых данных.
• Anomaly Detection — находит отклонения в данных в режиме, близком к реальному времени, используя алгоритм Random Cut Forest.
• ML Commons — даёт возможность управлять ML‑моделями и применять их для анализа данных. Это основа для интеграции с нейросетями.

Архитектура и ключевые концепции

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

Узлы и кластеры

Кластер — это группа из одного или нескольких узлов, которые совместно хранят данные и обрабатывают запросы. Для эффективной работы узлы в кластере могут выполнять разные роли:

• Узлы данных (Data nodes) — хранят данные и выполняют основную работу: индексацию, поиск и агрегацию.
• Узлы управления (Cluster manager nodes) — отвечают за работоспособность и целостность кластера. Отслеживают состояние узлов, создают и удаляют индексы, а также распределяют шарды. В продакшн‑средах рекомендуется использовать как минимум три выделенных узла управления для отказоустойчивости.
• Координирующие узлы (Coordinating‑only nodes) — действуют как умные маршрутизаторы. Принимают запросы, распределяют их по узлам данных, а затем собирают и возвращают финальный результат. Такие узлы не хранят данные и не управляют кластером, что позволяет разгрузить остальные компоненты системы.

Индексы и документы

Данные в OpenSearch организованы в индексы — логические коллекции документов. Если проводить аналогию с реляционными базами данных, индекс похож на таблицу, а документ — на строку в этой таблице. Каждый документ представляет собой JSON‑объект с уникальным идентификатором.

Шарды и реплики

Чтобы хранить большие объёмы данных и обеспечивать отказоустойчивость, каждый индекс делится на части — шарды. По сути, каждый шард — это самостоятельный мини‑индекс на базе Lucene. Шарды распределяются по разным узлам кластера — это позволяет обрабатывать запросы параллельно и хранить данные, объём которых превышает ресурсы одного сервера.

Шарды бывают двух типов:

• Основные содержат исходные данные. Их количество задаётся при создании индекса и не может быть изменено напрямую, но его можно скорректировать через операции разделения или сжатия индекса.
• Реплики — это копии основных шардов. Они решают две задачи: повышают отказоустойчивость (в случае сбоя реплика может стать основным шардом) и увеличивают производительность поиска, поскольку запросы на чтение могут обрабатываться параллельно на нескольких копиях данных.

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

Будущее OpenSearch: векторный поиск и ИИ

В 2025 году развитие OpenSearch сосредоточено на двух ключевых направлениях: совершенствовании векторного поиска и глубокой интеграции с генеративным ИИ. Проект позиционируется как открытая платформа для ИИ‑приложений, и команда активно работает над производительностью и новыми функциями в этой области.

Начиная с версии OpenSearch 3 система перешла на новую версию библиотеки Apache Lucene 10. Это обновление ядра принесло значительный прирост производительности. Кроме того, в версиях этой линейки появились новые оптимизации для векторных нагрузок, например технология memory‑optimized search, которая эффективно сочетает возможности Lucene и библиотеки Faiss для работы с данными в оперативной памяти.

Другое важное направление — квантование векторов. Это процесс сжатия данных, который позволяет значительно сократить объём памяти и дискового пространства, нужных для хранения эмбеддингов, при контролируемой потере точности. OpenSearch поддерживает несколько методов, включая скалярное квантование для Lucene, а также продуктовое и бинарное для Faiss.

Команда проекта активно работает над ускорением векторных операций с помощью GPU. В версии 3.0 эта возможность была экспериментальной, а уже в 3.1 стала общедоступной. Использование GPU на базе технологии NVIDIA cuVS позволяет ускорить построение векторных индексов до 9,3 раза и снизить затраты на инфраструктуру почти в четыре раза по сравнению с CPU. Для этого разработали специальный сервис Vector Index Build Service, который использует механизм удалённого построения индекса (remote index build) для выноса ресурсоёмких задач на выделенные машины с GPU.

Установка и настройка OpenSearch

Существует два основных подхода к развёртыванию OpenSearch: самостоятельная установка на собственных серверах и использование управляемых облачных сервисов. К последним относится Yandex Managed Service for OpenSearch.

Варианты самостоятельной установки

Для самостоятельного развёртывания OpenSearch предлагает несколько официальных способов:

• Архивы (tarball, ZIP) для быстрой установки на Linux или Windows.
• Docker^®‑образы и готовые конфигурации для Docker Compose.
• Helm^®‑чарты и Kubernetes^® Operator для развёртывания в облачных средах.
• Пакетные менеджеры apt и yum для установки на серверы с Debian^™ или RPM‑based дистрибутивами.

Для быстрого старта и тестирования удобно использовать демонстрационную конфигурацию безопасности. Начиная с версии 2.12 перед первым запуском нужно задать пароль администратора через переменную OPENSEARCH_INITIAL_ADMIN_PASSWORD.

Ключевые настройки для продакшн‑среды

Правильная настройка — залог стабильности и производительности кластера. Вот несколько ключевых моментов, на которые стоит обратить внимание:

• Память для Java (JVM Heap). Рекомендуется выделять под JVM Heap около 50% оперативной памяти узла, но не более 32 ГБ. Этот порог связан с работой механизма compressed oops — оптимизации использования памяти в Java. Превышение этого значения может привести к снижению производительности.
• Параметры операционной системы. Для стабильной работы в продакшн‑среде важно увеличить лимит на количество открытых файлов до 65 536 и более, а также настроить параметр vm.max_map_count на значение 262144. Кроме того, рекомендуется отключить swap‑файл, чтобы избежать вытеснения данных из оперативной памяти на диск.
• Настройка сети и обнаружения. Чтобы узлы могли найти друг друга и сформировать кластер, нужно указать их адреса в параметре discovery.seed_hosts. Также важно определить список узлов, которые будут участвовать в первоначальном выборе управляющего узла, в параметре cluster.initial_cluster_manager_nodes.
• Безопасность. Плагин Security установлен по умолчанию, и его настоятельно рекомендуется использовать в продакшн‑среде. Ключевые шаги — настройка шифрования TLS как для обмена данными между узлами, так и для клиентских запросов, а также конфигурация аутентификации и авторизации.
• Топология кластера. «Золотой стандарт» для отказоустойчивых инсталляций — использование трёх выделенных узлов управления, размещённых в разных зонах доступности. Это позволяет сохранить кворум — минимально необходимое число узлов для принятия решений — и избежать сбоев. Основную нагрузку по хранению и обработке данных при этом несут отдельные узлы данных.

OpenSearch в Yandex Cloud: управляемый сервис для ваших задач

Для тех, кто хочет использовать OpenSearch, но не готов тратить время на администрирование, мы предлагаем Yandex Managed Service for OpenSearch. Мы берём на себя развёртывание, обслуживание и мониторинг кластеров.

Быстрый старт и надёжность

Кластер можно развернуть за несколько минут, а мы автоматически оптимизируем его настройки под выбранную конфигурацию. Сервис обеспечивает высокий уровень надёжности и безопасности:

• Резервное копирование. Сервис автоматически создаёт резервные копии индексов. Их также можно делать вручную и хранить в Yandex Object Storage.
• Шифрование. Данные на дисках можно шифровать с помощью ключей из Yandex Key Management Service — это обеспечивает дополнительный уровень защиты.
• Безопасные подключения. Все сетевые подключения к кластеру защищены по протоколу TLS.
• Балансировка данных на кластерах — с помощью алгоритма на основе покоординатного спуска последовательно балансируем количество всех шардов на хосте, количество шардов одного индекса на хосте, количество primary‑шардов, количество primary‑шардов одного индекса на хосте и объём свободного места на хосте. На каждом этапе балансируем так, чтобы улучшилась балансировка по текущей координате, а из всех вариантов выбираем такой, чтобы максимально улучшить балансировку и по остальным координатам.

Кроме того, мы улучшили сервис в области сжатия данных — доработали Index State Manager, Lucene Codecs и ускорение индексации данных.

Визуализация и морфология для русского языка

В каждый кластер уже встроен OpenSearch Dashboards — интерфейс для визуализации данных и управления. Для централизованного управления доступом поддерживается аутентификация по протоколу SAML 2.0 — это позволяет интегрировать OpenSearch с корпоративными системами учёта пользователей.

Чтобы повысить точность поиска на русском языке, мы встроили в сервис наш собственный плагин yandex‑lemmer. Он выполняет лемматизацию — приводит слова к их словарной форме. Например, благодаря ему запрос «идут дожди» сможет найти документы, в которых содержатся фразы «идёт дождь» или «шёл дождь».

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

В результате Yandex Managed Service for OpenSearch освобождает команды от рутинных задач по управлению инфраструктурой и позволяет сосредоточиться на развитии продукта и анализе данных.