Zones

Kemerataan bukan satu-satunya keinginan saat menempatkan data. Pelanggan di Asia ingin datanya dekat — baca dan tulis menempuh latensi rendah ke shard di region Asia; regulasi tertentu menuntut data warga suatu negara tinggal di yurisdiksi negara itu; dan tim infrastruktur kadang ingin data panas menempati shard ber-SSD sementara arsip menumpuk di shard murah. MongoDB menjawab ketiganya dengan satu mekanisme: zones — label pada shard yang diikat ke rentang shard key. Chapter ini membahas cara kerja dan API modernnya.

Zone: Label untuk Shard #

Zone adalah nama bebas (misalnya asia, regulasi-eu, ssd-cepat) yang dikaitkan ke satu atau lebih shard. Sebuah shard boleh memikul banyak zone, dan satu zone boleh menaungi banyak shard. Dua hal penting mengikuti definisi ini:

• Zone yang tidak memiliki satu pun rentang shard key tidak berpengaruh apa pun — MongoDB mengabaikannya.
• Zone bukan pengganti sharding: ia melengkapi balancer dengan aturan penempatan tambahan.

Rentang userId [1000, 5000) pada diagram terikat ke zone asia, sehingga chunk-chunknya hanya boleh menempati Shard 1 dan Shard 2. Chunk di luar rentang itu bebas menempati shard mana pun, termasuk Shard 3.

Rentang Zone dan Batasannya #

Rentang zone didefinisikan dengan sh.updateZoneKeyRange() dan mengikuti konvensi yang sudah kita kenal dari chunk: batas bawah inklusif, batas atas eksklusif. Tiga syarat mengikatnya:

• Rentang harus dibangun dari field shard key — untuk compound key, dari prefiksnya. Kita tidak bisa membuat zone berdasar field di luar shard key.
• Rentang antar zone tidak boleh saling tumpang tindih.
• Rentang boleh didefinisikan untuk collection yang belum di-shard bahkan belum ada — justru disarankan sebelum sharding collection kosong, agar chunk awal langsung tersebar mengikuti zone.

Balancer menjunjung zone pada setiap putarannya: chunk yang jatuh dalam rentang sebuah zone hanya dimigrasikan ke shard pemilik zone itu, sementara keseimbangan tetap dijaga di dalam kumpulan shard zone tersebut. Setelah penempatan selesai, baca-tulis untuk data dalam zone hanya dirutekan ke shard-shard zone itu.

Contoh Konfigurasi Lengkap #

Empat langkah berikut menyiapkan zone asia untuk data pelanggan dengan userId 1000 sampai 5000 (perintah referensi — dijalankan lewat mongos pada sharded cluster sungguhan):

// mdtest: skip
// 1. Kaitkan zone ke shard:
sh.addShardToZone( "shardJakarta", "asia" )
sh.addShardToZone( "shardSingapura", "asia" )

// 2. Ikat rentang shard key ke zone:
sh.updateZoneKeyRange(
  "toko.pelanggan",
  { userId: 1000 },
  { userId: 5000 },
  "asia"
)

// 3. Baca kembali zone yang melekat pada shard:
sh.status()

// 4. Lepas semua bila tidak lagi diperlukan:
sh.removeRangeFromZone(
  "toko.pelanggan",
  { userId: 1000 },
  { userId: 5000 }
)
sh.removeShardFromZone( "shardJakarta", "asia" )

Bagian shards pada output sh.status() akan memperlihatkan label zone yang melekat pada tiap shard, dan bagian collection memperlihatkan rentang -->> milik tiap zone.

Dua pengecualian teknis yang perlu diingat: zone pada field hashed diikat ke rentang nilai hash-nya (bukan nilai asli) — gunakan convertShardKeyToHashed() dari Chapter Ranged vs Hashed Sharding untuk menghitung batasnya, dan satu-satunya pola yang mudah diprediksi adalah mengunci seluruh collection dari MinKey ke MaxKey ke satu zone. Selain itu, time series collection tidak didukung zones — datanya selalu disebar merata.

Pola Pemakaian yang Lazim #

Pola terakhir patut digarisbawahi: tenant yang menyumbang porsi data tak seimbang bisa diasingkan agar tidak mengganggu distribusi tenant lain — variasi dari pola outlier yang kita bahas di Section Data Modeling.

Rangkuman #

• Zone adalah label pada shard yang diikat ke rentang shard key; batas bawah inklusif, batas atas eksklusif, dan tidak boleh tumpang tindih.
• Balancer hanya memigrasikan chunk zone ke shard pemilik zone itu; akses data zone pun akhirnya terkonsentrasi ke shard tersebut.
• API modernnya: sh.addShardToZone() dan sh.updateZoneKeyRange() — addShardTag/addTagRange adalah warisan sejarah.
• Use case utama: latensi geografis, residensi data regulatif, tiering hardware, dan isolasi penyewa besar.

Placement sudah diatur; tersisa satu keterampilan penutup untuk section ini: membaca gejala ketika sharded cluster mulai menunjukkan keluhan.