Kdy Elasticsearch není vhodný jako hlavní databáze?

Question

IT Interview Practice · Accepted Answer

Elasticsearch dokáže data trvale ukládat. O jeho použití jako hlavní databáze rozhodujte podle toho, **která obchodní pravidla musí platit při selhání nebo souběhu zápisů**.

V objednávkovém systému jsou hledání produktů a potvrzení nákupu rozdílné úkoly. U prvního záleží na relevanci hledání, u druhého na správných změnách plateb a zásob.

## 1. Začněte změnami, které musí uspět společně

Předpokládejme, že nákup vyžaduje záznam objednávky a snížení zásoby. Firma musí určit, co má nastat, pokud uspěje jen jedna část.

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

Bulk API Elasticsearch odešle více operací nad dokumenty společně, ale jedna položka může selhat a jiná uspět. Nevytváří transakci „vše, nebo nic“. Aplikace musí vyhodnotit jednotlivé výsledky. [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Pokud potřebujete atomickou změnu napříč záznamy, transakční databáze obvykle poskytuje přímější základ. Vlastní koordinace přidává chybové stavy a obnovovací práci.

## 2. Odlište ochranu dokumentu od obchodních záruk

Optimistické řízení souběhu ověřuje, zda se dokument nezměnil od vámi přečtené verze. Může odmítnout zastaralou aktualizaci a zabránit tichému přepsání práce jiného klienta. [Řízení souběhu](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Tato ochrana platí pro aktualizovaný dokument. Automaticky nekoordinuje dokument zásoby s objednávkou, neposkytuje relační cizí klíče ani nevynucuje libovolnou jedinečnost obchodních polí.

Před výběrem úložiště sepište pravidla aplikace. Rozhodnutí pak bude konkrétní a nebude stát jen na označení „vyhledávač“ nebo „databáze“.

## 3. Ověřte, kdy se zápis objeví ve vyhledávání

Úspěšný zápis a viditelný výsledek hledání jsou dvě události:

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

Refresh zpřístupní nedávné změny vyhledávání. Získání dokumentu podle ID v reálném čase se proto liší od vyhledávacího dotazu. Volba refresh=wait_for může počkat na viditelnost, ale nevytvoří transakci přes více dokumentů. [Chování refresh](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

Na stránce hledání produktů může být krátké zpoždění přijatelné. U konečné platby nebo oprávnění určete potřebnou konzistenci výslovně a čtěte zdroj, který ji poskytuje. Refresh a trvalé uložení jsou také různé otázky.

## 4. Vyberte roli Elasticsearch

| Požadavek | Směr k posouzení | Důvod |
| --- | --- | --- |
| Objednávky a související záznamy se musí měnit atomicky | Transakční hlavní databáze | Pravidla správnosti patří k autoritativním záznamům. |
| Uživatelé potřebují pružné fulltextové hledání | Elasticsearch jako vyhledávací kopie | Vyhledávací data lze nezávisle tvarovat a obnovovat. |
| Nezávislé dokumenty s odpovídající konzistencí | Elasticsearch může být hlavní úložiště | Druhá databáze má mít prokázaný účel. |

Častý návrh objednávkového systému:

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

CDC zachycuje potvrzené změny; outbox ukládá událost spolu s obchodní změnou v jedné transakci. Samostatný proces je doručuje do indexu. Nemusíte tak spoléhat na to, že dva nezávislé zápisy aplikace vždy uspějí společně.

Indexování stále potřebuje stabilní ID, práci s verzemi, mazání, opakování a sledování zpoždění. Vyzkoušejte obnovu indexu ze zdroje. Jinak se vyhledávací kopie může stát druhým, nekonzistentním zdrojem pravdy.

## 5. Před rozhodnutím potvrďte model obnovy

Ať vyberete jakoukoli roli, plánujte zálohy a testujte obnovu. Repliky podporují dostupnost, ale zálohy nenahrazují. Pro skutečnou konfiguraci určete přijatelnou ztrátu dat a dobu obnovy.

V příkladu objednávek bych transakční záznamy ponechal v databázi podporující jejich pravidla a Elasticsearch přidal, pokud to vyžaduje hledání. U nezávislých dokumentů zaměřených na hledání bych posoudil, zda samotný Elasticsearch splní ukládání, konzistenci a obnovu.

**Zapamatujte si:** vybírejte podle požadovaných záruk a ověřujte selhání i obnovu. Rychlost hledání je jen část rozhodnutí.

Požadavek	Směr k posouzení	Důvod
Objednávky a související záznamy se musí měnit atomicky	Transakční hlavní databáze	Pravidla správnosti patří k autoritativním záznamům.
Uživatelé potřebují pružné fulltextové hledání	Elasticsearch jako vyhledávací kopie	Vyhledávací data lze nezávisle tvarovat a obnovovat.
Nezávislé dokumenty s odpovídající konzistencí	Elasticsearch může být hlavní úložiště	Druhá databáze má mít prokázaný účel.

1. Začněte změnami, které musí uspět společně

2. Odlište ochranu dokumentu od obchodních záruk

3. Ověřte, kdy se zápis objeví ve vyhledávání

4. Vyberte roli Elasticsearch

5. Před rozhodnutím potvrďte model obnovy

Související otázky