Partitioning

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_at per 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:

  • DELETE
  • VACUUM
  • OPTIMIZE
  • ARCHIVE

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.

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact