Elasticsearch, OpenSearch та альтернативи

Уявіть, що у вас є мільйон документів. Ви хочете знайти всі, де є слово «кава», але тільки ті, де воно вживається у контексті «приготування», а не «магазину». Ще й відсортувати за релевантністю. І все це - за 50 міліс...

5 лип. '26, 10:36·7 хв. читання

ЗмістНатисність на посилання, щоб перейти до потрібного місця

Elasticsearch: стандарт де-факто Як це працює всередині Що Elasticsearch вміє добре Темна сторона: ліцензійна драма OpenSearch: форк від Amazon Чим відрізняється OpenSearch від Elasticsearch?Коли обирати OpenSearch?Альтернативи: коли Elasticsearch - це забагато Typesense Meilisearch Solr PostgreSQL Full-Text Search SQLite FTS5 Qdrant, Weaviate, Pinecone - векторні бази даних Порівняльна таблиця Реальні кейси з практики

Реляційна база даних тут зламається. Вона вміє WHERE body LIKE '%кава%' - але це повний перебір рядків, без розуміння мови, без ранжування, без стійкості до помилок у написанні. На мільйоні записів це займе секунди. На мільярді - хвилини.

Для цього й існують пошукові рушії - спеціалізовані системи, побудовані навколо однієї ідеї: зробити пошук по великих обсягах тексту швидким, гнучким і розумним.

Elasticsearch: стандарт де-факто

Elasticsearch - це розподілений пошуковий рушій і аналітична платформа, побудована на Apache Lucene. Lucene - це Java-бібліотека, яка існує з 1999 року і реалізує класичні алгоритми інформаційного пошуку. Elasticsearch з'явився в 2010 році як зручна HTTP-обгортка над Lucene з підтримкою кластеризації.

Як це працює всередині

В основі лежить концепція інвертованого індексу. Замість того щоб для кожного документа зберігати його текст і шукати по ньому, система будує словник: «яке слово - в яких документах зустрічається». Це схоже на предметний покажчик у книзі.

"кава"         → [doc_3, doc_7, doc_42, doc_100]
"приготування" → [doc_7, doc_15, doc_42]

При запиті «приготування кави» система знаходить перетин множин за мілісекунди - незалежно від розміру колекції.

Поверх цього Elasticsearch додає:

Аналізатори - пайплайни обробки тексту: токенізація, видалення стоп-слів, стемінг (зведення до кореня), транслітерація.
Scoring - алгоритм BM25 (і раніше TF-IDF) присвоює кожному результату числовий рейтинг релевантності.
Шарди та репліки - індекс розбивається на частини (шарди), які розподіляються по вузлах кластера. Репліки забезпечують відмовостійкість.
REST API - вся взаємодія відбувається через JSON по HTTP. Жодних специфічних клієнтських протоколів.

Що Elasticsearch вміє добре

Повнотекстовий пошук - це очевидно. Але крім нього:

Агрегації - аналітика в реальному часі. «Скільки замовлень по кожному місту за останні 7 днів, розбитих по годинах?» - один запит, миттєва відповідь.

Geo-пошук - «знайди всі кафе у радіусі 2 км від координат». Elasticsearch підтримує геопросторові індекси нативно.

Векторний пошук (kNN) - з версії 8.x підтримка dense vectors дозволяє реалізувати семантичний пошук на основі ембедингів. Тобто знаходити документи за змістом, а не за точним збігом слів.

Observability стек (ELK) - Elasticsearch + Logstash + Kibana. Класичне поєднання для збору та аналізу логів. Тисячі компаній запускають його для моніторингу інфраструктури.

Темна сторона: ліцензійна драма

У 2021 році Elastic NV змінила ліцензію Elasticsearch і Kibana з Apache 2.0 на SSPL (Server Side Public License) та Elastic License 2.0. Обидві ліцензії забороняють надавати Elasticsearch як хмарний сервіс без комерційної угоди з Elastic.

Причина: Amazon Web Services запустив Amazon Elasticsearch Service (пізніше перейменований на OpenSearch) і фактично заробляв на чужому open-source коді, не роблячи внеску назад. Elastic вирішила закрити цю лазівку.

