Kapan Elasticsearch kurang cocok sebagai database utama?

Question

IT Interview Practice · Accepted Answer

Elasticsearch dapat menyimpan data secara tahan lama. Untuk menentukan apakah Elasticsearch cocok menjadi database utama, tanyakan **aturan bisnis apa yang harus tetap benar ketika penulisan gagal atau berlangsung bersamaan**.

Dalam sistem pemesanan, mencari produk dan mengonfirmasi pembelian merupakan dua pekerjaan berbeda. Relevansi pencarian penting untuk pekerjaan pertama; ketepatan pembayaran dan perubahan stok penting untuk pekerjaan kedua.

## 1. Mulai dari perubahan yang harus berhasil bersama

Misalnya, pembelian membutuhkan pencatatan pesanan sekaligus pengurangan stok. Bisnis harus menentukan apa yang terjadi jika hanya salah satunya berhasil.

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

Bulk API Elasticsearch mengirim beberapa operasi dokumen bersama-sama, tetapi satu item dapat gagal sementara item lain berhasil. API ini tidak menjadikannya transaksi yang seluruh operasinya harus berhasil atau dibatalkan bersama. Aplikasi harus memeriksa hasil setiap item. [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

Jika perubahan beberapa record harus bersifat atomik, database transaksional biasanya memberikan dasar yang lebih langsung. Membuat koordinasi tersebut sendiri menambah kemungkinan kegagalan dan pekerjaan pemulihan.

## 2. Bedakan perlindungan dokumen dari jaminan bisnis

Kontrol konkurensi optimistis memeriksa apakah dokumen berubah sejak versi yang Anda baca. Mekanisme ini dapat menolak pembaruan berdasarkan versi lama, sehingga satu klien tidak diam-diam menimpa pekerjaan klien lain. [Kontrol konkurensi](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

Perlindungan itu berlaku pada dokumen yang diperbarui. Mekanisme tersebut tidak otomatis mengoordinasikan dokumen stok dengan dokumen pesanan, menyediakan foreign key relasional, atau menerapkan sembarang aturan keunikan pada berbagai field bisnis.

Tuliskan aturan yang dibutuhkan aplikasi sebelum memilih penyimpanan. Dengan begitu, keputusan didasarkan pada kebutuhan nyata, bukan sekadar label “mesin pencari” atau “database”.

## 3. Periksa kapan hasil penulisan dapat dicari

Penulisan yang berhasil dan hasil yang terlihat dalam pencarian adalah dua kejadian berbeda:

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

Refresh membuat perubahan terbaru terlihat dalam pencarian. Karena itu, pengambilan dokumen secara real-time berdasarkan ID berbeda dari kueri pencarian. Opsi refresh=wait_for dapat menunggu sampai perubahan terlihat dalam pencarian, tetapi tidak menciptakan transaksi beberapa dokumen. [Perilaku refresh](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

Untuk halaman pencarian produk, jeda singkat sebelum perubahan terlihat mungkin dapat diterima. Untuk keputusan pembayaran akhir atau hak akses, tentukan konsistensi yang dibutuhkan secara jelas dan baca sumber yang memberikannya. Refresh dan ketahanan penyimpanan juga merupakan dua hal berbeda.

## 4. Pilih peran Elasticsearch

| Kebutuhan | Pilihan yang perlu dievaluasi | Alasan |
| --- | --- | --- |
| Pesanan dan record terkait harus berubah secara atomik | Database utama transaksional | Aturan kebenaran data perlu diterapkan dekat record yang menjadi sumber resmi. |
| Pengguna membutuhkan pencarian teks lengkap yang fleksibel | Elasticsearch sebagai salinan untuk pencarian | Data pencarian dapat dibentuk dan dibangun ulang secara terpisah. |
| Dokumen independen dengan kebutuhan konsistensi yang sesuai | Elasticsearch mungkin cocok sebagai penyimpanan utama | Penggunaan database kedua harus memiliki manfaat yang terbukti. |

Desain yang umum untuk sistem pemesanan adalah:

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

CDC menangkap perubahan yang sudah di-commit; outbox mencatat event bersama pembaruan bisnis dalam transaksi yang sama. Proses terpisah mengirim perubahan tersebut ke indeks. Dengan demikian, sistem tidak bergantung pada dua penulisan aplikasi yang terpisah untuk selalu berhasil bersama.

Alur pengindeksan tetap memerlukan ID yang stabil, penanganan versi, penghapusan, percobaan ulang, dan pemantauan keterlambatan. Uji pembangunan ulang indeks dari sumber. Jika tidak, salinan pencarian dapat berubah menjadi sumber kebenaran kedua yang tidak konsisten.

## 5. Pastikan model pemulihan sebelum menetapkan pilihan

Apa pun perannya, rencanakan backup dan uji pemulihannya. Replika membantu ketersediaan, tetapi tidak menggantikan backup. Tentukan kehilangan data dan waktu pemulihan yang dapat diterima berdasarkan konfigurasi sebenarnya.

Untuk contoh pesanan, saya akan menyimpan record transaksional dalam database yang mendukung aturan bisnisnya, lalu menambahkan Elasticsearch jika kebutuhan pencarian membenarkannya. Untuk dokumen independen yang berorientasi pencarian, saya akan menilai apakah Elasticsearch sendiri memenuhi kebutuhan penyimpanan, konsistensi, dan pemulihan.

**Ingat:** pilih berdasarkan jaminan yang dibutuhkan beban kerja, lalu verifikasi perilaku saat gagal dan pulih. Kecepatan pencarian hanyalah salah satu bagian keputusan.

Kebutuhan	Pilihan yang perlu dievaluasi	Alasan
Pesanan dan record terkait harus berubah secara atomik	Database utama transaksional	Aturan kebenaran data perlu diterapkan dekat record yang menjadi sumber resmi.
Pengguna membutuhkan pencarian teks lengkap yang fleksibel	Elasticsearch sebagai salinan untuk pencarian	Data pencarian dapat dibentuk dan dibangun ulang secara terpisah.
Dokumen independen dengan kebutuhan konsistensi yang sesuai	Elasticsearch mungkin cocok sebagai penyimpanan utama	Penggunaan database kedua harus memiliki manfaat yang terbukti.

1. Mulai dari perubahan yang harus berhasil bersama

2. Bedakan perlindungan dokumen dari jaminan bisnis

3. Periksa kapan hasil penulisan dapat dicari

4. Pilih peran Elasticsearch

5. Pastikan model pemulihan sebelum menetapkan pilihan

Pertanyaan terkait