Sharding #

Seiring pertumbuhan aplikasi, database sering menjadi bottleneck utama: query makin lambat, storage membengkak, dan beban write/read sulit ditangani oleh satu mesin. Di titik inilah sharding (dan sering disandingkan dengan partitioning) menjadi strategi penting dalam arsitektur database modern.

Artikel ini membahas:

• Apa itu sharding dan bagaimana konsep kerjanya
• Perbedaan sharding vs partitioning
• Mengapa sharding itu penting
• Kapan sharding benar-benar dibutuhkan
• Best practice memanfaatkan sharding/partitioning secara aman dan efektif

Apa Itu Sharding? #

Sharding adalah teknik membagi data ke beberapa database atau node fisik yang berbeda berdasarkan suatu aturan (shard key). Setiap shard menyimpan subset data yang saling eksklusif.

Contoh sederhana:

• User ID 1–1.000.000 → Shard A
• User ID 1.000.001–2.000.000 → Shard B

Dari sudut pandang aplikasi, data terlihat seperti satu logical database, tetapi secara fisik tersebar ke banyak server.

Karakteristik utama sharding:

• Horizontal scaling (scale-out, bukan scale-up)
• Setiap shard berdiri sendiri (CPU, RAM, disk terpisah)
• Beban query terbagi ke banyak node

Sharding vs Partitioning (Penting untuk Diluruskan) #

Istilah ini sering tertukar, padahal levelnya berbeda.

Partitioning #

• Terjadi di dalam satu database instance
• Data dibagi ke beberapa partisi (range, hash, list)
• Masih menggunakan satu server

Contoh:

• Tabel orders dipartisi per bulan

Sharding #

• Terjadi di level infrastruktur
• Data dibagi ke beberapa database/server
• Setiap shard punya schema yang sama

Ringkasnya:

• Partitioning → optimasi internal database
• Sharding → distribusi data lintas server

Dalam praktik besar, partitioning sering dipakai di dalam setiap shard.

Mengapa Sharding Itu Penting? #

Batas Fisik Satu Database #

Single database punya limit:

• CPU
• RAM
• IOPS disk

Ketika scale-up tidak lagi cukup atau terlalu mahal, sharding jadi satu-satunya jalan.

Beban Query yang Tidak Terdistribusi #

Tanpa sharding:

• Semua read/write menumpuk di satu node
• Lock contention meningkat
• Latency naik drastis saat peak traffic

Dengan sharding:

• Beban terbagi secara horizontal
• Query pada shard A tidak mengganggu shard B

Ukuran Data Terlalu Besar #

Dataset puluhan atau ratusan TB:

• Backup makin lama
• Restore berisiko
• Index rebuild mahal

Sharding membuat:

• Backup per shard lebih kecil
• Recovery lebih terkontrol

Kapan Sharding Dibutuhkan? #

Sharding bukan solusi default. Ini kompleks dan mahal secara operasional.

Sharding mulai masuk akal ketika:

Data Growth Tidak Terbendung #

• Data terus bertambah
• Archive/partitioning sudah mentok

Write Throughput Tinggi #

• Banyak insert/update paralel
• Single primary DB tidak sanggup

Akses Data Bisa Dipisah Secara Natural #

Contoh ideal:

• User-based system (user_id)
• Multi-tenant SaaS (tenant_id)
• Regional data (region_id)

Jika query sering membutuhkan join lintas shard → red flag.

Strategi Sharding yang Umum #

Range-based Sharding #

Shard ditentukan oleh rentang nilai.

Contoh:

• user_id 1–1jt → shard_1
• user_id 1jt–2jt → shard_2

Pro:

• Mudah dipahami

Con:

• Hot shard (data terbaru sering menumpuk di satu shard)

Hash-based Sharding #

Shard ditentukan oleh hash key.

Contoh:

• hash(user_id) % N

Pro:

• Distribusi data merata

Con:

• Sulit melakukan resharding

Directory-based Sharding #

Mapping shard disimpan di tabel metadata.

Pro:

• Fleksibel

Con:

• Tambahan lookup
• Single point of failure jika metadata tidak dirancang dengan baik

Best Practice Sharding & Partitioning #

Pilih Shard Key dengan Sangat Hati-hati #

Shard key yang buruk = bencana.

Kriteria shard key yang baik:

• Cardinality tinggi
• Distribusi merata
• Selalu ada di query

Hindari:

• Timestamp murni
• Status flag

Minimalkan Query Lintas Shard #

Cross-shard query:

• Mahal
• Sulit diskalakan
• Sulit di-cache

Best practice:

• Denormalisasi jika perlu
• Query selalu berbasis shard key

Gunakan Partitioning di Dalam Shard #

Setiap shard tetap bisa:

• Partition by date
• Partition by range

Manfaat:

• Index lebih kecil
• Maintenance lebih cepat

Siapkan Strategy Resharding Sejak Awal #

Pertanyaan penting:

• Bagaimana jika shard penuh?
• Bagaimana menambah shard baru?

Best practice:

• Jangan hardcode jumlah shard
• Gunakan abstraction layer di aplikasi

Jangan Sharding Terlalu Dini #

Premature sharding:

• Complexity naik
• Debugging sulit
• Developer velocity turun

Mulai dari:

1. Indexing yang benar
2. Query optimization
3. Partitioning
4. Baru sharding

Observability adalah Wajib #

Pantau per shard:

• QPS
• Latency
• Disk usage
• Lock contention

Tanpa observability, sharding hanya memindahkan masalah.

Kesimpulan #

Sharding adalah solusi powerful tapi berbahaya jika digunakan tanpa kebutuhan nyata.

Ringkasnya:

• Gunakan sharding saat scale-up dan optimasi internal sudah mentok
• Pilih shard key dengan sangat serius
• Kombinasikan dengan partitioning di level shard
• Selalu siapkan plan untuk masa depan

Sharding bukan tentang membuat sistem lebih cepat hari ini, tapi memastikan sistem tetap hidup saat skala membesar.