Bedakan pemerataan key dari pemerataan beban

Pertanyaan

Kalau key sudah tersebar rata di semua partisi, kenapa satu partisi masih bisa kewalahan sementara yang lain menganggur?

Setelah baca ini, kamu bisa mengukur ketimpangan beban per partisi, membedakan hot key, hot tenant, dan value besar, lalu memilih mitigasi sesuai penyebabnya.

Prasyarat dan contoh

Kamu sudah memilih partition key (M07.01) dan paham pencarian pemilik di ring (M07.02).

Cluster 8 partisi menyimpan 80 juta key, tepat 10 juta per partisi. Sebaran key sempurna. Tapi dasbor menunjukkan partisi 5 selalu di 95% CPU, sedangkan lainnya di 30%. Di partisi 5 ada satu key: profil seorang selebritas dengan 6.000 pembacaan per detik. Distribusi key rata, distribusi request nggak.

Hash hanya menyebar key. Ia nggak tahu seberapa sering sebuah key diakses atau seberapa besar value-nya.

Mekanisme

Ada tiga sumber ketimpangan, dan ketiganya butuh ukuran berbeda.

1. Hot key. Satu key menerima porsi besar request. Ukur: request per detik per key (sampling atau hitung top-k), lalu bandingkan dengan kapasitas satu partisi. Kalau satu key 6.000 rps sedangkan partisi mampu 5.000 rps, penambahan node nggak membantu: key itu tetap di satu partisi.

2. Hot tenant. Aplikasi multi-tenant dengan partisi tenant_id menaruh semua data satu tenant di satu partisi. Tenant yang besar memonopoli partisi itu. Ukur: bagian traffic dan bytes per tenant, bukan rata-rata. Kalau tenant terbesar memegang 40% traffic dari 8 partisi, satu partisi menanggung 40% tersebut, atau 3,2 kali beban rata-rata 12,5%.

3. Ukuran value tidak merata. Jumlah key sama, tapi satu partisi menyimpan banyak value besar (misalnya dokumen 5 MB) sehingga disk dan bandwidth-nya penuh duluan. Ukur: bytes per partisi dan bytes keluar per detik, bukan hanya jumlah key.

Ukuran ringkas untuk ketimpangan: rasio puncak terhadap rata-rata = beban partisi terpanas / rata-rata beban semua partisi. Rasio 1,1 sehat. Rasio 3 berarti kamu membayar kapasitas 3 kali lipat untuk melayani beban yang sama.

Mitigasi mengikuti penyebab:

• Hot key baca: cache di depan partisi, atau replika baca untuk key itu.
• Hot key tulis: pecah key jadi beberapa sub-key dengan sufiks (key#0 sampai key#7). Tulis ke sub-key acak, baca dengan menggabungkan semua sub-key.
• Hot tenant: beri tenant besar partisi khusus, atau partisi dengan (tenant_id, hash(entity_id)) supaya satu tenant tersebar.
• Value besar: simpan blob besar di object storage dan taruh referensinya di partisi, atau seimbangkan berdasarkan bytes, bukan jumlah key.

Saat rancangan ini gagal

• Mengukur jumlah key saja. Dasbor menunjukkan partisi seimbang, padahal tidak ada metrik request atau bytes per partisi.
• Rata-rata menyembunyikan puncak. Beban rata-rata 40% tampak aman, padahal partisi terpanas di 98% dan satu lonjakan menjatuhkannya.
• Memecah terlalu awal. Semua key diberi sub-key "just in case", sehingga setiap baca jadi 8 request dan beban baca naik 8 kali untuk key yang sebenarnya dingin.
• Hot key bergeser. Key panas hari ini berbeda dari besok (berita, produk viral). Daftar key yang dipecah secara manual cepat basi, jadi butuh deteksi otomatis atau kebijakan kedaluwarsa.
• Mitigasi membuat jaminan hilang. Cache untuk hot key bisa basi, dan sub-key menyulitkan operasi atomik di satu key. Tulis konsekuensinya.

Latihan

Cluster 8 partisi, tiap partisi mampu 6.000 rps. Beban puncak: 28.000 rps tersebar merata di key biasa (3.500 rps per partisi), ditambah satu key promo dengan 12.000 rps tulis.

1. Berapa beban partisi yang memegang key promo, dan berapa rasio puncak terhadap rata-rata?
2. Pecah key itu jadi 8 sub-key. Berapa beban terburuk dan terbaik per partisi?
3. Apa harga yang kamu bayar?

Lihat pembahasan+

1. Total beban 28.000 + 12.000 = 40.000 rps, rata-rata 5.000 rps per partisi. Partisi key promo menanggung 3.500 + 12.000 = 15.500 rps, jauh di atas kapasitas 6.000. Rasio puncak terhadap rata-rata = 15.500 / 5.000 = 3,1. Nambah node nggak menolong karena key itu tetap satu.
2. Tiap sub-key membawa 12.000 / 8 = 1.500 rps. Kalau tiap sub-key jatuh di partisi berbeda: 3.500 + 1.500 = 5.000 rps per partisi, di bawah 6.000. Kalau hash menaruh dua sub-key di satu partisi (itu sangat mungkin dengan hash acak): 3.500 + 3.000 = 6.500 rps, tepat melewati kapasitas. Jadi 8 sub-key belum cukup aman. 16 sub-key (750 rps masing-masing) dengan paling banyak dua di satu partisi memberi 3.500 + 1.500 = 5.000 rps.
3. Harga: pembacaan nilai total promo harus membaca semua sub-key (8 atau 16 request), nilai total bersifat sedikit tertinggal, dan operasi atomik "kurangi stok jika masih ada" nggak bisa lagi dilakukan atas satu key. Kamu harus merancang jatah per sub-key atau pemeriksaan stok terpisah.

Perhatikan pelajaran dari poin 2: jumlah sub-key ditentukan oleh headroom setelah tabrakan, bukan oleh pembagian rata murni.

Terkait

• Sebelumnya: M07.02 Bangun hash ring.
• Lanjut ke M07.04 Rutekan request. Pembacaan sub-key dan hot tenant memengaruhi cara penempatan dicari.
• Query yang butuh banyak partisi dibahas di M07.06 Rancang akses lintas partisi.
• Cache dan counter terdistribusi (M06 dan M12) belum tersedia sebagai lesson. Lab L07 (hot key) belum tersedia.

Catatan

• Asumsi: kapasitas 6.000 rps per partisi adalah angka ilustrasi, dan beban tersebar seragam di luar key promo.
• Yang nggak dibahas: algoritma deteksi hot key (count-min sketch, M12), penyeimbangan otomatis, dan pembatasan laju per tenant.
• Pemecahan key adalah teknik umum di aplikasi, bukan fitur yang selalu disediakan database.
• Terakhir ditinjau: 26 Oktober 2026.