Спільнота open-source сприйняла це неоднозначно. SSPL відкидається більшістю визначень open-source, включаючи OSI. Для багатьох це означало: Elasticsearch більше не є по-справжньому відкритим.

OpenSearch: форк від Amazon

У відповідь на зміну ліцензії AWS у 2021 році форкнула Elasticsearch 7.10 (останню версію під Apache 2.0) і створила OpenSearch. Одночасно було форковано Kibana → OpenSearch Dashboards.

OpenSearch залишається під Apache License 2.0. Amazon, як і раніше, пропонує його як керований сервіс - Amazon OpenSearch Service.

Чим відрізняється OpenSearch від Elasticsearch?

На момент форку - практично нічим. API були сумісні на 95%. З часом вони розійшлися:

Аспект	Elasticsearch	OpenSearch
Ліцензія	Elastic License 2.0 / SSPL	Apache 2.0
Векторний пошук	kNN з версії 8.x	k-NN плагін (з ранніх версій)
ML функції	Elastic ML (комерційні)	ML Commons (відкрито)
Security	X-Pack (безкоштовно з 7.x)	Security плагін (завжди безкоштовно)
Управління	Elastic NV (США)	OpenSearch Foundation (Linux Foundation)

Важливо: у 2024 році Elastic оголосила, що повертає Elasticsearch під ліцензію AGPL-3.0 - справжній open-source. Це частково відповідь на зростання OpenSearch. Але AGPL має свої обмеження для комерційного використання.

Коли обирати OpenSearch?

Якщо ви вже на AWS і використовуєте керований сервіс
Якщо важлива ліцензійна чистота (Apache 2.0)
Якщо потрібні вбудовані security функції безкоштовно
Якщо ваша команда не хоче залежати від комерційної компанії

Альтернативи: коли Elasticsearch - це забагато

Elasticsearch потужний, але він також важкий. Мінімальний кластер - це щонайменше 3 вузли, кілька гігабайт RAM, складне налаштування. Для малих і середніх проєктів це часто overkill.

Typesense

Typesense - сучасний пошуковий рушій, написаний на C++, орієнтований на простоту і швидкість.

Ключові особливості:

Миттєве налаштування: один бінарний файл, конфіг з 5 рядків
Typo tolerance з коробки - «кафе» знайде «кафе», «café», «кафэ»
Векторний пошук і гібридний пошук (текст + вектори)
Вбудована підтримка фасетного пошуку
Ліцензія: GPL-3.0 (self-hosted), є хмарний SaaS

Typesense чудово підходить для пошуку по продуктах, статтях, документації.

Обмеження: не підходить для аналітики логів, немає агрегацій рівня Elasticsearch, менша екосистема.

Meilisearch

Meilisearch - open-source (MIT) пошуковий рушій на Rust, з акцентом на developer experience.

# Запуск за 10 секунд
docker run -p 7700:7700 getmeili/meilisearch
curl -X POST 'http://localhost:7700/indexes/movies/documents' \
  -d '[{"id": 1, "title": "Зоряні війни"}]'

Особливості:

Надзвичайно простий REST API
Пошук-під-час-друку (instant search) з коробки
Фільтри, фасети, сортування
Многомовна підтримка
Векторний пошук (з версії 1.3)

Обмеження: менш масштабований ніж Elasticsearch, не підходить для петабайтних даних, обмежені аналітичні можливості.

Solr

Apache Solr - «старший брат» Elasticsearch. Теж побудований на Lucene, з'явився у 2004 році. Довгий час був стандартом індустрії.

Сьогодні Solr поступається Elasticsearch у зручності API, документації та cloud-native функціях. Але є ніші де Solr виграє: класичний enterprise-пошук, дуже складні faceting сценарії, інтеграція з Hadoop.

PostgreSQL Full-Text Search

Так, ваша улюблена реляційна база даних вміє повнотекстовий пошук. І він непоганий.

SELECT title, ts_rank(search_vector, query) AS rank
FROM articles, to_tsquery('ukrainian', 'пошук & рушій') query
WHERE search_vector @@ query
ORDER BY rank DESC;

