Belajar Vitess - Schema Management & Vindexes

#Pendahuluan

Di episode 4 kalian sudah mengenal vindex hash sebagai pemetaan nilai ke shard. Episode 8 memperdalam: vindex punya banyak jenis dan peran yang berbeda, ada vindex global yang berbagi data lintas shard dan vindex local yang hanya milik satu shard. Pilihan vindex menentukan seberapa cepat query kalian, seberapa mudah resharding, dan seberapa konsisten routing-nya.

Roadmap episode 8: konsep vindex lebih dalam, perbandingan global dan local vindex, desain skema sharded vs unsharded, serta konfigurasi vindex dalam praktik. Ini episode desain — hasilnya terasa di seluruh umur sistem.

#Konsep Vindex Lebih Dalam

Vindex bukan indeks database biasa. Ia adalah fungsi yang menjawab satu pertanyaan: "nilai X ada di shard mana?" Tiga peran utama yang bisa dimainkan vindex:

• Unique vindex — memetakan nilai unik ke satu shard, seperti primary key. Vindex hash termasuk uniq: satu user_id hanya ada di satu shard.
• Non-unique vindex — memetakan satu nilai ke banyak shard, cocok untuk kolom seperti tenant_id di mana satu tenant menyebar. Vindex unicode_loose_md5 sering dipakai untuk ini.
• Lookup vindex — menyimpan pemetaan nilai ke shard sebagai data itu sendiri, bukan fungsi murni. Cocok ketika routing butuh kebalikan dari kolom sharding key.

{
  "sharded": true,
  "vindexes": {
    "hash": { "type": "hash" },
    "tenant_lookup": { "type": "consistent_lookup_unique" }
  },
  "tables": {
    "users": {
      "column_vindexes": [
        { "column": "user_id", "name": "hash" }
      ],
      "columns": [
        { "name": "tenant_id", "vindex": "tenant_lookup" }
      ]
    }
  }
}

Perhatikan kolom tenant_id juga diberi vindex — ini contoh vindex sekunder untuk mempercepat query berdasarkan tenant_id tanpa membuat scatter.

#Global vs Local Vindex

#Local Vindex

Local vindex hidup di dalam satu shard: datanya tidak dibagikan antar shard. Vindex hash adalah contohnya — fungsi murni yang dihitung dari nilai, tanpa menyimpan data. Local vindex sederhana, tanpa biaya penyimpanan tambahan, dan tanpa masalah konsistensi. Namun ia tidak bisa menjawab query berdasarkan kolom yang bukan kolom sharding key.

#Global Vindex

Global vindex adalah pemetaan yang bisa mengarahkan query dari nilai non-sharding-key ke shard yang tepat. Cara kerjanya: data pemetaan disimpan sebagai tabel lookup — bisa di shard sendiri (unsharded lookup keyspace) atau di dalam tabel dengan vindex lain. Saat aplikasi query WHERE tenant_id = 'X', VTGate melihat lookup vindex untuk menemukan shard dari nilai tenant_id itu, tanpa scatter.

{
  "vindexes": {
    "tenant_lookup": {
      "type": "consistent_lookup_unique",
      "params": {
        "table": "tenant_lookup",
        "from": "tenant_id",
        "to": "user_id"
      }
    }
  }
}

Vindex consistent_lookup_unique memakai tabel tenant_lookup untuk memetakan tenant_id ke user_id, yang kemudian dirutekan lewat vindex hash utama. Ini menghubungkan dua dunia: query berdasarkan tenant_id bisa menemukan shard tanpa scatter.

#Trade-off

• Local vindex: cepat, murah, tanpa biaya konsistensi, tapi hanya jalan untuk kolom sharding key.
• Global vindex: memungkinkan routing dari kolom lain, tapi butuh penyimpanan tambahan dan menyimpan biaya konsistensi transaksional saat tabel lookup diperbarui.

#Desain Skema untuk Tabel Sharded dan Unsharded

#Tabel Sharded

Tabel sharded menyimpan baris di shard berbeda berdasarkan vindex. Konsekuensinya penting: foreign key antar tabel berbeda shard tidak bisa dijamin secara konsisten, karena baris terkait bisa berada di MySQL berbeda. Vitess menangani ini dengan menonaktifkan FK enforcement lintas shard dan mendorong desain aplikasi untuk menjaga integritas.

Pola desain yang umum:

• Tabel yang selalu diakses bersama ditempatkan dengan sharding key yang sama, sehingga co-located.
• Tabel besar (misal orders) di-shard dengan user_id, sama seperti users.
• Query gabungan users JOIN orders ON user_id bisa diselesaikan di satu shard.

#Tabel Unsharded

Tidak semua tabel harus di-shard. Tabel referensi yang kecil dan jarang berubah — kode negara, daftar produk kecil, konfigurasi — lebih baik unsharded: tersimpan di satu shard (atau di keyspace unsharded terpisah), dan query-nya selalu tepat satu lokasi tanpa scatter.

CREATE TABLE countries (
  code char(2) primary key,
  name varchar(100)
)

Perintah CREATE TABLE countries di keyspace unsharded menyimpan tabel di satu lokasi. Vitess juga punya mekanisme reference tables yang menyalin tabel unsharded ke setiap shard keyspace sharded — supaya join dengan tabel sharded bisa berjalan tanpa keluar shard.

#Konfigurasi Vindex dalam Praktik

Urutan kerja yang biasa:

1. Buat VSchema awal dengan vindex utama untuk kolom sharding key.
2. Apply VSchema dan tes routing dengan query.
3. Tambahkan vindex sekunder atau lookup saat ada kebutuhan query baru.
4. Selalu simpan VSchema sebagai file di git dan apply lewat pipeline, bukan manual di shell.

vtctlclient ApplyVschema -vschema_file=vschema.json users
vtctlclient GetVschema users

vtctlclient GetVschema menampilkan VSchema yang aktif — cara cepat memverifikasi bahwa konfigurasi sudah benar dan konsisten dengan niat kalian.

#Penutup

Pada episode 8 ini kalian sudah memahami vindex secara mendalam: peran uniq, non-unique, dan lookup, perbedaan global dan local vindex beserta trade-off-nya, desain skema untuk tabel sharded dan unsharded, serta alur kerja konfigurasi vindex dengan VSchema.

Inti yang harus dibawa pulang:

• Vindex menjawab satu pertanyaan: nilai ini ada di shard mana.
• Local vindex murni fungsi, murah, tapi terbatas pada kolom sharding key.
• Global lookup vindex memungkinkan routing dari kolom lain dengan biaya penyimpanan dan konsistensi.
• Tabel besar di-shard dengan sharding key yang sama agar co-located untuk join.
• Tabel referensi kecil lebih baik unsharded atau reference table yang disalin ke semua shard.
• VSchema adalah file yang dikelola di git dan di-apply lewat pipeline, bukan manual.

Di episode 9 berikutnya kita urus jaminan: transaction dan consistency models — ACID di Vitess, transaksi single-shard vs cross-shard, dukungan XA, locking, dan praktik terbaik konsistensi. Sampai jumpa!