Shard key memotong ruang nilai menjadi potongan-potongan yang disebut chunk — dan chunk inilah unit kerja seluruh mesin distribusi: metadata-nya dicatat di config server, migrasinya dikerjakan balancer, dan distribusinya diperiksa lewat sh.status(). Chapter ini membahas anatomi chunk, ukurannya, evolusi istilahnya sejak MongoDB 6.0, dan bagaimana potongan awal terbentuk saat sebuah collection mulai di-shard.

Chunk: Rentang Nilai Shard Key #

Sebuah chunk menampung semua document yang nilai shard key-nya berada di satu rentang tertentu. Batas bawah rentang bersifat inklusif, batas atas eksklusif — persis semantik operator $gte dan $lt. Rentang terkecil yang mungkin adalah satu nilai shard key unik; nilai yang sama tidak pernah terbelah ke dua chunk.

Semantik batas ini bisa kita lihat langsung. Lima document pengukuran suhu per jam, lalu sebuah “rentang chunk” [2, 5):

js 
db.suhu.insertMany([
  { jam: 1, c: 30 },
  { jam: 2, c: 31 },
  { jam: 3, c: 32 },
  { jam: 4, c: 33 },
  { jam: 5, c: 34 }
])
db.suhu.find({ jam: { $gte: 2, $lt: 5 } }, { _id: 0 })

Output yang Dihasilkan:

text 
{
  acknowledged: true,
  insertedIds: {
    '0': ObjectId('6ad3d8dec399656157abbb67'),
    '1': ObjectId('6ad3d8dec399656157abbb68'),
    '2': ObjectId('6ad3d8dec399656157abbb69'),
    '3': ObjectId('6ad3d8dec399656157abbb6a'),
    '4': ObjectId('6ad3d8dec399656157abbb6b')
  }
}
[ { jam: 2, c: 31 }, { jam: 3, c: 32 }, { jam: 4, c: 33 } ]

Document jam: 2 ikut (batas bawah inklusif), jam: 5 tidak (batas atas eksklusif) — begitulah chunk [2, 5) akan mengklaim document pada cluster sungguhan. Setiap chunk dimiliki tepat satu shard pada satu waktu; daftar kepemilikan ini hidup di config.chunks pada config server.

Ukuran dan Evolusi Istilah #

Ukuran chunk bawaan adalah 128 MB. Angka ini naik dari 64 MB sejak MongoDB 6.0 — perubahan yang menyertai perombakan besar di baliknya: balancer modern menilai keseimbangan berdasarkan ukuran data (selisih megabyte antar shard), bukan lagi jumlah chunk, dan pemecahan chunk terjadi sebagai bagian dari proses balancing ketika chunk perlu dimigrasi. Akibatnya “chunk” kini konsep logis — dokumentasi modern kerap menyebutnya range — dan sebuah chunk boleh tumbuh melebihi 128 MB tanpa langsung dipecah; dokumentasi resmi bahkan menyebut kemungkinan menemui chunk 1 TB pada cluster dengan chunkSize 256 MB.

Dampak praktisnya:

  • Ukuran kecil → distribusi lebih rata, tetapi migrasi lebih sering dan routing table lebih besar.
  • Ukuran besar → migrasi jarang dan metadata ramping, tetapi distribusi bisa lebih timpang.
  • Untuk kebanyakan deployment, sedikit ketimpangan lebih baik daripada migrasi yang ramai.

Pembentukan Chunk Awal #

Saat sh.shardCollection() dijalankan, kondisi collection menentukan bentuk awalnya:

  • Collection sudah berisi data: terbentuk satu chunk besar awal yang menampung seluruh rentang nilai; balancer kemudian memecah dan memindahkannya sesuai kebutuhan.
  • Collection kosong, strategi ranged: terbentuk satu chunk kosong tunggal yang membentang dari MinKey ke MaxKey; balancer mengurus sisanya.
  • Collection kosong, strategi hashed: chunk kosong langsung di-pre-split dan disebar ke seluruh shard sejak awal — distribusi awal langsung merata.
  • Collection kosong dengan zone ranges terdefinisi: chunk awal dibuat mengikuti rentang zone, mempercepat penerapan zones (Chapter Zones).

Memeriksa Distribusi #

Pemeriksaan standar dilakukan lewat mongos dengan sh.status(). Karena server latihan kita bukan sharded cluster (terbukti ditolak di Chapter Arsitektur Sharded Cluster), berikut contoh bentuk output-nya pada cluster sungguhan — ilustratif, bukan hasil eksekusi:

text 
--- Sharding Status ---
  sharding version: { ... }
  shards:
        { "_id" : "shardA", "host" : "shardA/rsA1:27018,rsA2:27018", "state" : 1 }
        { "_id" : "shardB", "host" : "shardB/rsB1:27019,rsB2:27019", "state" : 1 }
  databases:
        { "_id" : "toko", "primary" : "shardA", "version" : { "uuid" : ..., "timestamp" : ... } }
              toko.pesanan
                    shard key: { userId: 1 }
                    unique: false
                    balancing: true
                    chunks:
                            shardA  3
                            shardB  3
                    { userId: MinKey } -->> { userId: 500 } on : shardA
                    { userId: 500 } -->> { userId: 1500 } on : shardB
                    ...

Bagian penting untuk dibiasakan: shard key menegaskan kunci yang dipakai, chunks merangkum jumlah chunk per shard, dan daftar -->> memetakan rentang ke pemiliknya. Bila jumlah chunk sangat banyak, sh.status() memadatkannya menjadi ringkasan per shard kecuali kita memanggil sh.status(true). Versi 8.0 ke atas juga menambahkan bagian shardedDataDistribution yang menampilkan distribusi berdasarkan ukuran data — selaras dengan orientasi ukuran-data balancer modern.

Untuk inspeksi terprogram, collection config.chunks bisa dikueri lewat mongos:

js 
// mdtest: skip
// Dijalankan lewat mongos pada sharded cluster sungguhan:
use config
db.chunks.find( { ns: "toko.pesanan" } ).sort( { min: 1 } ).limit( 5 )

Rangkuman #

  • Chunk adalah rentang nilai shard key dengan batas bawah inklusif dan batas atas eksklusif; unit terkecilnya satu nilai unik.
  • Ukuran bawaan 128 MB (naik dua kali lipat sejak 6.0); chunk boleh melebihinya karena split terjadi saat balancing.
  • Sejak 6.0 balancer bekerja berbasis ukuran data dan “chunk” menjadi konsep logis yang oleh dokumentasi modern disebut range.
  • Distribusi diperiksa lewat sh.status() — jumlah chunk per shard dan peta rentang -->> — atau config.chunks untuk inspeksi terprogram.

Chunk yang timpang letaknya menuntut ada pihak yang memindahkan — peran itu dipegang balancer, bintang chapter berikutnya.