Jaga indeks tetap mutakhir

Pertanyaan

Bagaimana perubahan di sumber data sampai ke indeks tanpa kehilangan, menggandakan, atau membangkitkan kembali data yang sudah dihapus?

Setelah baca ini, kamu bisa merancang pipeline pengindeksan dengan pembaruan idempoten, menjelaskan kenapa penghapusan itu sulit, dan merencanakan backfill serta replay yang aman.

Prasyarat dan contoh

Kamu sudah paham inverted index (M11.01), antrean dan pemrosesan ulang (M10), dan partisi data (M07).

Sebuah resep diedit pukul 10.00:00, lalu dihapus pukul 10.00:05. Pipeline mengirim dua event ke antrean. Karena retry, event edit baru diproses setelah event hapus. Indeks sekarang memuat resep yang sudah dihapus pemiliknya, dan tidak ada error di log.

Indeks pencarian hampir selalu salinan turunan dari sumber kebenaran lain. Pekerjaan utamanya menjaga salinan itu tetap benar dalam batas waktu yang dinyatakan.

Mekanisme

1. Alur ingestion.

sumber (basis data / crawler)
  -> log perubahan (outbox, CDC, atau antrean)
  -> analyzer (tokenisasi, normalisasi)
  -> penulis indeks (batch)
  -> segmen baru yang bisa dicari

Letakkan log durabel di tengah. Kalau penulis indeks mati, kamu bisa melanjutkan dari offset terakhir, bukan menebak apa yang terlewat.

2. Upsert idempoten dengan versi. Kunci tiap dokumen dengan ID stabil. Sertakan versi dari sumber (nomor versi atau updated_at) pada tiap event. Aturannya: terapkan hanya jika versi event lebih besar dari versi yang sudah ada di indeks. Dengan begitu pemrosesan ulang dan event yang datang terlambat nggak merusak data.

3. Penghapusan. Segmen indeks bersifat immutable. Dokumen yang dihapus ditandai di bitmap "dihapus" dan baru benar-benar hilang saat segmen digabung (merge). Pembaruan sama dengan hapus ditambah sisip. Konsekuensinya:

• Dokumen yang dihapus tetap memakan ruang sampai merge berikutnya.
• Ia nggak boleh muncul di hasil, jadi filter bitmap diterapkan saat query.
• Hapus harus ikut versi juga. Simpan nisan (tombstone) beserta versinya selama jendela keterlambatan terpanjang, supaya event edit yang telat nggak menghidupkan lagi dokumen itu.

4. Kesegaran sebagai target. Dokumen baru terlihat setelah segmen di-refresh. Interval umum 1 detik membuat hasil terasa segera, tapi menambah banyak segmen kecil yang harus digabung. Menaikkan interval ke 30 detik menurunkan beban indeks. Nyatakan sebagai target: "99% perubahan muncul di pencarian dalam 60 detik", lalu ukur selisih waktu antara commit di sumber dan terlihat di indeks.

5. Backfill dan reindex. Mengubah analyzer atau skema berarti membangun indeks baru.

1. Buat indeks baru (v2) dan isi dari snapshot sumber, sambil menyimpan offset log saat snapshot diambil.
2. Putar ulang (replay) log dari offset itu supaya v2 menyusul.
3. Bandingkan jumlah dan sampel dokumen di v1 dan v2.
4. Pindahkan alias pencarian dari v1 ke v2. Simpan v1 sampai v2 terbukti sehat.

Replay hanya mungkin kalau log dipertahankan cukup lama. Retensi log harus lebih panjang dari waktu backfill terpanjang ditambah margin.

6. Batas crawling. Kalau sumber adalah web, sumber daya perlu dibatasi.

• Patuhi robots.txt dan batasi 1 request per detik per host (kesopanan).
• Kanonikalisasi URL (buang parameter pelacakan, samakan huruf host) lalu deduplikasi.
• Batasi kedalaman dan jumlah URL per host untuk menghindari jebakan crawler (kalender tak berujung).

Hitung kapasitasnya: 100 juta halaman dalam 30 hari butuh 100.000.000 / 2.592.000 detik ≈ 39 halaman per detik. Tapi satu situs dengan 5 juta halaman pada 1 request per detik butuh 5.000.000 / 86.400 ≈ 58 hari. Jadi batas utamanya adalah kesopanan per host, bukan kapasitas crawler.

Saat rancangan ini gagal

• Event tertukar. Edit tiba setelah hapus tanpa versi, dan dokumen terhapus kembali muncul. Nisan dan pengecekan versi mencegahnya.
• Indeks berjalan, sumber berubah. Tanpa log, backfill melewatkan perubahan yang terjadi selama snapshot. Selalu catat offset sebelum snapshot.
• Menghapus data sensitif. Penghapusan di indeks baru efektif setelah merge. Kalau ada kewajiban menghilangkan data, definisikan batas waktu dan paksa merge atau reindex.
• Poison document. Satu dokumen yang gagal dianalisis memblokir seluruh antrean. Pindahkan ke antrean surat mati (dead letter) setelah beberapa percobaan dan beri peringatan.
• Crawler terjebak. URL dengan parameter acak menghasilkan halaman tak terbatas. Batasi per host dan deteksi pola.

Contoh tandingan: tabel 50.000 baris yang berubah beberapa kali sehari. Reindex penuh tiap 10 menit cukup, tanpa log perubahan, versi, atau nisan. Kerumitan pipeline hanya sepadan kalau data besar atau perubahannya sering.

Latihan

Kamu menerima event berikut untuk dokumen r-77 dalam urutan tiba ini:

1. upsert r-77 versi 5
2. hapus r-77 versi 7
3. upsert r-77 versi 6
4. upsert r-77 versi 5 (diputar ulang)

Indeks awalnya kosong. Tunjukkan keadaan indeks setelah tiap event dan apa yang harus disimpan supaya hasil akhirnya benar.

Lihat pembahasan+

| Event | Aturan | Keadaan setelahnya | | ----- | ------------------------------------ | -------------------------------- | | 1 | belum ada, terapkan | dokumen versi 5 aktif | | 2 | versi 7 lebih besar dari 5, hapus | nisan versi 7, dokumen tersembunyi | | 3 | versi 6 lebih kecil dari 7, abaikan | tetap nisan versi 7 | | 4 | versi 5 lebih kecil dari 7, abaikan | tetap nisan versi 7 |

Hasil akhir: dokumen r-77 nggak muncul di hasil, sesuai sumber. Tanpa nisan versi 7, event 3 akan menghidupkan lagi dokumen itu.

Nisan harus disimpan selama jendela keterlambatan terpanjang, misalnya 7 hari kalau log punya retensi 7 hari. Setelah itu aman dibuang, dengan asumsi nggak ada event lama yang bisa muncul lagi.

Terkait

• Sebelumnya: M11.03 Dukung pengalaman pencarian.
• Lanjut ke M11.05 Skalakan eksekusi query.
• Antrean, retry, dan dead letter berasal dari M10. Outbox transaksional dibahas di M05.
• Rancangan D11 (web crawler dan pipeline pengindeksan) memakai alur ini. Belum tersedia.

Catatan

• Asumsi: ada sumber kebenaran lain, dan indeks bisa dibangun ulang dari sumber itu.
• Yang nggak dibahas: crawler terdistribusi sepenuhnya, deteksi duplikat dekat (simhash), dan rendering JavaScript.
• Interval refresh dan angka crawling adalah contoh perhitungan, bukan rekomendasi universal.
• Terakhir ditinjau: 26 Oktober 2026.