Когда Elasticsearch плохо подходит на роль основной базы данных?

Question

IT Interview Practice · Accepted Answer

Elasticsearch способен надёжно хранить данные. Чтобы решить, должен ли он быть основной базой, спросите: **какие бизнес-правила обязаны сохраняться при сбоях и одновременной записи**.

В системе заказов поиск товаров и подтверждение покупки — разные задачи. Для первой важна релевантность поиска, для второй — корректность изменений платежа и запасов.

## 1. Начните с изменений, которые должны проходить вместе

Предположим, покупка требует создания заказа и уменьшения остатка. Бизнес должен определить поведение, если удастся только одна операция.

```text
[Create order] ---- must coordinate ---- [Reduce stock]
      |                                      |
   success                                failure?
```

Bulk API Elasticsearch отправляет несколько операций над документами вместе, но один элемент может завершиться ошибкой, а другой успешно. Это не превращает операции в транзакцию «всё или ничего». Приложение должно проверять отдельные результаты. [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Если нужно атомарно изменить несколько записей, транзакционная база обычно даёт более прямую основу. Самостоятельная реализация координации добавляет сценарии сбоев и работу по восстановлению.

## 2. Отличайте защиту документа от бизнес-гарантий

Оптимистическое управление конкурентным доступом проверяет, не изменился ли документ с прочитанной вами версии. Оно может отклонить устаревшее обновление, не позволяя одному клиенту незаметно затереть работу другого. [Управление конкурентным доступом](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Эта защита относится к обновляемому документу. Она автоматически не согласует документ остатков с документом заказа, не предоставляет реляционные внешние ключи и не обеспечивает произвольную уникальность бизнес-полей.

До выбора хранилища запишите правила приложения. Это делает решение конкретным, а не основанным на ярлыке «поисковый движок» или «база данных».

## 3. Проверьте момент появления записи в поиске

Успешная запись и видимость результата в поиске — отдельные события:

```text
[Write accepted] -> [Refresh] -> [Search can see the change]
```

Refresh делает недавние изменения доступными поиску. Поэтому получение документа по ID в реальном времени отличается от поискового запроса. Параметр refresh=wait_for позволяет дождаться видимости в поиске, но не создаёт транзакцию над несколькими документами. [Поведение refresh](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

Для страницы поиска товаров небольшая задержка видимости может быть допустима. Для окончательного решения о платеже или правах явно определите необходимую согласованность и читайте источник, который её обеспечивает. Refresh и надёжное сохранение — также разные вопросы.

## 4. Выберите роль Elasticsearch

| Требование | Направление оценки | Причина |
| --- | --- | --- |
| Заказы и связанные записи должны меняться атомарно | Основная транзакционная база | Правила корректности должны находиться рядом с авторитетными записями. |
| Нужен гибкий полнотекстовый поиск | Elasticsearch как поисковая копия | Поисковые данные можно независимо моделировать и перестраивать. |
| Независимые документы с совместимыми требованиями согласованности | Elasticsearch может подходить как основное хранилище | У второй базы должно быть доказанное назначение. |

Распространённая схема системы заказов:

```text
[Transactional DB] -> [CDC / outbox] -> [Indexer] -> [Elasticsearch]
 authoritative data                               search copy
```

CDC фиксирует подтверждённые изменения; outbox записывает событие вместе с бизнес-обновлением в одной транзакции. Отдельный процесс доставляет изменения в индекс. Так система не рассчитывает на то, что две несвязанные записи приложения всегда выполнятся вместе.

Пути индексирования всё равно нужны стабильные ID, обработка версий и удалений, повторы и наблюдение за отставанием. Проверьте перестроение индекса из источника. Иначе поисковая копия может стать вторым, противоречивым источником истины.

## 5. Подтвердите модель восстановления до окончательного выбора

При любой роли планируйте резервное копирование и проверяйте восстановление. Реплики повышают доступность, но не заменяют резервные копии. Определите допустимую потерю данных и время восстановления для реальной конфигурации.

В примере заказов я бы хранил транзакционные записи в базе, поддерживающей их правила, и добавил Elasticsearch при оправданных требованиях поиска. Для независимых документов, ориентированных на поиск, я бы проверил, достаточно ли одного Elasticsearch для хранения, согласованности и восстановления.

**Запомните:** выбирайте по гарантиям, необходимым нагрузке, затем проверяйте поведение при сбоях и восстановлении. Скорость поиска — лишь часть решения.

Требование	Направление оценки	Причина
Заказы и связанные записи должны меняться атомарно	Основная транзакционная база	Правила корректности должны находиться рядом с авторитетными записями.
Нужен гибкий полнотекстовый поиск	Elasticsearch как поисковая копия	Поисковые данные можно независимо моделировать и перестраивать.
Независимые документы с совместимыми требованиями согласованности	Elasticsearch может подходить как основное хранилище	У второй базы должно быть доказанное назначение.

1. Начните с изменений, которые должны проходить вместе

2. Отличайте защиту документа от бизнес-гарантий

3. Проверьте момент появления записи в поиске

4. Выберите роль Elasticsearch

5. Подтвердите модель восстановления до окончательного выбора

Похожие вопросы