Hvornår passer Elasticsearch dårligt som primær database?

Question

IT Interview Practice · Accepted Answer

Elasticsearch kan gemme data varigt. For at afgøre, om det skal være den primære database, så spørg **hvilke forretningsregler der skal holde ved fejl eller samtidige skrivninger**.

I et ordresystem er produktsøgning og bekræftelse af køb forskellige opgaver. Den første kræver relevante søgeresultater, den anden korrekte betalings- og lagerændringer.

## 1. Begynd med ændringer, der skal lykkes sammen

Antag, at et køb kræver en ordrepost og en lagerreduktion. Forretningen skal definere, hvad der sker, hvis kun den ene lykkes.

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

Elasticsearchs bulk API sender flere dokumentoperationer sammen, men ét element kan fejle, mens et andet lykkes. Det gør dem ikke til en alt-eller-intet-transaktion. Applikationen skal kontrollere de enkelte resultater. [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Hvis ændringer på tværs af poster skal være atomiske, giver en transaktionel database normalt et mere direkte fundament. Egen koordinering tilføjer fejltilfælde og gendannelsesarbejde.

## 2. Skeln mellem dokumentbeskyttelse og forretningsgarantier

Optimistisk samtidighedskontrol undersøger, om dokumentet er ændret siden den læste version. Den kan afvise en forældet opdatering og forhindre, at en klient ubemærket overskriver en andens arbejde. [Samtidighedskontrol](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Beskyttelsen gælder det opdaterede dokument. Den koordinerer ikke automatisk lagerdokumentet med ordredokumentet, giver ikke relationelle fremmednøgler og håndhæver ikke vilkårlige unikhedsregler på forretningsfelter.

Skriv applikationens regler ned før valg af lager. Det gør beslutningen konkret i stedet for at bygge på mærkatet “søgemaskine” eller “database”.

## 3. Undersøg, hvornår en skrivning kan søges

En vellykket skrivning og et synligt søgeresultat er adskilte hændelser:

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

Refresh gør nylige ændringer synlige for søgning. Et realtidsopslag efter dokument-ID er derfor anderledes end en søgeforespørgsel. refresh=wait_for kan vente på søgesynlighed, men skaber ikke en transaktion over flere dokumenter. [Refresh-adfærd](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

På en produktsøgeside kan kort forsinkelse være acceptabel. Ved en endelig betalings- eller adgangsbeslutning skal konsistenskravet være udtrykkeligt, og kilden skal opfylde det. Refresh og varig lagring er også forskellige hensyn.

## 4. Vælg Elasticsearchs rolle

| Krav | Retning til vurdering | Begrundelse |
| --- | --- | --- |
| Ordrer og relaterede poster skal ændres atomisk | Transaktionel primær database | Korrekthedsregler hører hjemme tæt ved de autoritative poster. |
| Fleksibel fuldtekstsøgning | Elasticsearch som søgekopi | Søgedata kan formes og genopbygges uafhængigt. |
| Uafhængige dokumenter med passende konsistensbehov | Elasticsearch kan passe som hovedlager | En ekstra database bør have et påvist formål. |

Et almindeligt ordredesign er:

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

CDC opsamler bekræftede ændringer; en outbox registrerer en hændelse sammen med forretningsændringen i samme transaktion. En separat proces leverer ændringerne til indekset. Dermed afhænger systemet ikke af, at to uafhængige applikationsskrivninger altid lykkes sammen.

Indekseringen kræver stadig stabile ID'er, versionshåndtering, sletninger, gentagelser og overvågning af forsinkelse. Test genopbygning fra kilden. Ellers kan søgekopien blive en anden, inkonsistent sandhedskilde.

## 5. Bekræft gendannelsesmodellen før valget

Uanset rolle skal backups planlægges og gendannelse testes. Replikaer hjælper tilgængelighed, men erstatter ikke backups. Definér acceptabelt datatab og gendannelsestid for den faktiske konfiguration.

I ordreeksemplet ville jeg beholde transaktionelle poster i en database, der understøtter reglerne, og tilføje Elasticsearch, hvis søgekravene begrunder det. For uafhængige søgedokumenter ville jeg vurdere, om Elasticsearch alene opfylder lagring, konsistens og gendannelse.

**Husk:** vælg efter de nødvendige garantier, og verificér derefter fejl og gendannelse. Søgehastighed er kun en del af beslutningen.

Krav	Retning til vurdering	Begrundelse
Ordrer og relaterede poster skal ændres atomisk	Transaktionel primær database	Korrekthedsregler hører hjemme tæt ved de autoritative poster.
Fleksibel fuldtekstsøgning	Elasticsearch som søgekopi	Søgedata kan formes og genopbygges uafhængigt.
Uafhængige dokumenter med passende konsistensbehov	Elasticsearch kan passe som hovedlager	En ekstra database bør have et påvist formål.

1. Begynd med ændringer, der skal lykkes sammen

2. Skeln mellem dokumentbeskyttelse og forretningsgarantier

3. Undersøg, hvornår en skrivning kan søges

4. Vælg Elasticsearchs rolle

5. Bekræft gendannelsesmodellen før valget

Relaterede spørgsmål