Kiedy Elasticsearch źle sprawdza się jako główna baza danych?

Question

IT Interview Practice · Accepted Answer

Elasticsearch potrafi trwale przechowywać dane. Przy wyborze głównej bazy zapytaj, **jakie reguły biznesowe muszą obowiązywać, gdy zapisy zawodzą lub zachodzą równocześnie**.

W systemie zamówień wyszukiwanie produktów i potwierdzanie zakupu to różne zadania. Pierwsze wymaga trafnych wyników, drugie poprawnych zmian płatności i stanu magazynu.

## 1. Zacznij od zmian, które muszą udać się razem

Załóżmy, że zakup wymaga rekordu zamówienia i zmniejszenia zapasu. Firma musi określić, co zrobić, gdy powiedzie się tylko jedna operacja.

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

Bulk API Elasticsearch wysyła wiele operacji dokumentowych razem, ale jedna może się nie udać, gdy druga się powiedzie. Nie tworzy transakcji „wszystko albo nic”. Aplikacja musi sprawdzić poszczególne wyniki. [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Jeśli potrzebna jest atomowa zmiana wielu rekordów, baza transakcyjna zwykle daje prostszą podstawę. Samodzielna koordynacja dodaje scenariusze błędów i pracę przy odzyskiwaniu.

## 2. Oddziel ochronę dokumentu od gwarancji biznesowych

Optymistyczna kontrola współbieżności sprawdza, czy dokument nie zmienił się od odczytanej wersji. Może odrzucić nieaktualną aktualizację, zapobiegając cichemu nadpisaniu pracy innego klienta. [Kontrola współbieżności](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Ochrona dotyczy aktualizowanego dokumentu. Nie koordynuje automatycznie dokumentu zapasu z zamówieniem, nie zapewnia relacyjnych kluczy obcych ani dowolnych reguł unikalności pól biznesowych.

Przed wyborem magazynu zapisz wymagane reguły aplikacji. To konkretyzuje decyzję zamiast opierać ją na etykiecie „wyszukiwarka” lub „baza danych”.

## 3. Sprawdź moment widoczności zapisu w wyszukiwaniu

Udany zapis i widoczny wynik wyszukiwania to osobne zdarzenia:

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

Refresh udostępnia ostatnie zmiany wyszukiwaniu. Odczyt dokumentu po ID w czasie rzeczywistym różni się więc od zapytania wyszukującego. Opcja refresh=wait_for może poczekać na widoczność, ale nie tworzy transakcji wielodokumentowej. [Działanie refresh](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

Na stronie wyszukiwania produktów krótka zwłoka może być akceptowalna. Przy ostatecznej decyzji o płatności lub uprawnieniu jawnie określ spójność i odczytaj źródło, które ją zapewnia. Refresh i trwałość zapisu to również różne kwestie.

## 4. Wybierz rolę Elasticsearch

| Wymaganie | Kierunek oceny | Powód |
| --- | --- | --- |
| Zamówienia i powiązane rekordy muszą zmieniać się atomowo | Transakcyjna baza główna | Reguły poprawności powinny znajdować się blisko autorytatywnych rekordów. |
| Elastyczne wyszukiwanie pełnotekstowe | Elasticsearch jako kopia wyszukiwawcza | Dane wyszukiwania można niezależnie modelować i odbudowywać. |
| Niezależne dokumenty ze zgodnymi wymaganiami spójności | Elasticsearch może wystarczyć jako główny magazyn | Druga baza powinna mieć wykazane uzasadnienie. |

Typowy projekt systemu zamówień:

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

CDC przechwytuje zatwierdzone zmiany; outbox zapisuje zdarzenie razem ze zmianą biznesową w tej samej transakcji. Osobny proces dostarcza je do indeksu. Dzięki temu nie zakładamy, że dwa niezależne zapisy aplikacji zawsze powiodą się razem.

Indeksowanie nadal wymaga stabilnych ID, obsługi wersji, usunięć, ponowień i monitorowania opóźnienia. Przetestuj odbudowę indeksu ze źródła. Inaczej kopia wyszukiwawcza może stać się drugim, niespójnym źródłem prawdy.

## 5. Potwierdź model odtwarzania przed decyzją

Niezależnie od roli zaplanuj kopie zapasowe i testuj odtwarzanie. Repliki poprawiają dostępność, ale nie zastępują backupów. Określ akceptowalną utratę danych i czas przywrócenia dla rzeczywistej konfiguracji.

Dla zamówień trzymałbym rekordy transakcyjne w bazie wspierającej ich reguły i dodał Elasticsearch, jeśli uzasadniają to potrzeby wyszukiwania. Dla niezależnych dokumentów zorientowanych na wyszukiwanie sprawdziłbym, czy sam Elasticsearch spełnia wymagania przechowywania, spójności i odzyskiwania.

**Zapamiętaj:** wybieraj według wymaganych gwarancji, potem sprawdzaj zachowanie przy awarii i odtwarzaniu. Szybkość wyszukiwania jest tylko częścią decyzji.

Wymaganie	Kierunek oceny	Powód
Zamówienia i powiązane rekordy muszą zmieniać się atomowo	Transakcyjna baza główna	Reguły poprawności powinny znajdować się blisko autorytatywnych rekordów.
Elastyczne wyszukiwanie pełnotekstowe	Elasticsearch jako kopia wyszukiwawcza	Dane wyszukiwania można niezależnie modelować i odbudowywać.
Niezależne dokumenty ze zgodnymi wymaganiami spójności	Elasticsearch może wystarczyć jako główny magazyn	Druga baza powinna mieć wykazane uzasadnienie.

1. Zacznij od zmian, które muszą udać się razem

2. Oddziel ochronę dokumentu od gwarancji biznesowych

3. Sprawdź moment widoczności zapisu w wyszukiwaniu

4. Wybierz rolę Elasticsearch

5. Potwierdź model odtwarzania przed decyzją

Powiązane pytania