Optimasi Indeks Berdasarkan Skema Data Rtp
Optimasi indeks berdasarkan skema data RTP (Real-Time Processing) adalah pendekatan pengindeksan yang dirancang agar kueri tetap cepat saat data mengalir tanpa henti. Berbeda dari sistem batch, beban kerja RTP menuntut indeks yang adaptif: insert tinggi, update sering, dan query analitik maupun operasional berjalan bersamaan. Karena itu, strategi indeks tidak bisa sekadar “buat index di kolom yang sering dipakai”, melainkan harus mengikuti bentuk skema data, pola akses, serta umur data (hot–warm–cold) yang khas pada arsitektur real-time.
Memahami skema data RTP dan pola aksesnya
Skema RTP umumnya berpusat pada event: setiap baris mewakili kejadian dengan atribut seperti event_time, entity_id, event_type, dan payload terstruktur (JSON/kolom lebar). Pola akses yang sering muncul adalah kueri “rentang waktu + identitas”, misalnya mengambil event 15 menit terakhir untuk satu perangkat, atau agregasi per tipe event per jam. Ada juga kueri inspeksi cepat: mencari event tertentu berdasarkan correlation id. Dari sini, indeks harus melayani dua kebutuhan: filter selektif (entity atau id) dan pemotongan rentang waktu (time slicing) tanpa membuat penulisan data melambat.
Skema indeks “berlapis tiga” yang tidak biasa
Alih-alih mengandalkan satu indeks besar, gunakan skema indeks berlapis tiga: (1) indeks penunjuk waktu untuk memotong rentang, (2) indeks identitas komposit untuk kueri spesifik entitas, dan (3) indeks ringkas untuk pencarian cepat pada atribut tertentu. Lapisan ini bukan tiga indeks di semua tabel, melainkan tiga peran yang bisa diaktifkan sesuai tabel dan SLA. Contoh: tabel event utama cukup punya indeks (event_time, entity_id) untuk query harian, sementara tabel “lookup korelasi” yang lebih kecil punya indeks unik di correlation_id. Pendekatan ini terasa tidak biasa karena memisahkan fungsi indeks ke tabel/ruang yang berbeda, bukan menjejalkan semua kebutuhan ke satu indeks multikolom yang mahal.
Urutan kolom indeks mengikuti “selektivitas dinamis”
Dalam RTP, selektivitas kolom bisa berubah mengikuti jam sibuk. Pada jam tertentu, event_type mungkin homogen sehingga indeks (event_type, event_time) jadi tidak efektif. Lebih aman memakai urutan kolom yang stabil: letakkan kolom yang paling sering digunakan untuk membatasi data terlebih dahulu, lalu waktu. Untuk kueri “event untuk entity_id pada rentang waktu”, indeks (entity_id, event_time) biasanya menang. Untuk kueri “rentang waktu global”, indeks (event_time) atau partisi waktu lebih tepat. Prinsip praktisnya: jangan membuat indeks komposit panjang jika dua kolom pertama sudah cukup mengerucutkan hasil.
Partisi waktu sebagai “indeks makro”
Partisi berdasarkan waktu (harian/jam) bertindak seperti indeks makro yang mengurangi jumlah data yang disentuh. Ini sangat cocok untuk RTP karena data lama jarang diakses, namun tetap perlu disimpan. Dengan partisi, kueri 15 menit terakhir hanya membaca partisi terbaru, dan operasi housekeeping seperti drop partisi lama jauh lebih cepat daripada delete berjuta baris. Di banyak kasus, partisi mengurangi kebutuhan indeks berat karena pruning partisi sudah menghemat I/O secara signifikan.
Indeks parsial untuk data “panas” dan status tertentu
Indeks parsial adalah cara cerdas untuk RTP: Anda hanya mengindeks subset data yang sering dipakai. Misalnya, indeks untuk event berstatus “active” atau untuk window waktu tertentu (jika didukung), sehingga ukuran indeks kecil dan insert lebih ringan. Ini cocok untuk skema yang memiliki kolom status, severity, atau flag validasi. Strategi ini juga membantu menghindari indeks yang membengkak akibat event lama yang jarang dipanggil.
Materialisasi ringkas: tabel bayangan untuk query cepat
Jika skema event terlalu lebar (payload besar), indeks di tabel utama bisa mahal. Buat tabel bayangan yang “kurus”: hanya berisi event_id, event_time, entity_id, event_type, dan beberapa kolom filter utama. Tabel ini diisi melalui pipeline streaming atau trigger ringan, lalu diberi indeks agresif. Saat kueri butuh payload lengkap, lakukan join ke tabel utama berdasarkan event_id. Pola ini tidak umum karena terasa seperti duplikasi, namun dalam RTP sering lebih stabil: indeks tetap kecil, cache lebih efektif, dan latensi query menurun.
Perawatan indeks: statistik, bloat, dan batas jumlah indeks
Optimasi bukan hanya desain awal. Perbarui statistik secara terjadwal agar planner tidak salah pilih rencana eksekusi. Pantau bloat pada indeks akibat update dan vacuum yang tertinggal. Batasi jumlah indeks: setiap indeks menambah biaya write. Ukur dengan metrik nyata seperti p95 latency query dan throughput ingest, lalu buang indeks yang jarang dipakai. Untuk validasi, gunakan EXPLAIN dan log slow query agar perubahan indeks benar-benar mengikuti skema RTP, bukan asumsi.
Home
Bookmark
Bagikan
About
Chat
