Kdaj Elasticsearch ni primeren kot glavna podatkovna baza?

Question

IT Interview Practice · Accepted Answer

Elasticsearch lahko podatke hrani trajno. Ko presojate, ali naj bo glavna baza, vprašajte, **katera poslovna pravila morajo ostati veljavna ob napakah ali sočasnem pisanju**.

V sistemu naročil sta iskanje izdelkov in potrjevanje nakupa različni nalogi. Pri prvi šteje ustreznost zadetkov, pri drugi pa pravilne spremembe plačila in zaloge.

## 1. Začnite s spremembami, ki morajo uspeti skupaj

Recimo, da nakup zahteva zapis naročila in zmanjšanje zaloge. Podjetje mora določiti, kaj se zgodi, če uspe samo eno.

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

Elasticsearchov bulk API pošlje več operacij nad dokumenti skupaj, vendar lahko ena spodleti, druga pa uspe. Operacij ne spremeni v transakcijo vse-ali-nič. Aplikacija mora pregledati posamezne rezultate. [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Če potrebujete atomsko spremembo več zapisov, transakcijska baza običajno ponuja neposrednejši temelj. Lastna izvedba usklajevanja doda možnosti napak in delo pri obnovi.

## 2. Ločite zaščito dokumenta od poslovnih jamstev

Optimistični nadzor sočasnosti preveri, ali se je dokument spremenil od prebrane različice. Zavrne lahko zastarelo posodobitev in prepreči, da bi en odjemalec neopazno prepisal delo drugega. [Nadzor sočasnosti](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Ta zaščita velja za posodobljeni dokument. Ne uskladi samodejno dokumenta zaloge z naročilom, ne zagotovi relacijskih tujih ključev in ne uveljavlja poljubnih pravil enoličnosti med poslovnimi polji.

Pred izbiro shrambe zapišite pravila aplikacije. Tako odločitev postane konkretna in ni odvisna od oznake »iskalnik« ali »podatkovna baza«.

## 3. Preverite, kdaj zapis postane viden iskanju

Uspešen zapis in viden rezultat iskanja sta ločena dogodka:

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

Refresh naredi nedavne spremembe vidne iskanju. Zato se sprotno pridobivanje po ID-ju dokumenta razlikuje od iskalne poizvedbe. Možnost refresh=wait_for lahko počaka na vidnost v iskanju, ne ustvari pa transakcije nad več dokumenti. [Vedenje refresh](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

Na strani za iskanje izdelkov je kratek zamik lahko sprejemljiv. Za končno odločitev o plačilu ali dovoljenju izrecno določite zahtevano doslednost in berite vir, ki jo zagotavlja. Refresh in trajna hramba sta prav tako različni vprašanji.

## 4. Izberite vlogo Elasticsearcha

| Zahteva | Smer za oceno | Razlog |
| --- | --- | --- |
| Naročila in povezani zapisi se morajo spremeniti atomsko | Transakcijska glavna baza | Pravila pravilnosti sodijo blizu avtoritativnih zapisov. |
| Uporabniki potrebujejo prilagodljivo polnotekstovno iskanje | Elasticsearch kot iskalna kopija | Iskalne podatke lahko neodvisno oblikujete in obnovite. |
| Neodvisni dokumenti z združljivimi potrebami po doslednosti | Elasticsearch je morda primeren kot glavna shramba | Druga baza mora imeti dokazljiv namen. |

Pogosta zasnova sistema naročil je:

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

CDC zajema potrjene spremembe; outbox zabeleži dogodek skupaj s poslovno posodobitvijo v isti transakciji. Ločen proces spremembe dostavi v indeks. Tako ni treba predpostavljati, da bosta dva nepovezana zapisa aplikacije vedno uspela skupaj.

Pot indeksiranja še vedno potrebuje stabilne ID-je, obravnavo različic, brisanj in ponovitev ter spremljanje zamika. Preizkusite obnovo indeksa iz izvora. Sicer lahko iskalna kopija postane drugi, neskladen vir resnice.

## 5. Pred odločitvijo potrdite model obnove

Ne glede na vlogo načrtujte varnostne kopije in testirajte obnovo. Replike pomagajo razpoložljivosti, niso pa nadomestilo za varnostne kopije. Za dejansko konfiguracijo določite sprejemljivo izgubo podatkov in čas obnove.

Pri naročilih bi transakcijske zapise hranil v bazi, ki podpira njihova pravila, Elasticsearch pa dodal, če ga upravičijo potrebe iskanja. Pri neodvisnih dokumentih, namenjenih iskanju, bi ocenil, ali Elasticsearch sam izpolnjuje potrebe hrambe, doslednosti in obnove.

**Zapomnite si:** izberite glede na jamstva, ki jih zahteva delo, nato preverite napake in obnovo. Hitrost iskanja je le del te odločitve.

Zahteva	Smer za oceno	Razlog
Naročila in povezani zapisi se morajo spremeniti atomsko	Transakcijska glavna baza	Pravila pravilnosti sodijo blizu avtoritativnih zapisov.
Uporabniki potrebujejo prilagodljivo polnotekstovno iskanje	Elasticsearch kot iskalna kopija	Iskalne podatke lahko neodvisno oblikujete in obnovite.
Neodvisni dokumenti z združljivimi potrebami po doslednosti	Elasticsearch je morda primeren kot glavna shramba	Druga baza mora imeti dokazljiv namen.

1. Začnite s spremembami, ki morajo uspeti skupaj

2. Ločite zaščito dokumenta od poslovnih jamstev

3. Preverite, kdaj zapis postane viden iskanju

4. Izberite vlogo Elasticsearcha

5. Pred odločitvijo potrdite model obnove

Povezana vprašanja