Прямой ответ
Оба движка построены на Apache Lucene и предоставляют полнотекстовый поиск с похожим набором возможностей. Различие — в происхождении, лицензии и экосистеме вокруг ядра.
OpenSearch — форк Elasticsearch версии 7.10.2, созданный в 2021 году после перехода Elasticsearch на лицензии SSPL и Elastic License. OpenSearch распространяется под Apache License 2.0. Позднее Elastic вернула часть дистрибутивов под AGPLv3, поэтому лицензионная картина перестала быть однозначным различием.
| Критерий | OpenSearch | Elasticsearch |
|---|---|---|
| Ядро | Apache Lucene | Apache Lucene |
| Происхождение | Форк ES 7.10.2 | Исходный проект |
| Лицензия | Apache 2.0 | SSPL / Elastic License / AGPLv3 |
| Безопасность и RBAC | Включены в базовый дистрибутив | Включены в базовый дистрибутив |
| Язык запросов | Query DSL (совместим с ES 7.x) | Query DSL |
| Экосистема визуализации | OpenSearch Dashboards | Kibana |
| Совместимость API | Уровень ES 7.10 | Собственная линейка 8.x |
Практическое следствие совместимости: клиент, написанный под Elasticsearch 7.x, часто работает с OpenSearch без изменений, а клиент под 8.x — нет, поскольку в восьмой версии изменены поведение и формат ряда запросов.
Выбор определяется тремя вопросами.
Нужны ли возможности, появившиеся после 7.10. Ветки 8.x содержат улучшения, которых нет в OpenSearch, и наоборот: OpenSearch развивает собственные функции, отсутствующие в Elasticsearch. Список расхождений растёт с каждым релизом.
Какая лицензия приемлема для продукта. Apache 2.0 не накладывает ограничений на использование в управляемом сервисе. SSPL требует открытия исходного кода сервиса, построенного вокруг продукта. AGPLv3 требует распространения исходного кода модификаций.
Что уже используется в инфраструктуре. Существующий кластер Kibana и набор дашбордов склоняют выбор в сторону Elasticsearch; требование единой лицензии для всего стека — в сторону OpenSearch.
Базовый полнотекстовый поиск работает одинаково: о настройке индекса — в статье про полнотекстовый поиск в Elasticsearch. Если объём данных и нагрузка умеренные, отдельный движок может оказаться избыточным, и достаточно полнотекстового поиска в PostgreSQL.
Что общего у двух движков
Различия обсуждают чаще, чем совпадения, но общая часть определяет большую часть практической работы.
Инвертированный индекс Lucene. Оба движка хранят соответствие термин → список документов, поэтому скорость поиска по термину не зависит от объёма данных линейно. Сегменты индекса неизменяемы, а удаление помечает документ, поэтому периодическое слияние сегментов обязательно.
Модель кластера и шардирования. Индекс делится на первичные и репликовые шарды, распределяемые по узлам. Число шардов фиксируется при создании индекса, а изменение требует переиндексации.
Query DSL. Структура запросов с bool, must, should, filter совпадает, поэтому перенос запросов между движками сводится к точечным правкам.
Анализ текста. Конвейер анализатора — токенизатор, фильтры нижнего регистра, стемминга и синонимов — настраивается одинаково. О стемминге — в статье про лемматизацию и стемминг.
Различия начинаются там, где движки развивались независимо после 2021 года: состав плагинов, параметры безопасности по умолчанию, формат ответов отдельных API и вспомогательные сервисы.
Практика: выбор и внедрение поискового движка
1. Начинайте с оценки объёма и нагрузки. До нескольких миллионов документов и десятков запросов в секунду отдельный кластер часто избыточен, и встроенный поиск базы данных покрывает задачу.
2. Проверяйте лицензию под ваш способ использования. Встраивание поиска в коммерческий управляемый сервис и внутреннее использование оцениваются по-разному.
3. Фиксируйте версию клиента и движка. Совместимость клиента с версией кластера проверяется явно, поскольку расхождения в формате ответов приводят к ошибкам разбора.
4. Планируйте переиндексацию заранее. Изменение числа шардов и анализатора требует создания нового индекса и переноса данных; о порядке переноса — в статье про индексацию и синхронизацию.
5. Не храните единственный экземпляр данных в поисковом индексе. Индекс восстанавливается из источника, поэтому источник остаётся системой записи.
6. Измеряйте задержку поиска на реальных запросах. Тестовые запросы из документации не отражают распределение реальных, а задержка определяется частотой терминов.
7. Ограничивайте объём возвращаемых полей. Возврат всего документа при поиске увеличивает сетевой трафик и время разбора.
Рекомендации:
- Различайте поисковый индекс и систему записи. Индекс — производная структура, восстанавливаемая из источника, и потеря индекса не означает потерю данных.
- Не переносите запросы между движками без проверки. Совместимость на уровне 7.10 не распространяется на возможности более поздних версий.
- Проверяйте поведение при отказе узла. Распределение реплик и восстановление шардов отличаются настройками по умолчанию.
- Учитывайте стоимость кластера в эксплуатации. Оба движка требуют выделения памяти под heap и настройки сборщика мусора, что влияет на размер узла.
- Фиксируйте маппинг полей явно. Динамическое определение типа при первом документе приводит к неожиданному маппингу и переиндексации.
Практический сценарий: перенос поиска между движками
Контекст: сервис использовал Elasticsearch 7.10. Требовалось перейти на дистрибутив под лицензией Apache 2.0.
- Диагностика. Существующий клиент работал по Query DSL версии 7.x, а маппинг индексов использовал пользовательский анализатор со стеммингом и синонимами.
- Причина риска. Совместимость API гарантировалась только для возможностей версии 7.10, а часть запросов использовала агрегации, поведение которых в новой ветке отличалось.
- Действия. (а) Развернули целевой кластер рядом с существующим; (б) перенесли маппинг и настройки анализатора без изменений; (в) выполнили полную переиндексацию из источника, а не копированием индекса; (г) прогнали набор реальных поисковых запросов и сравнили результаты по первым двадцати позициям; (д) нашли два запроса с агрегациями, где формат ответа отличался, и исправили разбор; (е) переключили чтение после совпадения результатов.
- Результат. Перенос выполнен без изменения бизнес-логики поиска; расхождения обнаружились только в двух запросах с агрегациями.
Вывод: перенос между движками сводится к переиндексации из источника и проверке реальных запросов. Копирование индекса не переносит настройки корректно, а сравнение результатов на реальных запросах выявляет расхождения формата, которые не видны при проверке отдельных документов.
FAQ
Можно ли использовать клиент Elasticsearch с OpenSearch? Для возможностей уровня 7.10 — обычно да. Возможности более поздних версий несовместимы, поэтому клиент должен соответствовать версии кластера.
Какой движок быстрее? Производительность определяется настройкой кластера, размером heap, числом шардов и характером запросов, а не названием движка. Сравнение без одинаковой конфигурации нерепрезентативно.
Нужен ли отдельный кластер для поиска? Нет, если объём данных и нагрузка умеренные. Полнотекстовый поиск в базе данных покрывает задачу без дополнительной инфраструктуры.
Что делать с существующими дашбордами Kibana? Проверить совместимость с целевым движком. OpenSearch Dashboards построен на том же исходном коде, но расхождения накапливаются с версиями.
Источники: OpenSearch docs, Elasticsearch Reference, Apache Lucene documentation, Elastic licensing — ссылки в шапке.