ES против обычной БД и ClickHouse

У «Гонца» теперь три базы: PostgreSQL для заказов, ClickHouse для аналитики и Elasticsearch для поиска. Новички часто задают вопрос: зачем три, если Elasticsearch тоже хранит документы, тоже ищет и тоже считает агрегации? Нельзя ли держать всё в нём? Разберёмся, где проходят границы.

Что умеет каждая

	PostgreSQL	Elasticsearch	ClickHouse
Главная работа	транзакции приложения	поиск по тексту	сводная аналитика
Поиск по словам с формами, опечатками и ранжированием	слабо	отлично	нет
Транзакции и ограничения	да	нет	нет
Связи между таблицами (JOIN)	да	почти нет	да, с оговорками
Изменение отдельной записи	дёшево	дорого: перезапись документа	дорого: перезапись части
Сводки по миллиардам строк	медленно	хорошо, но дороже по памяти и диску	лучше всех
Видимость записи сразу	да	через refresh, около секунды	да

Почему Elasticsearch не основная база

• Нет транзакций. Записать заказ и списать бонусы одной транзакцией нельзя. _bulk не откатывается при ошибке, мы видели это в уроке про индексацию.
• Почти реальное время. Записанный документ виден поиску не сразу. Для приложения, которое сразу после оплаты показывает статус заказа, это неудобно.
• Нет связей. Связать блюдо и ресторан на лету, как JOIN, Elasticsearch не умеет. Вместо этого данные денормализуют: название ресторана копируют в каждое блюдо.
• Схема на годы. Тип поля и число шардов не меняются без перестройки индекса.
• Безопасность данных. Elasticsearch надёжен с репликами, но не задуман как единственный источник правды. Индекс обычно можно пересобрать из основной базы, и это хорошее свойство: если что-то сломалось, индекс просто строят заново.