Milloin Elasticsearch sopii huonosti päätietokannaksi?

Question

IT Interview Practice · Accepted Answer

Elasticsearch voi tallentaa tietoja pysyvästi. Pääasiallista tietokantaa valitessa kysy, **mitkä liiketoimintasäännöt on säilytettävä kirjoitusten epäonnistuessa tai tapahtuessa yhtä aikaa**.

Tuotteiden etsiminen ja ostoksen vahvistaminen ovat eri tehtäviä. Ensimmäisessä korostuu hakurelevanssi, jälkimmäisessä maksun ja varaston oikeellisuus.

## 1. Aloita yhdessä onnistuvista muutoksista

Ostos voi vaatia tilauksen ja varaston vähennyksen. On määritettävä, mitä tapahtuu vain toisen onnistuessa.

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

Bulk API lähettää monta dokumenttioperaatiota yhdessä, mutta yksittäinen voi epäonnistua muiden onnistuessa. Se ei luo kaikki tai ei mitään -transaktiota. Sovelluksen pitää tarkistaa jokainen tulos. [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Atomisiin usean tietueen muutoksiin transaktionaalinen tietokanta tarjoaa yleensä suoremman perustan. Oma koordinointi lisää virhetilanteita ja palautustyötä.

## 2. Erota dokumenttisuoja ja liiketoimintatakuu

Optimistinen samanaikaisuuden hallinta tarkistaa, onko dokumentti muuttunut lukemasi version jälkeen. Se voi hylätä vanhentuneen päivityksen ja estää toisen asiakkaan työn hiljaisen ylikirjoituksen. [Samanaikaisuuden hallinta](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Suoja koskee päivitettävää dokumenttia. Se ei automaattisesti koordinoi tilausta ja varastoa, tarjoa relaatiotietokannan viiteavaimia tai mielivaltaisia kenttien yksikäsitteisyyssääntöjä.

Kirjoita sovelluksen säännöt ennen varaston valintaa. Päätös perustuu silloin konkreettisiin vaatimuksiin eikä nimikkeisiin hakukone tai tietokanta.

## 3. Tarkista haettavuuden ajankohta

Onnistunut kirjoitus ja näkyvä hakutulos ovat eri tapahtumia:

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

Refresh tuo viime muutokset hakuihin. Reaaliaikainen ID-haku eroaa siksi hakukyselystä. refresh=wait_for voi odottaa hakunäkyvyyttä, mutta ei muodosta usean dokumentin transaktiota. [Refresh-toiminta](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

Tuotehaussa lyhyt viive voi sopia. Lopullisessa maksu- tai käyttöoikeuspäätöksessä määritä konsistenssi ja käytä sen tarjoavaa lähdettä. Refresh ja pysyvä tallennus ovat myös eri asioita.

## 4. Valitse Elasticsearchin rooli

| Vaatimus | Arvioitava suunta | Peruste |
| --- | --- | --- |
| Tilaukset ja liittyvät tiedot muuttuvat atomisesti | Transaktionaalinen pääkanta | Oikeellisuussäännöt kuuluvat varsinaisten tietueiden yhteyteen. |
| Joustava kokotekstihaku | Elasticsearch hakukopiona | Hakutiedot voidaan muotoilla ja rakentaa uudelleen erikseen. |
| Itsenäiset dokumentit ja sopiva konsistenssi | Voi toimia päävarastona | Toisella tietokannalla pitää olla osoitettu tarkoitus. |

Tavallinen tilausjärjestelmän rakenne:

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

CDC kerää vahvistetut muutokset; outbox tallentaa tapahtuman liiketoimintamuutoksen transaktiossa. Erillinen prosessi toimittaa ne indeksiin. Näin kaksi riippumatonta sovelluskirjoitusta ei joudu aina onnistumaan yhdessä.

Indeksointi tarvitsee silti vakaat ID:t, versiot, poistot, uusinnat ja viiveseurannan. Testaa uudelleenrakennus lähteestä, jottei hakukopiosta tule toista ristiriitaista totuutta.

## 5. Varmista palautusmalli

Suunnittele varmuuskopiot ja testaa palautus roolista riippumatta. Replikat auttavat saatavuutta, eivät korvaa varmuuskopioita. Määritä hyväksyttävä menetys ja palautusaika todelliselle asetukselle.

Tilauksissa pitäisin transaktiotiedot sääntöjä tukevassa kannassa ja lisäisin Elasticsearchin perusteltuun hakuun. Itsenäisissä hakudokumenteissa arvioisin, riittääkö se yksin tallennukseen, konsistenssiin ja palautukseen.

**Muista:** valitse tarvittavat takuut ja testaa virheet sekä palautus. Hakunopeus on vain osa päätöstä.

Vaatimus	Arvioitava suunta	Peruste
Tilaukset ja liittyvät tiedot muuttuvat atomisesti	Transaktionaalinen pääkanta	Oikeellisuussäännöt kuuluvat varsinaisten tietueiden yhteyteen.
Joustava kokotekstihaku	Elasticsearch hakukopiona	Hakutiedot voidaan muotoilla ja rakentaa uudelleen erikseen.
Itsenäiset dokumentit ja sopiva konsistenssi	Voi toimia päävarastona	Toisella tietokannalla pitää olla osoitettu tarkoitus.

1. Aloita yhdessä onnistuvista muutoksista

2. Erota dokumenttisuoja ja liiketoimintatakuu

3. Tarkista haettavuuden ajankohta

4. Valitse Elasticsearchin rooli

5. Varmista palautusmalli

Aiheeseen liittyvät kysymykset