Kada Elasticsearch netinka kaip pagrindinė duomenų bazė?

Question

IT Interview Practice · Accepted Answer

Elasticsearch gali patvariai saugoti duomenis. Spręsdami, ar jis turėtų būti pagrindinė bazė, klauskite, **kurios verslo taisyklės turi išlikti teisingos nepavykus rašymui arba rašant vienu metu**.

Užsakymų sistemoje produktų paieška ir pirkimo patvirtinimas yra skirtingi darbai. Pirmajam svarbus paieškos aktualumas, antrajam — teisingi mokėjimų ir atsargų pakeitimai.

## 1. Pradėkite nuo pakeitimų, kurie turi pavykti kartu

Tarkime, pirkimui reikia užsakymo įrašo ir atsargų sumažinimo. Verslas turi apibrėžti, kas nutiks pavykus tik vienam veiksmui.

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

Elasticsearch Bulk API pateikia kelias dokumentų operacijas kartu, bet viena gali nepavykti, o kita pavykti. Tai nėra viską patvirtinanti arba viską atšaukianti transakcija. Programa turi tikrinti atskirus rezultatus. [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Jei būtinas atominis kelių įrašų pakeitimas, transakcinė bazė paprastai suteikia tiesesnį pagrindą. Savarankiškas koordinavimas prideda nesėkmių scenarijų ir atkūrimo darbų.

## 2. Atskirkite dokumento apsaugą nuo verslo garantijų

Optimistinis konkurencijos valdymas patikrina, ar dokumentas nepasikeitė nuo perskaitytos versijos. Jis gali atmesti pasenusį atnaujinimą, kad vienas klientas tyliai neperrašytų kito darbo. [Konkurencijos valdymas](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Ši apsauga taikoma atnaujinamam dokumentui. Ji automatiškai nesuderina atsargų ir užsakymo dokumentų, nesuteikia reliacinių išorinių raktų ir neužtikrina bet kokių unikalumo taisyklių verslo laukuose.

Prieš rinkdamiesi saugyklą užrašykite reikalingas taisykles. Tuomet sprendimas bus konkretus, o ne paremtas pavadinimu „paieškos sistema“ ar „duomenų bazė“.

## 3. Patikrinkite, kada įrašymas tampa matomas paieškoje

Sėkmingas įrašymas ir matomas paieškos rezultatas yra atskiri įvykiai:

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

Refresh padaro naujus pakeitimus matomus paieškai. Todėl gavimas realiuoju laiku pagal dokumento ID skiriasi nuo paieškos užklausos. refresh=wait_for gali laukti matomumo, bet nesukuria kelių dokumentų transakcijos. [Refresh elgsena](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

Produktų paieškoje trumpas vėlavimas gali būti priimtinas. Galutiniam mokėjimo ar leidimo sprendimui aiškiai apibrėžkite nuoseklumą ir skaitykite jį užtikrinantį šaltinį. Refresh ir patvarus saugojimas taip pat yra skirtingi klausimai.

## 4. Pasirinkite Elasticsearch vaidmenį

| Reikalavimas | Vertinama kryptis | Priežastis |
| --- | --- | --- |
| Užsakymai ir susiję įrašai turi keistis atominiu būdu | Transakcinė pagrindinė bazė | Teisingumo taisyklės turi būti arti autoritetingų įrašų. |
| Reikia lanksčios viso teksto paieškos | Elasticsearch kaip paieškos kopija | Paieškos duomenis galima formuoti ir atkurti atskirai. |
| Nepriklausomi dokumentai su tinkamais nuoseklumo poreikiais | Elasticsearch gali būti pagrindinė saugykla | Antrai bazei reikia įrodyto tikslo. |

Dažnas užsakymų sistemos modelis:

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

CDC užfiksuoja patvirtintus pakeitimus; outbox įrašo įvykį toje pačioje transakcijoje kaip verslo pakeitimą. Atskiras procesas perduoda juos indeksui. Taip nereikia tikėtis, kad du nepriklausomi programos įrašymai visada pavyks kartu.

Indeksavimo keliui vis tiek reikia stabilių ID, versijų valdymo, trynimų, kartojimų ir vėlavimo stebėjimo. Išbandykite indekso atkūrimą iš šaltinio. Kitaip paieškos kopija gali tapti antru, nenuosekliu tiesos šaltiniu.

## 5. Prieš apsispręsdami patvirtinkite atkūrimą

Kad ir koks vaidmuo, planuokite atsargines kopijas ir bandykite atkūrimą. Replikos padeda pasiekiamumui, bet nepakeičia atsarginių kopijų. Faktinei konfigūracijai apibrėžkite priimtiną duomenų praradimą ir atkūrimo laiką.

Užsakymų pavyzdyje transakcinius įrašus laikyčiau jų taisykles palaikančioje bazėje, o Elasticsearch pridėčiau esant pagrįstam paieškos poreikiui. Nepriklausomiems paieškos dokumentams įvertinčiau, ar vien Elasticsearch tenkina saugojimo, nuoseklumo ir atkūrimo poreikius.

**Prisiminkite:** rinkitės pagal apkrovai būtinas garantijas, tada tikrinkite nesėkmes ir atkūrimą. Paieškos greitis yra tik viena sprendimo dalis.

Reikalavimas	Vertinama kryptis	Priežastis
Užsakymai ir susiję įrašai turi keistis atominiu būdu	Transakcinė pagrindinė bazė	Teisingumo taisyklės turi būti arti autoritetingų įrašų.
Reikia lanksčios viso teksto paieškos	Elasticsearch kaip paieškos kopija	Paieškos duomenis galima formuoti ir atkurti atskirai.
Nepriklausomi dokumentai su tinkamais nuoseklumo poreikiais	Elasticsearch gali būti pagrindinė saugykla	Antrai bazei reikia įrodyto tikslo.

1. Pradėkite nuo pakeitimų, kurie turi pavykti kartu

2. Atskirkite dokumento apsaugą nuo verslo garantijų

3. Patikrinkite, kada įrašymas tampa matomas paieškoje

4. Pasirinkite Elasticsearch vaidmenį

5. Prieš apsispręsdami patvirtinkite atkūrimą

Susiję klausimai