Shard Keys

Satu keputusan menentukan bagaimana data tersebar dan bagaimana query dirutekan selama sisa hidup sebuah collection ter-shard: shard key. Field ini menjadi alat pemotong yang membagi ruang nilai ke dalam chunk, dan sekaligus petanya saat mongos mencari lokasi sebuah document. Karena mengganti shard key setelah koleksi hidup bukan perkara ringan, desainnya harus dipikirkan sejak awal. Chapter ini membahas anatominya; kriteria memilih kandidat terbaik menyusul di Chapter Memilih Shard Key.

Anatomi Shard Key #

Shard key adalah satu field ber-index atau beberapa field compound index yang dipakai untuk mendistribusikan document antar shard. MongoDB memecah rentang nilai shard key menjadi chunk — rentang-rentang kecil yang tidak saling tumpang tindih — lalu berusaha menyebarkan chunk itu merata.

Bentuk deklarasinya menentukan strategi distribusi:

Perilaku strategi ranged dan hashed dibedah penuh di Chapter Ranged vs Hashed Sharding.

Dua aturan menyertai nilai shard key:

• Setiap document harus punya nilai shard key — tetapi “punya” di sini longgar: document yang tidak memiliki field shard key diperlakukan seolah nilainya null, dan menempati chunk range nilai null bersama document lain yang juga kosong.
• Nilai shard key pada sebuah document boleh di-update — sehingga document pindah chunk, bahkan pindah shard — kecuali field-nya adalah _id yang memang immutable. Update shard key yang sering menimbulkan biaya perpindahan, jadi bukan kebiasaan yang dianjurkan.

Syarat Index #

Collection yang di-shard membutuhkan index yang mendukung shard key — index tunggal pada shard key, atau compound index yang shard key-nya menjadi prefiksnya. Aturan lengkapnya:

• Collection kosong: sh.shardCollection() otomatis membuat index-nya bila belum ada.
• Collection sudah berisi data: kita harus membuat index-nya lebih dulu, sebelum memanggil sh.shardCollection().
• Index pendukung shard key tidak boleh di-drop selama ia satu-satunya index non-hidden yang menopang kunci itu.
• Constraint unique hanya bisa diterapkan pada shard key ber-strategi ranged (bukan hashed), dan menuntut collection punya unique index tepat pada kunci tersebut.

Yang bisa kita latih di server biasa adalah menyiapkan bentuk-bentuk index-nya — syarat yang sama dengan saat sharding sungguhan:

db.pelanggan.insertMany([
  { userId: 1, nama: "Budi" },
  { userId: 2, nama: "Siti" }
])
db.pelanggan.createIndex({ userId: 1 })
db.pelanggan.createIndex({ userId: "hashed" })
db.pelanggan.getIndexes()

Output yang Dihasilkan:

{
  acknowledged: true,
  insertedIds: {
    '0': ObjectId('6ad3d8e4d812fb8597514476'),
    '1': ObjectId('6ad3d8e4d812fb8597514477')
  }
}
userId_1
userId_hashed
[
  {
    v: 2,
    key: { _id: 1 },
    name: '_id_',
    collation: { locale: 'simple' }
  },
  {
    v: 2,
    key: { userId: 1 },
    name: 'userId_1',
    collation: { locale: 'simple' }
  },
  {
    v: 2,
    key: { userId: 'hashed' },
    name: 'userId_hashed',
    collation: { locale: 'simple' }
  }
]

Daftar getIndexes() memperlihatkan kedua bentuk berdampingan: key: { userId: 1 } untuk strategi ranged dan key: { userId: 'hashed' } untuk strategi hashed. Saat meng-shard collection sungguhan, salah satu dari dua bentuk inilah yang harus sudah tersedia bila collection-nya berisi data.

Mengaktifkan Sharding pada Sebuah Collection #

Prosedur resminya singkat — jalankan lewat mongos:

// mdtest: skip
// Dijalankan lewat mongos pada sharded cluster sungguhan:
sh.shardCollection( "toko.pelanggan", { userId: "hashed" } )

Sejak MongoDB 6.0, sh.shardCollection() tidak lagi menuntut sh.enableSharding() untuk databasenya terlebih dahulu — satu panggilan cukup. Argumen pertama adalah namespace lengkap (database.collection), argumen kedua adalah shard key.

Di server latihan kita, perintah ini jelas ditolak karena tidak ada mongos — dan pesan errornya informatif:

sh.shardCollection( "toko.pelanggan", { userId: "hashed" } )

Output yang Dihasilkan:

Uncaught 
MongoServerError[CommandNotFound]: no such command: 'shardCollection'. Are you connected to mongos?

Pesan Are you connected to mongos? adalah pengingat langsung bahwa seluruh administrasi sharding mengalir lewat router, sebagaimana dibedah di Chapter Shards, Config Servers, dan mongos.

Mengubah Shard Key #

Shard key bersifat tetap setelah collection di-shard — tetapi tidak sepenuhnya terkunci. Dua pintu resmi tersedia:

• refineCollectionShardKey (sejak 4.4): menambah field baru di akhir kunci lama, misalnya { negara: 1 } menjadi { negara: 1, userId: 1 }, untuk menaikkan cardinality tanpa memindahkan ulang seluruh data.
• reshardCollection (sejak 5.0): mengganti shard key total dan mendistribusikan ulang seluruh collection — operasi besar yang memakan waktu dan resource.

Rangkuman #

• Shard key adalah field ber-index yang menentukan distribusi document ke chunk dan shard; bentuknya { field: 1 } (ranged), { field: "hashed" }, atau compound.
• Document tanpa field shard key diperlakukan bernilai null; nilai shard key boleh di-update kecuali _id.
• Index pendukung shard key wajib tersedia untuk collection berisi data; bentuknya bisa kita latih di replica set biasa.
• Penggantian kunci hanya lewat refineCollectionShardKey atau reshardCollection — keduanya operasi besar, sehingga desain awal menentukan.

Dua strategi distribusi yang dijanjikan tabel di atas — ranged dan hashed — kini giliran dibedah tuntas.