Belajar MongoDB - Sharding (Horizontal Scalability)

#Pendahuluan

Replica set di episode 15 menjamin high availability dan read scaling. Tapi ada batas yang tidak bisa ditembus: storage dan write throughput masih terbatas oleh satu primary. Jika dataset mencapai terabyte dan tulisannya ratusan ribu per detik, tidak peduli seberapa besar server yang kalian beli — satu server fisik akan kewalahan. Jawabannya adalah sharding: memecah data ke banyak server secara horizontal.

Episode 16 mengajarkan cara berpikir skala horizontal. Roadmap-nya: pertama kita tentukan kapan sharding benar-benar dibutuhkan, kedua kita bedah arsitektur sharded cluster — shard, config servers, dan mongos, ketiga kita pahami shard key, dan keempat kita bandingkan ranged versus hashed sharding. Mari mulai.

#Kapan Membutuhkan Sharding?

Sharding menambah kompleksitas infrastruktur — jadi jangan dipakai sebelum benar-benar dibutuhkan. Dua sinyal jelas bahwa saatnya tiba:

Dataset terlalu besar untuk satu server — dalam ukuran terabyte ke atas, di mana storage satu mesin tidak muat atau mahal tidak wajar.
Write throughput melebihi kapasitas satu replica set — single primary hanya bisa memproses sejumlah tulis tertentu; jika limit ini tercapai dan storage masih adem, sharding memungkinkan banyak primary (satu per shard) menulis secara paralel.

Selain itu, ada indikator pendukung: working set (data yang sering diakses) mulai melebihi RAM server, dan query semakin lambat meski sudah di-index dengan baik. Jika sinyal di atas belum muncul, replica set yang diperbesar lebih sederhana dan lebih murah — sharding adalah keputusan arsitektur besar, bukan penyetelan sepele.

#Arsitektur Sharded Cluster

Sharded cluster memiliki tiga komponen dengan peran yang sangat berbeda:

Komponen	Peran
Shard	Setiap shard adalah replica set yang menyimpan subset data. Menambah shard berarti menambah kapasitas storage dan write.
Config Servers	Replica set khusus yang menyimpan metadata dan routing — informasi tentang di shard mana sebuah data berada.
mongos	Query router. Menerima query dari aplikasi, berkonsultasi ke config servers, lalu mengarahkan query ke shard yang tepat dan menggabungkan hasil.

Alur query di sharded cluster

App ---> mongos ---> config servers (metadata)
                |
                +--> shard A (subset data)
                +--> shard B (subset data)
                +--> shard C (subset data)

Poin penting: aplikasi tidak pernah berbicara langsung ke shard. Aplikasi hanya berkomunikasi dengan mongos — yang tampak seperti mongod biasa — dan mongos mengurus sisanya. Ini menjaga pengalaman aplikasi tetap sederhana meski di belakangnya ada puluhan server.

#Chunk dan Balancer

Data dalam collection ter-shard dipecah menjadi chunk — rentang data kontinu berdasarkan shard key. Chunk-chunk ini tersebar di antara shard. Saat satu shard kewalahan dan shard lain menganggur, balancer (proses latar belakang) memindahkan chunk untuk meratakan beban secara otomatis. Inilah yang membuat sharded cluster "menyembuhkan" distribusi datanya sendiri.

#Shard Key

#Konsep Shard Key

Shard key adalah field (atau kombinasi field) yang menentukan bagaimana dokumen didistribusikan antar shard. MongoDB membagi rentang nilai shard key menjadi chunk, dan menempatkan setiap chunk di satu shard. Pilihan shard key adalah keputusan paling penting dan paling sulit diubah di sharded cluster — pilih sebelum collection membesar, karena mengubah shard key setelah data tersebar sangat rumit.

#Ciri Shard Key yang Baik

Shard key yang baik memiliki tiga sifat:

High cardinality — nilai yang sangat beragam. Jika hanya ada dua nilai berbeda (misal true/false), data hanya tersebar ke dua shard — sisanya menganggur.
Low frequency — tidak ada nilai yang mendominasi. Shard key dengan satu nilai sangat populer membuat satu shard menerima beban tak seimbang (hot shard).
Non-monotonically increasing — nilainya tidak naik terus menerus. Shard key seperti createdAt atau auto-increment akan selalu mengarahkan write baru ke satu shard terakhir — memusatkan beban dan menggagalkan distribusi.

Contoh shard key yang baik: kombinasi { customerId: 1, orderDate: 1 } di collection orders — customerId punya banyak nilai unik, tidak ada yang mendominasi, dan distribusi waktu tersebar.

#Ranged Sharding vs Hashed Sharding

#Ranged Sharding

