Kapan Elasticsearch ora cocog dadi database utama?

Question

IT Interview Practice · Accepted Answer

Elasticsearch bisa nyimpen data kanthi awet. Kanggo mutusake apa cocog dadi database utama, takonana **aturan bisnis apa sing kudu tetep bener nalika panulisan gagal utawa mlaku bebarengan**.

Ing sistem pesenan, nggoleki produk lan ngonfirmasi tuku iku rong gaweyan beda. Relevansi telusuran penting kanggo sing kapisan; pembayaran lan owah-owahan stok sing bener penting kanggo sing kapindho.

## 1. Wiwiti saka owah-owahan sing kudu sukses bebarengan

Upamane tuku butuh record pesenan lan pengurangan stok. Bisnis kudu nemtokake apa sing kelakon yen mung salah siji sukses.

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

Bulk API Elasticsearch ngirim sawetara operasi dokumen bebarengan, nanging siji item bisa gagal nalika liyane sukses. Iki ora ndadekake kabeh operasi dadi transaksi sing kabeh sukses utawa kabeh dibatalake. Aplikasi kudu mriksa asil saben item. [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Yen syarate owah-owahan atomik ing sawetara record, database transaksional lumrahe menehi dhasar sing luwih langsung. Nggawe koordinasi kasebut dhewe nambah kasus kegagalan lan gaweyan pamulihan.

## 2. Bedakake pangayoman dokumen lan jaminan bisnis

Optimistic concurrency control mriksa manawa dokumen durung owah wiwit versi sing diwaca. Bisa nolak pembaruan saka versi lawas supaya siji klien ora meneng-meneng nimpa gaweyan klien liyane. [Kontrol konkurensi](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Pangayoman kasebut mung kanggo dokumen sing dianyari. Ora otomatis nyelarasake dokumen stok karo dokumen pesenan, nyedhiyakake foreign key relasional, utawa ngetrapake sembarang aturan unik ing field bisnis.

Tulisen aturan sing dibutuhake aplikasi sadurunge milih panyimpenan. Iki nggawe keputusan nyata, ora mung gumantung label “mesin telusur” utawa “database”.

## 3. Priksa kapan panulisan katon ing telusuran

Panulisan sukses lan asil sing katon ing telusuran iku kedadeyan kapisah:

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

Refresh nggawe owah-owahan anyar katon ing telusuran. Mula, njupuk dokumen kanthi ID kanthi real-time beda karo query telusuran. Opsi refresh=wait_for bisa ngenteni nganti katon ing telusuran, nanging ora nggawe transaksi sawetara dokumen. [Prilaku refresh](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

Kanggo kaca telusuran produk, wektu tundha cekak bisa ditampa. Kanggo keputusan pembayaran pungkasan utawa ijin akses, jelasake konsistensi sing dibutuhake lan waca sumber sing nyedhiyakake. Refresh lan panyimpenan awet uga rong perkara beda.

## 4. Pilih peran Elasticsearch

| Syarat | Pilihan sing dievaluasi | Alesan |
| --- | --- | --- |
| Pesenan lan record gandhengan kudu owah atomik | Database utama transaksional | Aturan bener kudu cedhak record sing dadi sumber resmi. |
| Pangguna butuh telusuran teks lengkap sing luwes | Elasticsearch minangka salinan telusuran | Data telusuran bisa dibentuk lan dibangun ulang kanthi mandiri. |
| Dokumen mandiri kanthi syarat konsistensi sing cocog | Elasticsearch bisa cocog dadi panyimpenan utama | Database kapindho kudu duwe tujuan sing kabukten. |

Desain sing umum kanggo sistem pesenan yaiku:

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

CDC njupuk owah-owahan sing wis di-commit; outbox nyathet event bareng pembaruan bisnis ing transaksi sing padha. Proses kapisah ngirim owah-owahan kasebut menyang indeks. Iki nyingkiri gumantung marang rong panulisan aplikasi mandiri supaya tansah sukses bebarengan.

Alur indeks tetep butuh ID stabil, penanganan versi, pambusakan, nyoba maneh, lan pemantauan keterlambatan. Uji mbangun ulang indeks saka sumber. Yen ora, salinan telusuran bisa dadi sumber kebenaran kapindho sing ora konsisten.

## 5. Pasthekake model pamulihan sadurunge milih

Apa wae perane, rencanakake backup lan uji restore. Replika mbantu kasedhiyan nanging ora ngganti backup. Temtokake data ilang lan wektu pulih sing bisa ditampa ing konfigurasi nyata.

Kanggo tuladha pesenan, aku bakal nyimpen record transaksional ing database sing ndhukung aturane, banjur nambah Elasticsearch yen kabutuhan telusuran mbenerake. Kanggo dokumen mandiri sing fokus telusuran, aku bakal mriksa apa Elasticsearch dhewe nyukupi panyimpenan, konsistensi, lan pamulihan.

**Elinga:** pilih miturut jaminan sing dibutuhake beban kerja, banjur priksa prilaku nalika gagal lan pulih. Kacepetan telusuran mung salah siji bagean keputusan.

Syarat	Pilihan sing dievaluasi	Alesan
Pesenan lan record gandhengan kudu owah atomik	Database utama transaksional	Aturan bener kudu cedhak record sing dadi sumber resmi.
Pangguna butuh telusuran teks lengkap sing luwes	Elasticsearch minangka salinan telusuran	Data telusuran bisa dibentuk lan dibangun ulang kanthi mandiri.
Dokumen mandiri kanthi syarat konsistensi sing cocog	Elasticsearch bisa cocog dadi panyimpenan utama	Database kapindho kudu duwe tujuan sing kabukten.

1. Wiwiti saka owah-owahan sing kudu sukses bebarengan

2. Bedakake pangayoman dokumen lan jaminan bisnis

3. Priksa kapan panulisan katon ing telusuran

4. Pilih peran Elasticsearch

5. Pasthekake model pamulihan sadurunge milih

Pitakon sing gegandhengan