Mikor nem megfelelő az Elasticsearch elsődleges adatbázisnak?

Question

IT Interview Practice · Accepted Answer

Az Elasticsearch képes tartós adattárolásra. Az elsődleges adatbázis szerepéről az alapján dönts, **mely üzleti szabályoknak kell igaznak maradniuk hibás vagy párhuzamos írások esetén is**.

Egy rendelési rendszerben a termékkeresés és a vásárlás jóváhagyása külön feladat. Az elsőnél a találatok relevanciája, a másodiknál a fizetés és készletváltozás helyessége fontos.

## 1. Indulj az együtt sikerülő változásokból

Tegyük fel, a vásárláshoz rendelési rekord és készletcsökkentés kell. Meg kell határozni, mi történjen, ha csak az egyik sikerül.

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

Az Elasticsearch bulk API több dokumentumműveletet küld együtt, de egyik elbukhat, miközben másik sikeres. Ettől még nem lesznek mindent-vagy-semmit tranzakció. Az alkalmazásnak az egyedi eredményeket kell ellenőriznie. [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Több rekord atomi módosításához a tranzakciós adatbázis általában közvetlenebb alap. A koordináció saját megvalósítása további hibalehetőségeket és helyreállítási munkát hoz.

## 2. Különítsd el a dokumentumvédelmet az üzleti garanciáktól

Az optimista konkurenciakezelés ellenőrzi, változott-e a dokumentum az olvasott verzió óta. Elutasíthatja az elavult módosítást, így egyik kliens nem írja észrevétlenül felül a másik munkáját. [Konkurenciakezelés](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Ez a védelem a módosított dokumentumra vonatkozik. Nem koordinálja automatikusan a készletet a rendelési dokumentummal, nem ad relációs idegen kulcsokat, és nem kényszerít ki tetszőleges mezők közötti egyediséget.

Tárolóválasztás előtt írd le az alkalmazás szabályait. Így konkrét igények, nem a „keresőmotor” vagy „adatbázis” elnevezés alapján döntesz.

## 3. Ellenőrizd, mikor válik kereshetővé az írás

A sikeres írás és a keresésben látható eredmény külön esemény:

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

A refresh teszi láthatóvá a friss módosításokat a keresésnek. Az ID szerinti valós idejű lekérés ezért eltér a keresőkérdéstől. A refresh=wait_for megvárhatja a keresési láthatóságot, de nem hoz létre többdokumentumos tranzakciót. [Refresh működése](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

Termékkeresésnél kis késés elfogadható lehet. Végső fizetési vagy jogosultsági döntéshez egyértelműen határozd meg a konzisztenciát, és megfelelő forrást olvass. A refresh és a tartós tárolás is külön kérdés.

## 4. Válaszd ki az Elasticsearch szerepét

| Igény | Vizsgálandó irány | Indok |
| --- | --- | --- |
| Rendelések és kapcsolódó rekordok atomi változása | Tranzakciós elsődleges adatbázis | A helyességi szabályok a hiteles rekordok mellé valók. |
| Rugalmas teljes szöveges keresés | Elasticsearch keresési másolatként | A keresési adat önállóan alakítható és újraépíthető. |
| Független dokumentumok megfelelő konzisztenciaigénnyel | Az Elasticsearch fő tárolóként is jó lehet | A második adatbázisnak igazolt célja legyen. |

Gyakori rendelési architektúra:

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

A CDC a véglegesített változásokat rögzíti; az outbox ugyanabban a tranzakcióban tárol eseményt, mint az üzleti módosítás. Külön folyamat juttatja ezeket az indexhez. Így nem kell két független alkalmazásírás közös sikerére hagyatkozni.

Az indexeléshez továbbra is stabil ID-k, verziókezelés, törlések, újrapróbálás és késésfigyelés kell. Teszteld az index újraépítését a forrásból. Máskülönben a keresési másolat második, inkonzisztens igazságforrás lehet.

## 5. Véglegesítés előtt igazold a helyreállítást

Bármelyik szerepet választod, tervezz mentést és tesztelj visszaállítást. A replikák javítják az elérhetőséget, de nem helyettesítik a mentést. A tényleges konfigurációra határozd meg az elfogadható adatvesztést és helyreállítási időt.

A rendelési példában a tranzakciós rekordokat szabályaikat támogató adatbázisban tartanám, és indokolt keresési igényre adnék Elasticsearchöt. Független, keresésközpontú dokumentumoknál megvizsgálnám, hogy önmagában teljesíti-e a tárolást, konzisztenciát és helyreállítást.

**Emlékezz:** a szükséges garanciák alapján válassz, majd ellenőrizd a hibát és helyreállítást. A keresési sebesség csak egy része a döntésnek.

Igény	Vizsgálandó irány	Indok
Rendelések és kapcsolódó rekordok atomi változása	Tranzakciós elsődleges adatbázis	A helyességi szabályok a hiteles rekordok mellé valók.
Rugalmas teljes szöveges keresés	Elasticsearch keresési másolatként	A keresési adat önállóan alakítható és újraépíthető.
Független dokumentumok megfelelő konzisztenciaigénnyel	Az Elasticsearch fő tárolóként is jó lehet	A második adatbázisnak igazolt célja legyen.

1. Indulj az együtt sikerülő változásokból

2. Különítsd el a dokumentumvédelmet az üzleti garanciáktól

3. Ellenőrizd, mikor válik kereshetővé az írás

4. Válaszd ki az Elasticsearch szerepét

5. Véglegesítés előtt igazold a helyreállítást

Kapcsolódó kérdések