Belajar Vitess - Mengelola Keyspaces & Shards

#Pendahuluan

Cluster Vitess kalian sudah hidup dengan keyspace commerce satu shard. Sekarang waktunya naik level: membuat keyspace baru dari nol, lalu memahami bagaimana Vitess memecah data ke banyak shard. Episode 4 adalah jantung pengelolaan data Vitess — kalian akan belajar berpikir dalam keyspace, shard, dan sharding key.

Roadmap episode 4: membuat keyspace dari nol, menentukan sharding key dan vindex, menambah shard, rebalancing, dan praktik terbaik partitioning. Di akhir episode, kalian akan punya keyspace dua shard yang nyata dengan routing berdasarkan vindex.

#Membuat Keyspace

Membuat keyspace adalah langkah pertama. Gunakan vtctlclient untuk membuat keyspace dengan sharding yang diaktifkan:

vtctlclient CreateKeyspace -sharding_column_name=user_id -sharding_column_type=uint64 users
vtctlclient ListAllKeyspaces

Perintah pertama membuat keyspace bernama users dengan kolom sharding user_id bertipe uint64. vtctlclient ListAllKeyspaces harus menampilkan commerce dan users.

Sekarang keyspace users ada, tapi tanpa shard. Untuk mulai menyimpan data, keyspace harus punya setidaknya satu shard. Biasanya kita mulai dari satu shard bernama 0 (mewakili seluruh rentang dari nilai terkecil sampai terbesar):

vtctlclient InitShardMaster -force commerce/0 <tablet-alias>

Perintah vtctlclient InitShardMaster menunjuk tablet tertentu sebagai primary shard. Ini langkah inisialisasi agar shard siap menerima query.

#Menentukan Sharding Key dan Vindex

#Sharding Key

Sharding key adalah kolom yang menentukan lokasi data: baris dengan nilai sharding key tertentu selalu berada di shard yang sama. Pemilihan sharding key adalah keputusan paling penting di Vitess. Persyaratan utamanya: nilainya selalu ada di setiap baris dan konsisten sepanjang umur baris — mengubah sharding key setelah baris tersimpan berarti memindahkan baris.

Pertimbangan lain: kolom itu harus sering dipakai dalam query. Setiap query yang memfilter sharding key bisa dirutekan ke satu shard saja. Jika workload kalian jarang memfilter kolom itu, semua query akan scatter — dan sharding jadi sia-sia.

#Vindex

Vindex menghubungkan sharding key ke shard. Vindex paling umum adalah hash (untuk tipe integer), yang mendistribusikan data merata dengan hashing nilai lalu memetakannya ke rentang shard. Karena memakai hash, distribusinya nyaris seragam terlepas dari pola nilai aslinya.

Definisikan VSchema untuk keyspace users lewat JSON yang di-apply:

{
  "sharded": true,
  "vindexes": {
    "user_hash": { "type": "hash" }
  },
  "tables": {
    "users": {
      "column_vindexes": [
        { "column": "user_id", "name": "user_hash" }
      ]
    }
  }
}

Bagian "sharded": true menandakan keyspace ini dipecah, dan column_vindexes menetapkan bahwa kolom user_id dipetakan dengan vindex user_hash. Apply dengan ApplyVschema:

vtctlclient ApplyVschema -vschema_file=/path/to/vschema.json users

Setelah ini, tabel users akan di-shard berdasarkan user_id. Query WHERE user_id = 123 akan langsung menuju satu shard.

#Menambah Shard dan Rebalancing

#Dari Satu Shard ke Dua Shard

Keyspace users sekarang satu shard 0. Untuk menambah shard, kita harus membagi shard 0 menjadi dua bagian: -80 dan 80- (dalam heksadesimal, 80 adalah titik tengah rentang). Proses ini disebut resharding dan dijelaskan mendalam di episode 16 — untuk sekarang, pahami hasilnya:

Shard 0    : -80    (setengah kiri rentang)
Shard 80-  : 80-    (setengah kanan rentang)

Setiap keyspace punya rentang total dari nilai terkecil sampai terbesar, dan shard membagi rentang ini. Nilai yang dipetakan vindex menentukan shard mana yang menerimanya.

#Rebalancing vs Partitioning

Rebalancing berarti memindahkan data agar tiap shard kebagian beban merata. Di Vitess, rebalancing utama dilakukan lewat resharding terencana — bukan otomatis. Jika satu shard penuh, kalian pecah lagi. Ini berbeda dengan partitioning di MySQL, yang memecah data dalam satu server: partitioning tidak menambah kapasitas total, hanya menata di dalam server yang sama.

CREATE TABLE events (
  event_id bigint,
  created_at datetime,
  primary key (event_id, created_at)
) PARTITION BY RANGE (YEAR(created_at))

Perintah PARTITION BY RANGE di atas hanya membagi tabel di satu server. Sharding Vitess membaginya lintas server — skala totalnya berbeda jauh.

#Praktik Terbaik Partitioning di Vitess

Beberapa aturan praktis yang layak diingat:

• Pilih sharding key yang seimbang. Kolom dengan kardinalitas rendah (misal status: aktif/nonaktif) akan menimbun data di satu shard. Kolom dengan kardinalitas tinggi seperti user_id jauh lebih baik.
• Pertimbangkan join. Tabel yang sering di-join dengan tabel lain sebaiknya punya sharding key yang sama, sehingga join bisa terjadi di shard yang sama (co-located). Join lintas shard tetap didukung, tapi lebih lambat.
• Perhatikan tabel referensi. Tabel kecil yang jarang berubah (seperti daftar negara) tidak perlu di-shard — jadikan unsharded atau gunakan lookup vindex agar tersalin ke semua shard.
• Mulai dari satu shard. Jangan ragu memulai tanpa sharding. Tambahkan shard saat datanya benar-benar besar.

#Penutup

Pada episode 4 ini kalian sudah membuat keyspace baru bernama users, menentukan sharding key user_id dengan vindex hash, memahami rentang shard seperti -80 dan 80-, serta membedakan rebalancing, partitioning MySQL, dan sharding Vitess.

Inti yang harus dibawa pulang:

• Sharding key harus selalu ada, stabil, dan sering dipakai dalam query.
• Vindex menghubungkan nilai kolom ke shard; hash adalah pilihan paling umum untuk integer.
• Keyspace di-shard hanya jika VSchema menyatakan sharded: true.
• Shard membagi rentang hash: 0 bisa dipecah menjadi -80 dan 80-.
• Rebalancing di Vitess berarti resharding terencana, bukan proses otomatis.
• Mulai dari satu shard, reshard saat benar-benar dibutuhkan.

Di episode 5 berikutnya kita bedah mesin utama di belakang semua ini: query routing dan VTGate — bagaimana query dipecah, cross-shard query bekerja, scatter-gather, dan batasan SQL yang harus kalian tahu. Sampai jumpa!