OpenSearch или Elasticsearch: что выгоднее и когда

MAATRIX

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

Откуда взялся раскол

До версии 7.10 Elasticsearch распространялся под Apache 2.0 — открытой лицензией без ограничений на коммерческое использование. В январе 2021 года Elastic NV сменил лицензию на SSPL (Server Side Public License) с опциональной Elastic License, мотивируя это защитой от облачных провайдеров, которые продавали Elasticsearch как услугу, не отдавая ничего разработчикам. SSPL формально open source, но OSI её таковой не признаёт: она обязывает публиковать исходники всей инфраструктуры, через которую вы предоставляете сервис на базе продукта, а не только патчи к самому продукту.

AWS, для которой Elasticsearch был частью Amazon OpenSearch Service, с новой лицензией жить не могла — и форкнула последнюю Apache 2.0 версию (7.10.2) в отдельный проект OpenSearch. С 2021 года кодовые базы разошлись: Elastic активно развивает свою ветку, OpenSearch — свою, под управлением OpenSearch Software Foundation (с 2024 года проект передан в Linux Foundation). В 2024 году Elastic частично отыграл назад: с версии 9 добавил AGPL v3 как ещё один вариант лицензии — это тоже открытая лицензия, признанная OSI, но с обязательством публиковать исходники изменённого кода при сетевом распространении, что для большинства пользователей, не занимающихся перепродажей Elasticsearch как сервиса, не критично.

Лицензии: что можно, а что нет

Здесь и кроется главный практический вопрос — не «что быстрее», а «что вам юридически можно делать».

Если вы просто ставите движок для своего проекта и не собираетесь перепродавать его как услугу — юридическая разница почти не ощущается на практике: обе лицензии позволяют использовать продукт бесплатно. Разница начинает иметь значение, если вы (a) хостинг-провайдер, предлагающий managed Elasticsearch клиентам, (b) разрабатываете форк с изменениями и хотите его распространять, или (c) вашей компании юридический отдел требует OSI-совместимую лицензию по политике комплаенса.

Совместимость API и миграция

Обе системы используют общий REST API формата — запросы вида PUT /index/_doc/1 работают в обеих. До версии 7.10 клиенты полностью взаимозаменяемы. Дальше начинаются расхождения:

• Elasticsearch с версии 8 требует TLS и security по умолчанию (раньше это было опционально), ввёл ILM (Index Lifecycle Management) в новом виде, добавил ESQL — собственный язык запросов.
• OpenSearch развивает свой Index State Management (ISM) — функционально похож на ILM, но синтаксис отличается.
• Клиентские библиотеки официально поддерживают только «свою» версию: elasticsearch-py версии 8.x может ломаться на OpenSearch и наоборот из-за проверки заголовка версии сервера. Для OpenSearch есть отдельный клиент opensearch-py.
• Дашборды: Kibana работает только с Elasticsearch, OpenSearch Dashboards — форк Kibana под Apache 2.0, тоже разошедшийся в деталях UI. Про выбор между ними у нас есть отдельный разбор — Grafana или Kibana: что выбрать для сервера касается похожей темы стека визуализации логов.

Миграция данных между кластерами реализуется через reindex API или снятие snapshot и restore на другой стороне — оба поддерживают формат snapshot, совместимый на уровне S3-репозитория, но кросс-версийный reindex между Elasticsearch 8.x и OpenSearch 2.x иногда спотыкается на изменившихся mapping-типах (особенно text/keyword с новыми анализаторами). Перед миграцией продакшен-индекса всегда тестируйте reindex на копии — не на боевых данных.

Производительность: без придуманных цифр

Здесь стоит быть честным: обе базы кода происходят из одного форка 2021 года и до сих пор архитектурно близки — тот же Lucene под капотом (обе команды используют актуальные версии Apache Lucene, хотя и не всегда синхронно), тот же принцип шардирования и репликации. Публичные бенчмарки от заинтересованных сторон (Elastic сравнивает в свою пользу, AWS — в свою) достаточно предвзяты, чтобы им не доверять напрямую, а независимых воспроизводимых тестов на сопоставимых версиях немного.

Что можно сказать без вымышленных цифр:

• На типовых нагрузках (полнотекстовый поиск, агрегации, логи) разница в throughput между актуальными версиями обеих систем на одинаковом железе, по опыту эксплуатации, обычно укладывается в единицы-десятки процентов — не в разы. Если вам критичны точные цифры под вашу нагрузку — тестируйте на своих данных, готовых универсальных цифр от разработчиков этой статьи нет.
• OpenSearch добавил собственные фичи для больших кластеров (например, сегментную репликацию как альтернативу document-based), которые снижают нагрузку на индексацию в кластерах с большим числом реплик — но выигрыш заметен в основном на крупных инсталляциях, не на одном-двух узлах.
• Elasticsearch активнее вкладывается в векторный поиск и интеграцию с ML-инференсом «из коробки» — если вам нужен semantic search или RAG-пайплайн без сборки своей обвязки, здесь у Elastic на 2026 год обычно более зрелый инструментарий, хотя OpenSearch тоже добавил свой k-NN плагин и активно его развивает.

