Bayangkan toko buku latihan kita tumbuh menjadi platform nasional: jutaan pelanggan, ratusan juta ulasan, dan arus tulis yang terus menanjak. Pada titik tertentu, satu server MongoDB — sekuat apa pun spesifikasinya — menyentuh batas: kapasitas disk yang terpasang penuh, working set yang tidak lagi muat di RAM, atau throughput tulis yang jenuh pada satu mesin. Sharding adalah jawaban MongoDB untuk masalah itu: membagi data satu collection ke banyak server agar beban dapat tumbuh secara horizontal.
Peta materi Chapter ini:
- Perbedaan scale-up dan scale-out, beserta kapan masing-masing sudah cukup.
- Definisi sharding di MongoDB dan posisinya terhadap replikasi.
- Sinyal kapan sebuah deployment benar-benar membutuhkan sharding.
Scale-Up vs Scale-Out #
Ada dua arah menambah kapasitas. Scale-up (vertical scaling) memperbesar satu mesin yang sama: CPU lebih banyak, RAM lebih besar, disk lebih cepat. Scale-out (horizontal scaling) menambah mesin baru dan menyebarkan beban ke semuanya.
| Aspek | Scale-up | Scale-out |
|---|---|---|
| Perubahan aplikasi | Tidak ada — tetap satu server | Perlu perencanaan pembagian data |
| Batas atas | Batas fisik satu mesin, biaya naik tajam di puncak | Ditambah mesin, hampir tanpa batas praktis |
| Proses peningkatan | Beli hardware, matikan, pindahkan data | Tambah server, biarkan sistem menyebar |
| Titik jenuh tunggal | Masih satu mesin | Beban terdistribusi |
Scale-up tetap langkah pertama yang wajar: sampai batas tertentu, satu mesin besar lebih sederhana dioperasikan daripada sepuluh mesin kecil. Sharding baru masuk hitungan ketika kebutuhan melewati apa yang bisa diberikan satu mesin — atau biayanya tidak masuk akal lagi.
Membagi Collection ke Banyak Shard #
Sharding di MongoDB adalah mempartisi data satu collection: document dengan rentang nilai shard key tertentu disimpan di shard yang satu, rentang lainnya di shard berikutnya. Setiap shard adalah replica set utuh — jadi setiap potongan data tetap punya salinan dan ketahanan kegagalan, persis seperti materi di Section Replikasi.
Diagram di atas menunjukkan hasil sharding: satu collection terpecah menjadi subset data yang menempati shard berbeda. Aplikasi tetap melihat satu collection biasa — pembagian ini tersembunyi di lapisan cluster.
Sharding dan replikasi menyelesaikan masalah yang berbeda dan saling melengkapi:
| Replikasi | Sharding | |
|---|---|---|
| Bentuk data | Salinan identik di setiap anggota | Data terbagi, tiap shard menyimpan subset |
| Masalah yang diselesaikan | Ketersediaan dan ketahanan kegagalan | Kapasitas storage dan throughput |
| Tulis | Tetap menuju satu primary | Tersebar ke banyak shard |
| Jumlah server menambah kapasitas | Tidak | Ya, kira-kira linear untuk beban yang terdistribusi baik |
Sebelum masuk lebih jauh, kita pastikan dulu posisi server latihan kita. Dokumentasi resmi menyebut cara mendeteksi koneksi ke mongos (router sharded cluster): respons perintah hello memuat field msg bernilai isdbgrid. Kita uji di server lokal:
printjson({ setName: db.hello().setName, msg: db.hello().msg })Output yang Dihasilkan:
{
setName: 'rs0',
msg: undefined
}Field setName berisi rs0 — server latihan kita adalah replica set, bukan sharded cluster. Field msg bernilai undefined, artinya kita terhubung ke mongod biasa; nilai isdbgrid hanya muncul saat kita terhubung ke mongos. Seluruh section ini karenanya bersifat konseptual: kita pakai diagram dan tabel, sementara perintah khusus sharding ditampilkan sebagai referensi karena membutuhkan cluster sungguhan.
Kapan Waktu yang Tepat #
Sharding menyelesaikan masalah skala, tetapi membawa kompleksitas operasional: ada komponen tambahan (mongos dan config servers, dibedah di Chapter Arsitektur Sharded Cluster), ada keputusan desain shard key yang menentukan nasib cluster bertahun-tahun ke depan, dan ada pekerjaan balancing yang berjalan di belakang. Karena itu pola yang dianjurkan dokumentasi resmi bersifat konservatif.
Sinyal bahwa satu deployment sudah layak di-shard:
- Kapasitas disk satu mesin mendekati batas, dan data terus bertumbuh.
- Working set (data panas yang aktif diakses) melampaui RAM satu mesin, terlihat dari page faults yang tinggi.
- Throughput tulis atau jaringan saturasi meski index dan query sudah dioptimalkan.
Rangkuman #
- Scale-up memperbesar satu mesin; scale-out menambah mesin. Sharding adalah mekanisme scale-out data di MongoDB.
- Sharding mempartisi satu collection ke banyak shard; setiap shard adalah replica set, sehingga replikasi dan sharding bekerja berlapis.
- Sinyal utama kebutuhan sharding: kapasitas disk, working set di luar RAM, dan throughput yang jenuh pada satu mesin.
- Kompleksitas operasionalnya nyata — gunakan hanya ketika masalah skala benar-benar muncul.
Chapter berikutnya membedah bentuk lengkap sharded cluster: siapa menyimpan data, siapa menyimpan metadata, dan siapa yang diajak bicara oleh aplikasi.