Bilakah Elasticsearch kurang sesuai sebagai pangkalan data utama?

Question

IT Interview Practice · Accepted Answer

Elasticsearch boleh menyimpan data secara tahan lama. Untuk memilihnya sebagai pangkalan data utama, tanya **peraturan perniagaan yang mesti kekal benar apabila penulisan gagal atau berlaku serentak**.

Dalam sistem pesanan, mencari produk dan mengesahkan pembelian ialah tugas berlainan. Kerelevanan carian penting bagi yang pertama; ketepatan pembayaran dan perubahan stok penting bagi yang kedua.

## 1. Mulakan dengan perubahan yang mesti berjaya bersama

Andaikan pembelian memerlukan rekod pesanan dan pengurangan stok. Perniagaan mesti menentukan tindakan jika hanya satu berjaya.

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

Bulk API Elasticsearch menghantar beberapa operasi dokumen bersama, tetapi satu item boleh gagal sementara yang lain berjaya. Ia bukan transaksi yang semuanya berjaya atau semuanya dibatalkan. Aplikasi perlu menyemak hasil setiap item. [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Jika perubahan merentas rekod perlu atomik, pangkalan data transaksi biasanya memberi asas lebih terus. Membina penyelarasan sendiri menambah kes kegagalan dan kerja pemulihan.

## 2. Bezakan perlindungan dokumen daripada jaminan perniagaan

Kawalan keserentakan optimistik memeriksa sama ada dokumen berubah sejak versi yang dibaca. Ia boleh menolak kemas kini lapuk agar satu klien tidak menimpa kerja klien lain tanpa disedari. [Kawalan keserentakan](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Perlindungan itu terpakai pada dokumen yang dikemas kini. Ia tidak menyelaraskan dokumen stok dengan pesanan secara automatik, menyediakan kunci asing hubungan atau menguatkuasakan sebarang peraturan keunikan merentas medan perniagaan.

Tuliskan peraturan aplikasi sebelum memilih storan. Keputusan menjadi nyata dan tidak bergantung pada label “enjin carian” atau “pangkalan data”.

## 3. Semak bila penulisan boleh dicari

Penulisan berjaya dan hasil yang kelihatan dalam carian ialah peristiwa berasingan:

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

Refresh menjadikan perubahan terkini kelihatan dalam carian. Oleh itu, mendapatkan dokumen mengikut ID secara masa nyata berbeza daripada pertanyaan carian. refresh=wait_for boleh menunggu keterlihatan carian, tetapi tidak mewujudkan transaksi berbilang dokumen. [Kelakuan refresh](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

Halaman carian produk mungkin menerima kelewatan singkat. Untuk keputusan pembayaran akhir atau kebenaran akses, tentukan konsistensi yang diperlukan dan baca sumber yang menjaminnya. Refresh dan storan tahan lama juga isu berbeza.

## 4. Pilih peranan Elasticsearch

| Keperluan | Arah untuk dinilai | Sebab |
| --- | --- | --- |
| Pesanan dan rekod berkaitan mesti berubah secara atomik | Pangkalan data utama transaksi | Peraturan ketepatan perlu dekat dengan rekod berautoriti. |
| Pengguna memerlukan carian teks penuh fleksibel | Elasticsearch sebagai salinan carian | Data carian boleh dibentuk dan dibina semula secara berasingan. |
| Dokumen bebas dengan konsistensi yang sesuai | Elasticsearch mungkin sesuai sebagai stor utama | Pangkalan data kedua perlu tujuan yang terbukti. |

Reka bentuk biasa untuk pesanan ialah:

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

CDC menangkap perubahan yang telah dikomit; outbox merekodkan peristiwa bersama kemas kini perniagaan dalam transaksi sama. Proses lain menghantarnya ke indeks. Ini mengelakkan pergantungan pada dua penulisan aplikasi berasingan untuk sentiasa berjaya bersama.

Laluan indeks masih memerlukan ID stabil, pengendalian versi, pemadaman, percubaan semula dan pemantauan kelewatan. Uji pembinaan semula indeks daripada sumber. Jika tidak, salinan carian boleh menjadi sumber kebenaran kedua yang tidak konsisten.

## 5. Pastikan model pemulihan sebelum memilih

Apa pun peranannya, rancang sandaran dan uji pemulihan. Replika membantu ketersediaan tetapi bukan pengganti sandaran. Tentukan kehilangan data dan masa pemulihan yang boleh diterima bagi konfigurasi sebenar.

Untuk pesanan, saya akan menyimpan rekod transaksi dalam pangkalan data yang menyokong peraturannya dan menambah Elasticsearch jika carian memerlukannya. Untuk dokumen bebas berorientasikan carian, saya akan menilai sama ada Elasticsearch sahaja memenuhi storan, konsistensi dan pemulihan.

**Ingat:** pilih berdasarkan jaminan beban kerja, kemudian sahkan kegagalan dan pemulihan. Kelajuan carian hanya satu bahagian keputusan.

Keperluan	Arah untuk dinilai	Sebab
Pesanan dan rekod berkaitan mesti berubah secara atomik	Pangkalan data utama transaksi	Peraturan ketepatan perlu dekat dengan rekod berautoriti.
Pengguna memerlukan carian teks penuh fleksibel	Elasticsearch sebagai salinan carian	Data carian boleh dibentuk dan dibina semula secara berasingan.
Dokumen bebas dengan konsistensi yang sesuai	Elasticsearch mungkin sesuai sebagai stor utama	Pangkalan data kedua perlu tujuan yang terbukti.

1. Mulakan dengan perubahan yang mesti berjaya bersama

2. Bezakan perlindungan dokumen daripada jaminan perniagaan

3. Semak bila penulisan boleh dicari

4. Pilih peranan Elasticsearch

5. Pastikan model pemulihan sebelum memilih

Soalan berkaitan