Når passer Elasticsearch dårlig som primærdatabase?

Question

IT Interview Practice · Accepted Answer

Elasticsearch kan lagre data varig. For å avgjøre om det bør være hoveddatabasen, spør **hvilke forretningsregler som må gjelde når skriving feiler eller skjer samtidig**.

I et ordresystem er produktsøk og bekreftelse av kjøp ulike oppgaver. Søket trenger relevante treff; kjøpet trenger riktige betalings- og lagerendringer.

## 1. Begynn med endringer som må lykkes sammen

Anta at et kjøp trenger en ordrepost og en lagerreduksjon. Virksomheten må definere hva som skjer hvis bare én lykkes.

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

Elasticsearch sitt bulk-API sender flere dokumentoperasjoner samlet, men én kan feile mens en annen lykkes. Operasjonene blir ikke en transaksjon der alt eller ingenting skjer. Applikasjonen må kontrollere hvert resultat. [Bulk-API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Hvis kravet er en atomisk endring på tvers av poster, gir en transaksjonsdatabase vanligvis et mer direkte grunnlag. Å bygge koordineringen selv gir flere feiltilfeller og mer gjenopprettingsarbeid.

## 2. Skill dokumentbeskyttelse fra forretningsgarantier

Optimistisk samtidighetskontroll sjekker at dokumentet ikke har endret seg siden versjonen du leste. Den kan avvise en utdatert oppdatering og hindre at én klient ubemerket overskriver en annens arbeid. [Samtidighetskontroll](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Beskyttelsen gjelder dokumentet som oppdateres. Den koordinerer ikke automatisk lagerdokumentet med ordredokumentet, gir ikke relasjonelle fremmednøkler og håndhever ikke vilkårlige unikhetsregler på tvers av forretningsfelt.

Skriv ned applikasjonens regler før lagring velges. Da blir beslutningen konkret fremfor å bygge på merkelappen «søkemotor» eller «database».

## 3. Kontroller når en endring blir søkbar

En vellykket skriving og et synlig søkeresultat er separate hendelser:

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

En refresh gjør nye endringer synlige i søk. Et sanntidsoppslag med dokument-ID er derfor annerledes enn et søk. Valget refresh=wait_for kan vente på søkesynlighet, men oppretter ingen transaksjon over flere dokumenter. [Refresh-atferd](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

For en produktsøkeside kan kort forsinkelse være akseptabelt. For en endelig betalings- eller tilgangsbeslutning må nødvendig konsistens defineres uttrykkelig, og en kilde som tilbyr den, leses. Refresh og varig lagring er også ulike hensyn.

## 4. Velg rollen Elasticsearch skal ha

| Krav | Retning å vurdere | Begrunnelse |
| --- | --- | --- |
| Ordrer og relaterte poster må endres atomisk | Transaksjonell hoveddatabase | Korrekthetsreglene hører hjemme nær de autoritative postene. |
| Brukerne trenger fleksibelt fulltekstsøk | Elasticsearch som søkekopi | Søkedata kan formes og bygges på nytt uavhengig. |
| Uavhengige dokumenter med passende konsistenskrav | Elasticsearch kan passe som hovedlager | En ekstra database bør ha et påvist formål. |

Et vanlig design for ordrer er:

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

CDC fanger opp committede endringer; en outbox lagrer en hendelse sammen med forretningsendringen i samme transaksjon. En separat prosess leverer endringene til indeksen. Dette unngår å stole på at to uavhengige applikasjonsskrivinger alltid lykkes sammen.

Indekseringen trenger fortsatt stabile ID-er, versjonshåndtering, slettinger, nye forsøk og overvåking av etterslep. Test gjenoppbygging fra kilden. Ellers kan søkekopien bli en ekstra, inkonsistent sannhetskilde.

## 5. Bekreft gjenopprettingsmodellen før valget tas

Uansett rolle må sikkerhetskopier planlegges og gjenoppretting testes. Replikaer hjelper tilgjengeligheten, men erstatter ikke sikkerhetskopier. Definer akseptabelt datatap og gjenopprettingstid for den faktiske konfigurasjonen.

I ordreeksemplet ville jeg beholdt transaksjonelle poster i en database som støtter reglene deres, og lagt til Elasticsearch hvis søkekravene begrunner det. For uavhengige, søkeorienterte dokumenter ville jeg vurdert om Elasticsearch alene dekker lagring, konsistens og gjenoppretting.

**Husk:** velg etter garantiene arbeidsmengden trenger, og kontroller feil- og gjenopprettingsatferd. Søkehastighet er bare én del av beslutningen.

Krav	Retning å vurdere	Begrunnelse
Ordrer og relaterte poster må endres atomisk	Transaksjonell hoveddatabase	Korrekthetsreglene hører hjemme nær de autoritative postene.
Brukerne trenger fleksibelt fulltekstsøk	Elasticsearch som søkekopi	Søkedata kan formes og bygges på nytt uavhengig.
Uavhengige dokumenter med passende konsistenskrav	Elasticsearch kan passe som hovedlager	En ekstra database bør ha et påvist formål.

1. Begynn med endringer som må lykkes sammen

2. Skill dokumentbeskyttelse fra forretningsgarantier

3. Kontroller når en endring blir søkbar

4. Velg rollen Elasticsearch skal ha

5. Bekreft gjenopprettingsmodellen før valget tas

Relaterte spørsmål