Kada Elasticsearch nije prikladan kao primarna baza podataka?

Question

IT Interview Practice · Accepted Answer

Elasticsearch može trajno pohranjivati podatke. Da biste odlučili treba li biti glavna baza, pitajte **koja poslovna pravila moraju ostati istinita kada upisi ne uspiju ili se izvršavaju istodobno**.

U sustavu narudžbi traženje proizvoda i potvrda kupnje različiti su poslovi. Za prvo je važna relevantnost pretrage, a za drugo ispravna promjena plaćanja i zaliha.

## 1. Počnite od promjena koje moraju uspjeti zajedno

Pretpostavimo da kupnja zahtijeva zapis narudžbe i smanjenje zalihe. Poslovanje mora odrediti što se događa ako uspije samo jedno.

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

Elasticsearchov bulk API šalje više operacija nad dokumentima zajedno, ali jedna može ne uspjeti dok druga uspije. To nije transakcija u kojoj uspijeva sve ili ništa. Aplikacija mora pregledati pojedinačne rezultate. [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Ako je potrebna atomska promjena više zapisa, transakcijska baza obično pruža jednostavniji temelj. Samostalna izvedba koordinacije dodaje slučajeve kvara i posao oporavka.

## 2. Razlikujte zaštitu dokumenta od poslovnih jamstava

Optimistička kontrola konkurentnosti provjerava je li dokument promijenjen nakon verzije koju ste pročitali. Može odbiti zastarjelu izmjenu i spriječiti da jedan klijent neprimjetno prepiše rad drugoga. [Kontrola konkurentnosti](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Ta zaštita vrijedi za dokument koji se ažurira. Ne koordinira automatski dokument zalihe s narudžbom, ne daje relacijske strane ključeve i ne provodi proizvoljna pravila jedinstvenosti poslovnih polja.

Zapišite potrebna pravila prije izbora pohrane. Tako odluka postaje konkretna, umjesto da se oslanja na naziv „tražilica” ili „baza podataka”.

## 3. Provjerite kada upis postaje pretraživ

Uspješan upis i vidljiv rezultat pretrage odvojeni su događaji:

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

Osvježavanje čini nedavne promjene vidljivima pretrazi. Dohvat dokumenta po ID-u u stvarnom vremenu zato se razlikuje od upita pretrage. Opcija refresh=wait_for može čekati vidljivost, ali ne stvara transakciju više dokumenata. [Ponašanje osvježavanja](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

Za pretragu proizvoda kratko kašnjenje može biti prihvatljivo. Za konačnu odluku o plaćanju ili ovlastima izričito definirajte dosljednost i čitajte iz izvora koji je pruža. Osvježavanje i trajna pohrana također su različite stvari.

## 4. Odaberite ulogu Elasticsearcha

| Zahtjev | Smjer za procjenu | Razlog |
| --- | --- | --- |
| Narudžbe i povezani zapisi moraju se mijenjati atomski | Transakcijska glavna baza | Pravila ispravnosti trebaju biti blizu mjerodavnih zapisa. |
| Korisnici trebaju fleksibilnu pretragu cijelog teksta | Elasticsearch kao kopija za pretragu | Podaci za pretragu mogu se zasebno oblikovati i ponovno izgraditi. |
| Neovisni dokumenti s odgovarajućom dosljednošću | Elasticsearch može biti glavno spremište | Druga baza treba imati dokazanu svrhu. |

Čest dizajn sustava narudžbi jest:

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

CDC bilježi potvrđene promjene; outbox zapisuje događaj uz poslovnu promjenu u istoj transakciji. Zaseban proces dostavlja promjene indeksu. Tako ne ovisimo o tome da dva nepovezana upisa aplikacije uvijek uspiju zajedno.

Indeksiranje i dalje treba stabilne ID-jeve, obradu verzija, brisanja, ponovne pokušaje i praćenje kašnjenja. Testirajte ponovnu izgradnju indeksa iz izvora. Inače kopija za pretragu može postati drugi, nedosljedan izvor istine.

## 5. Potvrdite oporavak prije konačne odluke

Bez obzira na ulogu, planirajte sigurnosne kopije i testirajte vraćanje. Replike pomažu dostupnosti, ali ne zamjenjuju sigurnosne kopije. Odredite prihvatljiv gubitak podataka i vrijeme oporavka za stvarnu konfiguraciju.

Za narudžbe bih transakcijske zapise zadržao u bazi koja podržava njihova pravila, a Elasticsearch dodao ako ga pretraga opravdava. Za neovisne dokumente usmjerene na pretragu procijenio bih zadovoljava li Elasticsearch sam pohranu, dosljednost i oporavak.

**Zapamtite:** birajte prema jamstvima koja rad zahtijeva, zatim provjerite kvarove i oporavak. Brzina pretrage samo je dio odluke.

Zahtjev	Smjer za procjenu	Razlog
Narudžbe i povezani zapisi moraju se mijenjati atomski	Transakcijska glavna baza	Pravila ispravnosti trebaju biti blizu mjerodavnih zapisa.
Korisnici trebaju fleksibilnu pretragu cijelog teksta	Elasticsearch kao kopija za pretragu	Podaci za pretragu mogu se zasebno oblikovati i ponovno izgraditi.
Neovisni dokumenti s odgovarajućom dosljednošću	Elasticsearch može biti glavno spremište	Druga baza treba imati dokazanu svrhu.

1. Počnite od promjena koje moraju uspjeti zajedno

2. Razlikujte zaštitu dokumenta od poslovnih jamstava

3. Provjerite kada upis postaje pretraživ

4. Odaberite ulogu Elasticsearcha

5. Potvrdite oporavak prije konačne odluke

Povezana pitanja