Pilih partition key

Pertanyaan

Kolom mana yang sebaiknya menentukan letak sebuah baris, dan apa yang kamu korbankan dengan pilihan itu?

Setelah baca ini, kamu bisa membandingkan partisi hash dan rentang untuk satu pola akses, lalu menunjukkan query mana yang tetap murah dan mana yang jadi mahal.

Prasyarat dan contoh

Kamu sudah paham indeks dan akses data (M04), replikasi dasar (M05), dan alasan satu mesin akhirnya nggak cukup (M01). Lesson ini nggak butuh pengetahuan soal konsensus.

Bayangkan tabel orders berisi 600 juta baris, sekitar 1,2 TB. Satu node database kamu nyaman di kisaran 400 GB, dan tulisnya mentok di sekitar 3.000 per detik. Kamu perlu membaginya jadi beberapa partisi. Pertanyaannya: partisi berdasarkan apa?

Kalau kamu pilih created_at, query "pesanan 7 hari terakhir" cepat karena datanya berdekatan. Tapi semua tulisan baru jatuh di partisi paling baru, dan partisi lain nyaris menganggur. Kalau kamu pilih hash dari user_id, tulisan menyebar rata, tapi query "semua pesanan minggu ini" harus menanyai semua partisi.

Nggak ada pilihan yang gratis. Partition key adalah keputusan tentang query mana yang kamu bikin murah.

Mekanisme

Partisi rentang (range). Ruang key diurutkan lalu dipotong jadi rentang, misalnya a-f, g-m, n-z, atau tanggal per minggu. Key yang berdekatan tinggal di partisi yang sama, jadi range scan murah: satu partisi, satu pembacaan berurutan. Harganya, key yang naik monoton (timestamp, ID auto-increment) membuat semua tulisan menumpuk di ujung rentang paling baru.

Partisi hash. Kamu hitung hash(key) lalu petakan hasilnya ke partisi, misalnya hash(key) mod 8. Key yang berdekatan tersebar acak, jadi beban tulis cenderung rata. Harganya, urutan hilang: "semua pesanan dari tanggal 1 sampai 7" nggak bisa dijawab dari satu partisi.

Pilih lewat tiga pertanyaan, berurutan:

1. Query apa yang paling sering dan paling penting? Tulis dengan angka: 4.000 lookup per detik berdasarkan user_id, 20 laporan per jam berdasarkan tanggal.
2. Apakah key itu cukup beragam dan tersebar? Hitung kardinalitasnya. Key dengan 12 nilai (misalnya negara) nggak akan pernah menyebar ke 32 partisi.
3. Apakah key itu terkonsentrasi dalam waktu? Timestamp dan ID urut selalu menjadikan satu partisi sebagai ujung tombak.

Ada jalan tengah: key gabungan. Partisi dengan hash dari bagian pertama, urutkan di dalam partisi dengan bagian kedua. Key (user_id, created_at) menaruh semua pesanan satu pengguna di satu partisi, terurut waktu. Query "pesanan terbaru milik pengguna X" jadi satu range scan kecil, sementara beban antar pengguna tetap menyebar.

Soal jumlah partisi: jangan pas-pasan dengan jumlah node. Banyak sistem membuat partisi jauh lebih banyak daripada node (misalnya 256 partisi untuk 8 node), supaya perpindahan nanti bisa per partisi utuh. Itu dibahas lagi di M07.05.

Saat rancangan ini gagal

• Key monoton pada partisi rentang. Partisi created_at mingguan menerima 100% tulisan baru. Tujuh partisi lain cuma menyimpan arsip. Kapasitas total kamu sebenarnya cuma satu node.
• Kardinalitas terlalu rendah. Partisi berdasarkan status (4 nilai) atau negara (satu negara menyumbang 60% data) menghasilkan partisi yang timpang sejak hari pertama, dan jumlah partisi dibatasi oleh jumlah nilai.
• Key yang sering diubah. Kalau partition key bisa berubah (misalnya kota pengguna), baris harus pindah partisi tiap kali nilainya berubah. Pilih key yang tetap seumur baris.
• Hash menutupi masalah beban. Hash membuat key tersebar rata, bukan beban. Satu pengguna dengan 40% traffic tetap mendarat di satu partisi. Itu topik M07.03.
• Query utama ternyata bukan lewat key. Kalau 60% query mencari berdasarkan email sementara kamu partisi lewat user_id, hampir semua request jadi scatter. Itu topik M07.06.

Latihan

Sistem tiket acara: 2 juta event, 300 juta tiket. Tulisan puncak 8.000 tiket per detik saat tiket konser populer dibuka. Query dominan:

1. "Semua tiket milik pengguna X" (3.000 per detik).
2. "Sisa stok tiket untuk event Y" (2.000 per detik, 80% ke 20 event yang sedang jualan).
3. "Laporan penjualan per hari" (10 per jam).

Pilih partition key untuk tabel tickets, hash atau rentang, dan sebutkan satu query yang jadi mahal serta satu risiko beban.

Lihat pembahasan+

Contoh jawaban yang cukup:

Pilihan: hash dari user_id untuk tabel tickets. Query 1 (yang paling sering) mengenai satu partisi. Tulisan menyebar karena jumlah pengguna besar dan tiket tersebar antar pengguna.

Query yang jadi mahal: laporan penjualan per hari harus scatter ke semua partisi. Dengan 10 kali per jam dan pekerjaan yang bisa dijalankan di replika atau sebagai tabel ringkasan, ini bisa diterima.

Risiko beban: query 2 (stok per event) bukan lewat user_id. Stok sebaiknya hidup di tabel terpisah yang dipartisi dengan hash event_id. Tapi 80% query-nya ke 20 event, dan satu event konser bisa sendirian mendapat ribuan request per detik di satu partisi. Itu hot key, dan hash event_id saja nggak menyelesaikannya.

Yang salah: partisi rentang berdasarkan created_at, karena 8.000 tulisan per detik semuanya mendarat di partisi paling baru. Juga partisi berdasarkan event_id untuk tabel tiket, karena satu event populer menyedot hampir semua tulisan.

Poin utamanya: satu entitas bisa butuh dua tabel dengan dua partition key, dan keputusannya dibuat dari query yang paling sering, bukan dari satu model data tunggal.

Terkait

• Lanjut ke M07.02 Bangun hash ring untuk memetakan key ke node tanpa memindahkan hampir semua data saat node bertambah.
• M07.03 Bedakan pemerataan key dari pemerataan beban untuk hot key dan hot tenant.
• M07.06 Rancang akses lintas partisi untuk query yang tidak lewat partition key.
• Angka kebutuhan di atas mengikuti cara hitung di M01.03 Hitung kebutuhan server.
• Indeks dan akses data (M04) serta replikasi dasar (M05) belum tersedia sebagai lesson. Lab L07 dan proyek B04 juga belum tersedia.

Catatan

• Asumsi: kapasitas satu node (400 GB, 3.000 tulis per detik) adalah angka ilustrasi, bukan ukuran produk tertentu.
• Yang nggak dibahas: pemetaan key ke node secara detail (M07.02), migrasi (M07.05), dan transaksi lintas partisi.
• Hash dan rentang adalah dua ujung spektrum. Banyak sistem menyediakan keduanya atau gabungan keduanya, dan istilahnya berbeda antar produk.
• Terakhir ditinjau: 26 Oktober 2026.