Ranged sharding memecah data berdasarkan rentang nilai shard key. Query yang menyaring range nilai tertentu bisa diarahkan tepat ke shard yang memegang rentang itu — sangat efisien untuk query range dan operasi yang mengelompokkan nilai berdekatan.

Mengaktifkan ranged sharding

sh.enableSharding("app")
sh.shardCollection("app.orders", { customerId: 1 })

Kelemahan utamanya: jika shard key monotonik naik, semua write baru menumpuk di satu shard (hot spot). Ranged sharding paling cocok saat shard key tersebar merata alami.

#Hashed Sharding

Hashed sharding menghitung hash dari nilai shard key lalu membaginya merata ke chunk. Hash memastikan nilai berurutan tersebar ke chunk berbeda — menghilangkan masalah hot spot secara drastis, termasuk pada shard key yang monotonik naik.

Mengaktifkan hashed sharding

sh.enableSharding("app")
sh.shardCollection("app.events", { deviceId: "hashed" })

Konsekuensinya: query range tidak efisien — karena nilai berurutan tersebar acak, query range harus menjangkau banyak shard. Hashed sharding ideal untuk workload write-heavy dan query lookup point (berdasarkan nilai tunggal), seperti event log yang diakses per device.

#Menyiapkan Sharded Cluster Secara Praktis

Untuk memahami cara kerja sharded cluster, tidak ada guru yang lebih baik daripada praktik langsung. Bayangkan kita membangun cluster minimal: satu mongos, satu config server, dan dua shard. Pertama, mulai config server sebagai replica set satu anggota:

Menjalankan config server

mongod --configsvr --replSet cfgrs --dbpath /data/configdb --port 27019

Config server wajib dijalankan dengan flag --configsvr dan sebagai replica set. Setelah itu, mulai dua shard — masing-masing replica set satu anggota yang sederhana:

Menjalankan dua shard

mongod --shardsvr --replSet rs1 --dbpath /data/shard1 --port 27017
mongod --shardsvr --replSet rs2 --dbpath /data/shard2 --port 27018

Terakhir, mulai mongos sebagai pintu masuk aplikasi:

Menjalankan mongos query router

mongos --configdb cfgrs/localhost:27019 --port 27017

Kemudian daftarkan kedua shard ke cluster lewat mongos:

Menambahkan shard ke cluster

mongosh "mongodb://localhost:27017"
 
sh.addShard("rs1/localhost:27017")
sh.addShard("rs2/localhost:27018")
 
sh.status()

sh.status() menampilkan peta lengkap cluster: shard yang terdaftar, database yang di-shard, dan distribusi chunk. Inilah titik verifikasi bahwa cluster kalian sehat sebelum lalu lintas masuk.

Warning

Setelah collection di-shard, shard key tidak bisa diubah. Jika desain shard key salah — contoh klasiknya memilih createdAt yang monotonik — kalian akan terjebak dengan hot shard selamanya atau harus migrasi data besar-besaran. Habiskan waktu menganalisis access pattern sebelum memilih. Satu-satunya jalan keluar yang wajar adalah membangun ulang collection dari awal di cluster baru.

Info

Aturan praktis: hashed sharding untuk workload tulis massal dan lookup point (events, logs, sessions); ranged sharding untuk workload yang memakai query rentang per grup alami (orders per customer dalam rentang waktu). Saat ragu di collection write-heavy dengan shard key monotonik, hashed hampir selalu pilihan aman.

#Penutup

Pada episode 16 ini kalian telah memahami sharding sebagai jalan menuju skala horizontal: memecah dataset terabyte dan write throughput yang melampaui kapasitas satu replica set. Kalian mengenal arsitektur sharded cluster — shard yang menyimpan subset data, config servers yang menyimpan metadata routing, dan mongos sebagai query router — beserta mekanisme chunk dan balancer yang meratakan beban otomatis. Terakhir, kalian menguasai pemilihan shard key yang ideal (high cardinality, low frequency, non-monotonic) dan perbedaan ranged versus hashed sharding.

Inti yang harus dibawa pulang:

Sharding untuk dataset terabyte atau write throughput melebihi satu replica set.
Shard menyimpan data, config servers menyimpan metadata, mongos merutekan query.
Shard key yang baik: cardinality tinggi, frekuensi rendah, dan tidak monotonik naik.
Ranged cocok untuk query range; hashed menghilangkan hot spot untuk write massal.
Shard key tidak bisa diubah — pilih dengan sangat hati-hati.

Di episode 17 berikutnya kita mengamankan semuanya: Security: Authentication, Authorization & Encryption. Kalian akan mengaktifkan autentikasi SCRAM, membangun RBAC dengan built-in roles dan custom roles, lalu memahami encryption at rest, TLS untuk encryption in transit, dan client-side field level encryption untuk field sensitif. Sampai jumpa di episode 17!