ES против обычной БД и ClickHouse
Ставим Elasticsearch рядом с реляционной БД и с ClickHouse, чтобы понимать, для каких задач он, а для каких — нет.
Elasticsearch — не замена базе данных: это поисково-аналитический движок; для строгих транзакций берут реляционную БД, для тяжёлой колоночной аналитики — ClickHouse.
ES против реляционной БД
| Критерий | Реляционная БД | Elasticsearch |
| Модель | таблицы, строки, схема, связи | денормализованные JSON-документы |
| Транзакции | полноценные ACID | нет многодокументных транзакций |
| Сильная сторона | целостность, связи, точные выборки | полнотекстовый поиск, релевантность, агрегации |
| JOIN | основа модели | почти нет; данные денормализуют |
| Свежесть данных | видно сразу (read-after-write) | задержка refresh (~1 с) |
Вывод: источник истины — реляционная БД (заказы, платежи, пользователи с гарантиями). Elasticsearch — производный слой для поиска и аналитики, который наполняют из основной БД. Их часто используют вместе.
ES против ClickHouse
ClickHouse — колоночная СУБД для аналитики (OLAP) на огромных объёмах. Здесь сравнение тоньше, потому что у ES тоже сильная аналитика (агрегации).
| Критерий | ClickHouse | Elasticsearch |
| Сильная сторона | сканирующая аналитика по миллиардам строк, SQL | полнотекстовый поиск + релевантность + агрегации |
| Хранение | колоночное, сильное сжатие | инвертированный индекс + doc values |
| Запросы | SQL, тяжёлые GROUP BY, JOIN | Query DSL, поиск по тексту |
| Где блистает | дашборды по терабайтам, агрегаты по «холодным» данным | поиск, логи с текстом, гибкий ранжированный поиск |
Грубо: нужен поиск по тексту с релевантностью — Elasticsearch. Нужна тяжёлая числовая аналитика по огромным таблицам без полнотекстового поиска — ClickHouse часто быстрее и дешевле по железу.
Как работает под капотом
Разница в том, что оптимизировано. Реляционная БД хранит строки и держит индексы-деревья по значениям для точных выборок и связей. ES хранит инвертированный индекс (слово → документы) и потому блестяще ищет текст, но не делает дешёвые JOIN. ClickHouse хранит данные по колонкам: чтобы посчитать сумму по столбцу, он читает только этот столбец (сильно сжатый) и сканирует его на огромной скорости, но искать произвольное слово в тексте, как ES, не умеет. Каждая структура хранения — это выбор, под какой класс запросов оптимизироваться.
Частые ошибки
- Делать ES единственным хранилищем для важных данных. Без ACID и многодокументных транзакций он плохой источник истины для денег и заказов.
- Эмулировать JOIN в ES. Связи в ES дороги (parent-child, nested); правильнее денормализовать данные при индексации.
- Брать ES ради чисто числовой аналитики. Если полнотекстовый поиск не нужен, колоночная СУБД (ClickHouse) часто эффективнее.
Итоги
- ES — не замена реляционной БД: нет ACID и дешёвых JOIN; он производный слой поиска и аналитики.
- Источник истины держат в реляционной БД, а ES наполняют из неё.
- Для полнотекстового поиска — ES; для тяжёлой числовой OLAP-аналитики без текста — часто ClickHouse.