Для конкретной установки на VPS у нас есть пошаговые инструкции по обеим системам — установка Elasticsearch на Ubuntu 24.04 и установка OpenSearch на Ubuntu 24.04 — конфиги и параметры JVM в них рабочие, проверенные на реальном железе.

Стоимость владения

Обе системы бесплатны в базовой поставке. Разница в TCO появляется на уровне того, что вам нужно сверх голого поиска:

Elasticsearch:

• Security (RBAC, TLS между нодами) — с версии 8 включён по умолчанию бесплатно, но продвинутые фичи (SSO, field-level security на все роли, некоторые ML-модули) остаются в платной подписке Gold/Platinum.
• Managed-хостинг у Elastic (Elastic Cloud) стоит заметно дороже голого VPS — вы платите за удобство, а не за движок.
• Self-hosted на своём сервере — бесплатен, платите только за инфраструктуру.

OpenSearch:

• Весь функционал (security plugin, alerting, anomaly detection, ISM) включён в Apache 2.0 сборку без отдельной подписки.
• AWS предлагает managed OpenSearch Service, но и self-hosted вариант ничем не обрезан по сравнению с ним.
• Затрат на лицензии в принципе нет — экономия ощутима именно на масштабе, когда счёт идёт на десятки узлов.

Практический вывод: если вы разворачиваете на своём VPS или выделенном сервере, платите вы в обоих случаях примерно одинаково — за железо и трафик, не за софт. Разница в TCO ощущается заметно только если вы рассматривали managed-облако конкретного вендора или упирались в платные модули Elastic. Требования к оперативной памяти у обеих систем схожи и заданы объёмом индексов, а не выбором форка — этот момент подробно разобран в статье сколько RAM нужно для OpenSearch, выводы применимы и к Elasticsearch с поправкой на конкретную версию.

Практический выбор по сценарию

Сведём в конкретные рекомендации:

Берите OpenSearch, если:

• Юридический отдел требует OSI-совместимую лицензию или вы вообще не хотите разбираться в нюансах ELv2/AGPL.
• Вы уже в экосистеме AWS и используете другие managed-сервисы — интеграция нативная.
• Нужен весь функционал security/alerting/ISM без доплаты, а бюджет ограничен.
• Устраивает community-поддержка и документация, без SLA от вендора.

Берите Elasticsearch, если:

• Нужен zero-configuration security с самой актуальной моделью угроз — Elastic исторически быстрее закрывает CVE в security-модуле.
• Планируете semantic search, RAG или ML-инференс поверх индексов — экосистема здесь на 2026 год обычно более отлажена «из коробки».
• Команда уже умеет с Elasticsearch и Kibana, переучивание дороже потенциальной экономии.
• Готовы платить за Elastic Cloud или enterprise-подписку ради официального SLA и поддержки.

Не имеет значения, если:

• Нагрузка небольшая (один индекс, до нескольких миллионов документов) — обе справятся одинаково хорошо на одном VPS с 4-8 ГБ RAM.
• Вы используете только базовый REST API без специфичных плагинов — миграция между системами в этом случае почти безболезненна.

Настройка на сервере: на что обратить внимание

Независимо от выбора, для продакшена на своём VPS или выделенном сервере важны одни и те же базовые вещи:

# Отключить memory swapping для JVM — критично для обеих систем
sudo swapoff -a

# В /etc/elasticsearch/jvm.options (или opensearch/jvm.options)
# heap не больше 50% RAM и не больше 32 ГБ
-Xms4g
-Xmx4g

# elasticsearch.yml / opensearch.yml — базовые продакшен-настройки
cluster.name: my-cluster
node.name: node-1
network.host: 0.0.0.0
discovery.type: single-node   # для одного узла
bootstrap.memory_lock: true

Systemd-юнит должен снимать лимит на память для процесса:

[Service]
LimitMEMLOCK=infinity

Если разворачиваете в Docker — учитывайте, что контейнерные лимиты CPU/памяти напрямую влияют на то, сколько heap может выделить JVM внутри, это разобрано в статье про лимиты CPU и памяти в Docker. На одном узле для теста или небольшого продакшена достаточно 4 ядер и 8 ГБ RAM с NVMe-диском — на HDD или медленном SSD индексация и особенно merge сегментов заметно проседают по времени отклика.

Частые вопросы