Partitioning #
Seiring pertumbuhan data, banyak sistem mulai merasakan query melambat, maintenance makin berat, dan operasi sederhana terasa mahal. Salah satu teknik yang sering disebut sebagai solusi adalah database partitioning.
Namun partitioning bukanlah silver bullet. Jika digunakan tanpa pemahaman yang tepat, justru bisa menambah kompleksitas, membuat query lebih mahal, dan menyulitkan operasional.
Artikel ini membahas secara mendalam:
- Apa itu partitioning
- Mengapa partitioning penting
- Kapan partitioning benar-benar dibutuhkan
- Jenis-jenis partitioning
- Best practice memanfaatkan partitioning secara efektif
- Kesalahan umum dalam implementasi
Apa Itu Database Partitioning? #
Partitioning adalah teknik membagi satu tabel logis menjadi beberapa bagian fisik (partition) berdasarkan aturan tertentu.
Dari sudut pandang aplikasi:
- Tetap terlihat sebagai 1 tabel
Dari sudut pandang database:
- Data disimpan di segmen-segmen terpisah
Contoh sederhana:
- Tabel
orders - Dipartisi berdasarkan
created_atper bulan
orders_2024_01
orders_2024_02
orders_2024_03
Namun aplikasi tetap melakukan:
SELECT * FROM orders WHERE created_at >= '2024-02-01'
Database yang akan menentukan partition mana saja yang perlu dibaca.
Mengapa Partitioning Itu Penting? #
Mengurangi Data yang Harus Dipindai #
Tanpa partitioning:
- Query harus memindai seluruh tabel
Dengan partitioning:
- Database hanya membaca partition relevan (partition pruning)
Dampak langsung:
- I/O lebih kecil
- Cache lebih efektif
- Query lebih cepat
Meningkatkan Performansi Query Skala Besar #
Partitioning sangat membantu untuk:
- Tabel ratusan juta hingga miliaran row
- Query dengan filter yang konsisten (misal waktu, region, tenant)
Tanpa partitioning:
- Index besar
- Query planner bekerja lebih berat
Dengan partitioning:
- Index lebih kecil per partition
- Query planner lebih efisien
Maintenance Jauh Lebih Murah #
Operasi mahal seperti:
DELETEVACUUMOPTIMIZEARCHIVE
Menjadi jauh lebih ringan dengan partitioning:
Contoh:
- Menghapus data 1 tahun lalu
Tanpa partitioning:
DELETE FROM orders WHERE created_at < '2023-01-01'
- Lock lama
- WAL besar
- Fragmentasi
Dengan partitioning:
DROP PARTITION orders_2023_01
- O(1)
- Hampir tanpa overhead
Isolasi Beban dan Hot Data #
Partitioning membantu memisahkan:
- Hot data (data terbaru, sering diakses)
- Cold data (data lama, jarang diakses)
Manfaat:
- Cache fokus ke hot partition
- Query operasional tidak terganggu data historis
Kapan Partitioning Benar-Benar Dibutuhkan? #
Partitioning bukan default choice. Ia dibutuhkan jika kondisi berikut terpenuhi:
Kapan Partitioning Tepat #
- Tabel tumbuh sangat besar (jutaan → miliaran row)
- Query hampir selalu punya filter tertentu (tanggal, tenant, region)
- Data bersifat time-series atau append-only
- Retensi data jelas (misal simpan 1–3 tahun)
- Maintenance mulai menjadi bottleneck
Kapan Partitioning Tidak Tepat #
- Tabel kecil atau sedang
- Query sering full scan tanpa filter
- Pola akses data tidak konsisten
- Tim belum siap dengan kompleksitas operasional
⚠️ Premature partitioning sering lebih berbahaya daripada tidak partitioning sama sekali.
Jenis-Jenis Partitioning #
Range Partitioning #
Paling umum dan paling aman.
Contoh:
- Berdasarkan tanggal
- Berdasarkan angka ID
PARTITION BY RANGE (created_at)
Kelebihan:
- Cocok untuk time-series
- Mudah pruning
Kekurangan:
- Risiko hot partition jika data tidak merata
List Partitioning #
Berdasarkan nilai diskrit.
Contoh:
- Region
- Status
PARTITION BY LIST (country)
Kelebihan:
- Sangat eksplisit
Kekurangan:
- Tidak fleksibel jika value sering bertambah
Hash Partitioning #
Berdasarkan hash function.
Contoh:
user_id
PARTITION BY HASH (user_id)
Kelebihan:
- Distribusi data merata
Kekurangan:
- Tidak bisa pruning berbasis range
- Kurang cocok untuk query time-based
Composite Partitioning #
Kombinasi beberapa strategi.
Contoh:
- Range (tanggal) + Hash (user_id)
Digunakan pada sistem berskala sangat besar.
Partition Pruning: Kunci Performa #
Partitioning tidak berguna tanpa pruning.
Partition pruning terjadi ketika:
- Query filter menggunakan kolom partition
- Filter bersifat deterministik
Contoh baik:
WHERE created_at >= '2024-01-01'
Contoh buruk:
WHERE DATE(created_at) = '2024-01-01'
Fungsi pada kolom partition sering membuat pruning gagal.
Best Practice Menggunakan Partitioning #
Pilih Partition Key Berdasarkan Query Pattern #
Bukan berdasarkan asumsi.
Tanya:
- Filter apa yang paling sering muncul?
- Apakah filter itu konsisten?
Jaga Jumlah Partition Tetap Masuk Akal #
Terlalu sedikit:
- Manfaat minim
Terlalu banyak:
- Planning query berat
- Metadata membengkak
Rule of thumb:
- Puluhan hingga ratusan partition, bukan ribuan
Gunakan Range Partition untuk Data Berbasis Waktu #
Ini adalah use case paling stabil:
- Log
- Event
- Order
- Audit trail
Pastikan Index Dibuat di Level Partition #
Index global besar sering menghilangkan manfaat partitioning.
Idealnya:
- Index per partition
- Ukuran index kecil
Automasi Lifecycle Partition #
Partitioning harus otomatis:
- Auto-create partition baru
- Auto-drop partition lama
Tanpa automasi:
- Human error
- Downtime
Jangan Jadikan Partitioning sebagai Pengganti Index #
Partitioning ≠ Index.
- Partitioning mengurangi data scope
- Index mengurangi search cost
Keduanya saling melengkapi.
Kesalahan Umum dalam Partitioning #
❌ Partitioning terlalu dini ❌ Salah memilih partition key ❌ Menggunakan fungsi di kolom partition ❌ Terlalu banyak partition kecil ❌ Tidak memikirkan query planner ❌ Tidak menyiapkan strategi migrasi
Penutup #
Partitioning adalah alat skalabilitas, bukan fitur kosmetik.
Jika digunakan dengan benar:
- Query lebih cepat
- Maintenance lebih murah
- Sistem lebih tahan skala
Jika digunakan sembarangan:
- Kompleksitas meningkat
- Bug sulit dilacak
- Performa justru menurun
Prinsip utama: pahami pola data dan query terlebih dahulu, baru tentukan apakah partitioning memang diperlukan.