Wanneer is Elasticsearch ongeschikt als primaire database?

Question

IT Interview Practice · Accepted Answer

Elasticsearch kan gegevens duurzaam opslaan. Vraag bij de keuze voor een primaire database **welke bedrijfsregels waar moeten blijven wanneer schrijfbewerkingen mislukken of gelijktijdig plaatsvinden**.

In een bestelsysteem zijn producten zoeken en een aankoop bevestigen verschillende taken. Bij de eerste telt zoekrelevantie; bij de tweede tellen correcte betalingen en voorraadwijzigingen.

## 1. Begin met wijzigingen die samen moeten slagen

Stel dat een aankoop een bestelrecord en een voorraadvermindering vereist. Het bedrijf moet bepalen wat er gebeurt als slechts één daarvan slaagt.

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

De bulk-API van Elasticsearch verstuurt meerdere documentbewerkingen tegelijk, maar één onderdeel kan mislukken terwijl een ander slaagt. Dit maakt de bewerkingen niet tot een alles-of-nietstransactie. De applicatie moet individuele resultaten controleren. [Bulk-API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Als een atomaire wijziging over meerdere records nodig is, biedt een transactionele database meestal een directere basis. Zelf die coördinatie bouwen voegt foutscenario’s en herstelwerk toe.

## 2. Onderscheid documentbescherming van bedrijfsgaranties

Optimistische concurrencycontrole controleert of een document niet is veranderd sinds de gelezen versie. Zij kan een verouderde update weigeren en voorkomen dat de ene client ongemerkt het werk van een andere overschrijft. [Concurrencycontrole](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Die bescherming geldt voor het bijgewerkte document. Ze coördineert niet automatisch het voorraaddocument met het besteldocument, biedt geen relationele foreign keys en handhaaft niet zomaar uniciteitsregels over bedrijfsvelden.

Schrijf de benodigde applicatieregels op voordat je opslag kiest. Daarmee maak je de beslissing concreet, zonder te vertrouwen op het etiket “zoekmachine” of “database”.

## 3. Controleer wanneer een wijziging doorzoekbaar wordt

Een geslaagde schrijfbewerking en een zichtbaar zoekresultaat zijn afzonderlijke gebeurtenissen:

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

Een refresh maakt recente wijzigingen zichtbaar voor zoekopdrachten. Een realtime-opvraag op document-ID verschilt daarom van een zoekquery. De optie refresh=wait_for kan wachten op zoekzichtbaarheid, maar creëert geen transactie over meerdere documenten. [Refreshgedrag](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

Voor een productzoekpagina kan korte zichtbaarheidsvertraging acceptabel zijn. Definieer voor een definitieve betaling of toegangsbeslissing expliciet de vereiste consistentie en lees een bron die deze biedt. Refresh en duurzame opslag zijn bovendien verschillende zaken.

## 4. Kies de rol van Elasticsearch

| Vereiste | Te beoordelen richting | Reden |
| --- | --- | --- |
| Bestellingen en gerelateerde records moeten atomair veranderen | Transactionele primaire database | De vereiste correctheidsregels horen dicht bij de gezaghebbende records. |
| Gebruikers hebben flexibele volledige-tekstzoekopdrachten nodig | Elasticsearch als zoekkopie | Zoekgegevens kunnen onafhankelijk worden ingericht en herbouwd. |
| Onafhankelijke documenten met passende consistentie-eisen | Elasticsearch kan als hoofdopslag passen | Een tweede database moet een aantoonbaar doel hebben. |

Een gebruikelijk ontwerp voor bestellingen is:

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

CDC legt gecommitteerde wijzigingen vast; een outbox registreert een gebeurtenis naast de bedrijfswijziging in dezelfde transactie. Een apart proces levert die wijzigingen aan de index. Zo vertrouw je niet op twee onafhankelijke applicatieschrijfacties die altijd samen moeten slagen.

Het indexeerproces heeft nog steeds stabiele ID’s, versieafhandeling, verwijderingen, retries en bewaking van achterstand nodig. Test het opnieuw opbouwen van de index vanuit de bron. Anders kan een zoekkopie een tweede, inconsistente bron van waarheid worden.

## 5. Bevestig het herstelmodel vóór de keuze

Plan bij iedere rol back-ups en test herstel. Replica’s helpen de beschikbaarheid, maar vervangen geen back-ups. Bepaal acceptabel gegevensverlies en hersteltijd voor de daadwerkelijke configuratie.

Voor het bestelvoorbeeld zou ik transactionele records bewaren in een database die hun regels ondersteunt en Elasticsearch toevoegen als de zoekeisen dat rechtvaardigen. Voor onafhankelijke, zoekgerichte documenten beoordeel ik of alleen Elasticsearch voldoet aan opslag-, consistentie- en hersteleisen.

**Onthoud:** kies op basis van de garanties die het werk nodig heeft en controleer daarna fout- en herstelgedrag. Zoeksnelheid is slechts één deel van die beslissing.

Vereiste	Te beoordelen richting	Reden
Bestellingen en gerelateerde records moeten atomair veranderen	Transactionele primaire database	De vereiste correctheidsregels horen dicht bij de gezaghebbende records.
Gebruikers hebben flexibele volledige-tekstzoekopdrachten nodig	Elasticsearch als zoekkopie	Zoekgegevens kunnen onafhankelijk worden ingericht en herbouwd.
Onafhankelijke documenten met passende consistentie-eisen	Elasticsearch kan als hoofdopslag passen	Een tweede database moet een aantoonbaar doel hebben.

1. Begin met wijzigingen die samen moeten slagen

2. Onderscheid documentbescherming van bedrijfsgaranties

3. Controleer wanneer een wijziging doorzoekbaar wordt

4. Kies de rol van Elasticsearch

5. Bevestig het herstelmodel vóór de keuze

Gerelateerde vragen