PostgreSQL підтримує словники для різних мов (включаючи ukrainian через uk_hunspell), GIN/GiST індекси для швидкого пошуку, та ранжування за релевантністю.

Коли це достатньо: до кількох мільйонів документів, якщо не потрібна typo tolerance і складні агрегації, якщо хочете мінімізувати інфраструктуру.

Коли недостатньо: великі обсяги, потрібна fuzzy search, синоніми, складне ранжування, аналітика в реальному часі.

SQLite FTS5

Для зовсім невеликих проєктів або мобільних застосунків - FTS5 модуль SQLite. Повнотекстовий пошук без жодної зовнішньої залежності.

Qdrant, Weaviate, Pinecone - векторні бази даних

Це окремий клас систем, що набирає популярності з розвитком LLM. Замість пошуку за ключовими словами - пошук за семантичною близькістю через вектори (ембединги).

Qdrant (Rust, MIT) - fast, production-ready, self-hosted або хмарний.
Weaviate (Go, BSD-3) - гібридний пошук + вбудована інтеграція з OpenAI/Cohere.
Pinecone - хмарний SaaS, найпростіший у налаштуванні.

Ці системи не замінюють Elasticsearch - вони доповнюють. Гібридний підхід (BM25 + векторний пошук) часто дає найкращі результати.

Порівняльна таблиця

	Elasticsearch	OpenSearch	Typesense	Meilisearch	PG FTS
Ліцензія	Elastic/AGPL	Apache 2.0	GPL-3	MIT	PostgreSQL
Мова	Java	Java	C++	Rust	C
Typo tolerance	Так (fuzzy)	Так	Відмінна	Відмінна	Ні
Агрегації	Розширені	Розширені	Базові	Базові	Обмежені
Складність	Висока	Висока	Низька	Низька	-
RAM (мін.)	1–2 GB	1–2 GB	256 MB	256 MB	-
Векторний пошук	Так (8.x+)	Так	Так	Так	pgvector
Ідеально для	Enterprise, logs	AWS, відкритість	Продукти, docs	Стартапи	Малі проєкти

Як обирати?

Обирайте Elasticsearch якщо:

Потрібна аналітика логів (ELK стек)
Масштаб - десятки мільйонів документів і більше
Потрібні складні агрегації і Kibana dashboards
Команда готова інвестувати час у налаштування

Обирайте OpenSearch якщо:

Ви на AWS або важлива ліцензія Apache 2.0
Потрібна та ж функціональність що й Elasticsearch

Обирайте Typesense або Meilisearch якщо:

Стартап або середній проєкт
Пріоритет - швидкий старт і developer experience
Потрібна typo tolerance без тонкого налаштування

Залишайтесь на PostgreSQL FTS якщо:

Менше мільйона документів
Не хочете додаткової інфраструктури
Базова якість пошуку достатня

Реальні кейси з практики

GitHub використовує Elasticsearch для пошуку по коду і репозиторіях - мільярди документів, субсекундна відповідь.

Wikipedia - Elasticsearch для пошуку по статтях. Близько 60 мільйонів сторінок, 300+ мов.

Netflix - ELK стек для аналізу логів. Петабайти даних.

Shopify - Elasticsearch для пошуку по продуктах у мільйонах магазинів.

Водночас тисячі менших продуктів чудово живуть на Meilisearch або Typesense - і не потребують складності Elasticsearch.

Elasticsearch - це Photoshop серед пошукових рушіїв: надзвичайно потужний, але з крутою кривою навчання і серйозними системними вимогами. OpenSearch - його ліцензійно чистий близнюк.

Але 2024–2026 роки показують: конкуренція жива. Typesense і Meilisearch відкусують аудиторію у середньому сегменті. Векторні бази даних відкривають новий вимір семантичного пошуку. PostgreSQL з pgvector тихо підбирається знизу.

Правильний вибір - не «найпотужніше рішення», а «найпростіше рішення, яке вирішує вашу задачу». Іноді це Elasticsearch. Іноді - LIKE '%пошук%' у PostgreSQL.

Головне - розуміти, що ви будуєте, і не стріляти з гармати по горобцях.

Інтернет Програмування Комп'ютери та технології