Când este Elasticsearch nepotrivit ca bază de date principală?

Question

IT Interview Practice · Accepted Answer

Elasticsearch poate păstra date durabil. Pentru a decide dacă ar trebui să fie baza principală, întreabă **ce reguli de afaceri trebuie să rămână adevărate când scrierile eșuează sau rulează simultan**.

Într-un sistem de comenzi, găsirea produselor și confirmarea cumpărării sunt sarcini diferite. Pentru prima contează relevanța căutării; pentru a doua, modificarea corectă a plății și stocului.

## 1. Începe cu modificările care trebuie să reușească împreună

Să presupunem că o cumpărare necesită o comandă și o reducere a stocului. Firma trebuie să definească ce se întâmplă dacă reușește doar una dintre operații.

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

API-ul bulk al Elasticsearch trimite împreună mai multe operații pe documente, dar un element poate eșua în timp ce altul reușește. Nu le transformă într-o tranzacție de tip totul-sau-nimic. Aplicația trebuie să inspecteze rezultatele individuale. [API bulk](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Dacă cerința este o modificare atomică a mai multor înregistrări, o bază tranzacțională oferă de obicei o fundație mai directă. Implementarea proprie a coordonării adaugă situații de eșec și muncă de recuperare.

## 2. Separă protecția documentului de garanțiile de afaceri

Controlul optimist al concurenței verifică dacă documentul s-a schimbat față de versiunea citită. Poate respinge o actualizare învechită, împiedicând un client să suprascrie neobservat munca altuia. [Controlul concurenței](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Protecția se aplică documentului actualizat. Nu coordonează automat documentul de stoc cu cel de comandă, nu oferă chei străine relaționale și nu impune reguli arbitrare de unicitate între câmpuri de afaceri.

Scrie regulile necesare aplicației înainte de alegerea stocării. Astfel, decizia devine concretă, fără să se bazeze pe eticheta „motor de căutare” sau „bază de date”.

## 3. Verifică momentul în care o scriere devine căutabilă

O scriere reușită și un rezultat vizibil în căutare sunt evenimente separate:

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

Un refresh face modificările recente vizibile căutării. Prin urmare, căutarea în timp real după ID-ul documentului diferă de o interogare de căutare. Opțiunea refresh=wait_for poate aștepta vizibilitatea în căutare, dar nu creează o tranzacție între mai multe documente. [Comportamentul refresh](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

Pentru pagina de căutare a produselor, o mică întârziere poate fi acceptabilă. Pentru decizia finală privind plata sau permisiunile, definește explicit consistența necesară și citește dintr-o sursă care o asigură. Refresh și stocarea durabilă sunt, de asemenea, preocupări diferite.

## 4. Alege rolul Elasticsearch

| Cerință | Direcție de evaluat | Motiv |
| --- | --- | --- |
| Comenzile și înregistrările asociate trebuie modificate atomic | Bază principală tranzacțională | Regulile de corectitudine trebuie să fie aproape de înregistrările autoritative. |
| Utilizatorii au nevoie de căutare flexibilă în text | Elasticsearch drept copie pentru căutare | Datele de căutare pot fi modelate și reconstruite independent. |
| Documente independente, cu nevoi compatibile de consistență | Elasticsearch poate fi potrivit ca stocare principală | O a doua bază trebuie să aibă un scop demonstrat. |

Un design obișnuit pentru comenzi este:

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

CDC capturează modificările confirmate; un outbox înregistrează un eveniment alături de actualizarea de afaceri în aceeași tranzacție. Un proces separat livrează modificările către index. Astfel, nu depindem de reușita simultană a două scrieri independente ale aplicației.

Fluxul de indexare necesită în continuare ID-uri stabile, tratarea versiunilor și ștergerilor, reluări și monitorizarea întârzierii. Testează reconstruirea indexului din sursă. Altfel, copia de căutare poate deveni o a doua sursă de adevăr, inconsistentă.

## 5. Confirmă modelul de recuperare înainte de alegerea finală

Indiferent de rol, planifică copii de siguranță și testează restaurarea. Replicile ajută disponibilitatea, dar nu înlocuiesc backupurile. Definește pierderea acceptabilă de date și timpul de recuperare pentru configurația reală.

Pentru exemplul comenzilor, aș păstra înregistrările tranzacționale într-o bază care le susține regulile și aș adăuga Elasticsearch dacă cerințele căutării justifică acest lucru. Pentru documente independente orientate spre căutare, aș evalua dacă Elasticsearch singur satisface nevoile de stocare, consistență și recuperare.

**De reținut:** alege după garanțiile necesare sarcinii, apoi verifică comportamentul la eșec și recuperare. Viteza căutării este doar o parte a deciziei.

Cerință	Direcție de evaluat	Motiv
Comenzile și înregistrările asociate trebuie modificate atomic	Bază principală tranzacțională	Regulile de corectitudine trebuie să fie aproape de înregistrările autoritative.
Utilizatorii au nevoie de căutare flexibilă în text	Elasticsearch drept copie pentru căutare	Datele de căutare pot fi modelate și reconstruite independent.
Documente independente, cu nevoi compatibile de consistență	Elasticsearch poate fi potrivit ca stocare principală	O a doua bază trebuie să aibă un scop demonstrat.

1. Începe cu modificările care trebuie să reușească împreună

2. Separă protecția documentului de garanțiile de afaceri

3. Verifică momentul în care o scriere devine căutabilă

4. Alege rolul Elasticsearch

5. Confirmă modelul de recuperare înainte de alegerea finală

Întrebări conexe