När passar Elasticsearch dåligt som primär databas?

Question

IT Interview Practice · Accepted Answer

Elasticsearch kan lagra data beständigt. För att avgöra om det bör vara primär databas behöver du fråga **vilka verksamhetsregler som måste gälla när skrivningar misslyckas eller sker samtidigt**.

I ett ordersystem är produktsökning och köpbekräftelse olika uppgifter. Sökrelevans är viktig för den första; korrekta betalnings- och lagerändringar för den andra.

## 1. Börja med ändringarna som måste lyckas tillsammans

Anta att ett köp kräver en orderpost och en lagerminskning. Verksamheten måste definiera vad som ska hända om bara den ena lyckas.

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

Elasticsearchs bulk-API skickar flera dokumentoperationer tillsammans, men en kan misslyckas medan en annan lyckas. Operationerna blir inte en allt-eller-inget-transaktion. Applikationen måste kontrollera de enskilda resultaten. [Bulk-API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Om kravet är en atomär ändring över flera poster ger en transaktionsdatabas vanligtvis en mer direkt grund. Egen samordning tillför felsituationer och återställningsarbete.

## 2. Skilj dokumentskydd från verksamhetsgarantier

Optimistisk samtidighetskontroll kontrollerar att dokumentet inte har ändrats sedan den version du läste. Den kan avvisa en inaktuell uppdatering och hindra en klient från att tyst skriva över en annan klients arbete. [Samtidighetskontroll](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Skyddet gäller dokumentet som uppdateras. Det samordnar inte automatiskt lagerdokumentet med orderdokumentet, tillhandahåller inte relationella främmande nycklar och upprätthåller inte godtyckliga unicitetsregler mellan verksamhetsfält.

Skriv ned applikationens regler innan lagringen väljs. Då blir beslutet konkret i stället för att bygga på etiketten ”sökmotor” eller ”databas”.

## 3. Kontrollera när en skrivning blir sökbar

En lyckad skrivning och ett synligt sökresultat är separata händelser:

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

En refresh gör nya ändringar synliga för sökning. Ett realtidsuppslag via dokument-ID skiljer sig därför från en sökfråga. Alternativet refresh=wait_for kan vänta på söksynlighet, men skapar inte en transaktion över flera dokument. [Refresh-beteende](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

På en produktsöksida kan en kort synlighetsfördröjning vara acceptabel. För slutliga betalnings- eller behörighetsbeslut ska nödvändig konsistens definieras uttryckligen och en källa som ger den läsas. Refresh och beständig lagring är också olika frågor.

## 4. Välj Elasticsearchs roll

| Krav | Inriktning att utvärdera | Orsak |
| --- | --- | --- |
| Order och relaterade poster måste ändras atomärt | Transaktionell primär databas | Korrekthetsreglerna hör hemma nära de auktoritativa posterna. |
| Användarna behöver flexibel fulltextsökning | Elasticsearch som sökkopia | Sökdata kan utformas och återskapas oberoende. |
| Oberoende dokument med kompatibla konsistensbehov | Elasticsearch kan passa som huvudsakligt lager | En andra databas bör ha ett påvisat syfte. |

En vanlig design för ordersystem är:

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

CDC fångar committade ändringar; en outbox registrerar en händelse tillsammans med verksamhetsuppdateringen i samma transaktion. En separat process levererar ändringarna till indexet. Då förlitar man sig inte på att två oberoende applikationsskrivningar alltid lyckas tillsammans.

Indexeringsflödet behöver fortfarande stabila ID:n, versionshantering, raderingar, återförsök och övervakning av fördröjning. Testa att bygga om indexet från källan. Annars kan sökkopian bli en andra, inkonsekvent sanningskälla.

## 5. Bekräfta återställningsmodellen före beslutet

Oavsett roll ska säkerhetskopior planeras och återställning testas. Repliker hjälper tillgängligheten men ersätter inte säkerhetskopior. Definiera acceptabel dataförlust och återställningstid för den faktiska konfigurationen.

För orderexemplet skulle jag behålla transaktionsposter i en databas som stöder deras regler och lägga till Elasticsearch om sökkraven motiverar det. För oberoende, sökorienterade dokument skulle jag bedöma om Elasticsearch ensamt uppfyller behoven av lagring, konsistens och återställning.

**Kom ihåg:** välj utifrån belastningens nödvändiga garantier och verifiera sedan fel- och återställningsbeteende. Sökhastighet är bara en del av beslutet.

Krav	Inriktning att utvärdera	Orsak
Order och relaterade poster måste ändras atomärt	Transaktionell primär databas	Korrekthetsreglerna hör hemma nära de auktoritativa posterna.
Användarna behöver flexibel fulltextsökning	Elasticsearch som sökkopia	Sökdata kan utformas och återskapas oberoende.
Oberoende dokument med kompatibla konsistensbehov	Elasticsearch kan passa som huvudsakligt lager	En andra databas bör ha ett påvisat syfte.

1. Börja med ändringarna som måste lyckas tillsammans

2. Skilj dokumentskydd från verksamhetsgarantier

3. Kontrollera när en skrivning blir sökbar

4. Välj Elasticsearchs roll

5. Bekräfta återställningsmodellen före beslutet

Relaterade frågor