Belajar Vitess - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Episode 1 sudah menjawab mengapa Vitess lahir. Sekarang kita jawab bagaimana ia bekerja: apa saja komponennya, bagaimana mereka berkoordinasi, dan bagaimana sebuah query sederhana berhasil menemukan data yang mungkin tersebar di puluhan server. Episode 2 adalah fondasi arsitektur — semua episode berikutnya akan merujuk kembali ke konsep di sini.

Roadmap episode 2: kita bedah empat komponen utama (VTGate, VTTablet, Topology Service, dan MySQL instances), lalu konsep keyspace dan shard, kemudian vindex sebagai otak routing, dan terakhir alur lengkap sebuah query. Akhir episode, gambaran besar arsitektur Vitess akan jelas di kepala kalian.

#Komponen Utama Vitess

#VTGate: Query Serving Layer

VTGate adalah pintu masuk semua query. Aplikasi terhubung ke VTGate seperti terhubung ke MySQL biasa, tapi di belakangnya VTGate melakukan tiga tugas: parsing SQL, merencanakan query, dan merutekan ke shard yang tepat. VTGate juga mengelola koneksi pooling, transaksi, dan batas concurrency.

Satu hal yang perlu diingat: VTGate tidak menyimpan data sama sekali. Ia murni logic layer yang tahu data itu di mana berdasarkan metadata dari Topology Service. Ini membuat VTGate mudah diskalakan secara horizontal — tambah instance VTGate, tambah kapasitas query.

#VTTablet: Storage Layer

VTTablet adalah agen yang hidup berdampingan dengan setiap MySQL instance. Satu VTTablet mengelola satu MySQL, dan merekalah yang berkomunikasi dengan VTGate: menerima query, menjalankannya di MySQL, mengelola replikasi, dan melaporkan health serta metrics.

VTTablet juga menjalankan berbagai background job: pemantauan replikasi, backup, dan VReplication (yang akan kita bahas di episode 10). Bayangkan VTTablet sebagai "remote control" yang memungkinkan Vitess mengendalikan MySQL tanpa masuk ke dalamnya langsung.

vtctlclient ListAllTablets

Perintah vtctlclient ListAllTablets menampilkan semua tablet beserta keyspace, shard, dan tipe perannya — window pertama kalian ke dalam arsitektur yang sedang berjalan.

#Topology Service

Topology Service adalah sumber kebenaran Vitess: ia menyimpan metadata tentang keyspace, shard, tablet, dan kebijakan. Secara teknis berupa backend kunci-nilai seperti etcd, ZooKeeper, atau Consul. Setiap kali VTGate butuh tahu shard mana yang melayani keyspace tertentu, ia bertanya ke Topology Service.

Karena itu, Topology Service harus sangat andal — ia adalah sistem saraf cluster Vitess. Jika ia mati, operasi yang membutuhkan metadata (seperti failover terencana) terganggu, meski query yang sedang berjalan biasanya tetap bisa dilayani oleh VTGate yang sudah punya cache topologi.

#MySQL Instances

Di level terbawah ada MySQL itu sendiri. Vitess tidak mengganti MySQL — ia membungkusnya. Kalian bebas memakai MySQL community, Percona Server, atau MariaDB, dan Vitess mengelolanya lewat VTTablet. Versi MySQL yang dipakai akan mempengaruhi fitur yang tersedia, misalnya versi baru mendukung mekanisme failover yang lebih modern.

#Keyspace, Shard, dan Vindexes

#Keyspace

Keyspace adalah unit logis tertinggi: kumpulan tabel yang diperlakukan sebagai satu database oleh aplikasi. Aplikasi bisa punya beberapa keyspace, seperti database terpisah di MySQL biasa. Satu keyspace bisa terdiri dari satu shard (tanpa sharding) atau banyak shard.

USE commerce

Perintah USE commerce memilih keyspace tujuan, mirip USE database di MySQL. Di sinilah kita bedakan konsep: keyspace itu seperti database, shard itu seperti potongan database.

#Shard

Shard adalah partisi data. Satu shard adalah satu MySQL (lengkap dengan replikanya) yang menyimpan sebagian data keyspace. Keyspace yang di-shard ke tiga shard berarti datanya terpecah tiga. Dua pendekatan sharding: sharding by range (misal rentang ID) dan sharding by hash (misal hash dari user_id).

#Vindex: Otak Routing

Vindex adalah fungsi yang memetakan nilai kolom ke shard. Saat query WHERE user_id = 42 masuk, VTGate memakai vindex user_id untuk menghitung shard mana yang memegang data user_id tersebut. Vindex wajib didefinisikan untuk kolom sharding key, dan pemilihan vindex adalah keputusan desain paling penting dalam sharding.

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

VSchema (Vitess Schema) di atas mendefinisikan vindex bernama hash yang diterapkan pada kolom user_id tabel users. Semua query berdasarkan user_id akan dirutekan langsung ke shard yang tepat — tanpa scatter.

#Alur Routing Sebuah Query

Mari ikuti perjalanan satu query dari aplikasi sampai ke disk:

1. Aplikasi mengirim SELECT * FROM users WHERE user_id = 42 ke VTGate.
2. VTGate mem-parsing query, lalu melihat VSchema untuk menemukan vindex user_id.
3. VTGate menghitung shard target dari nilai 42, dan bertanya ke Topology Service untuk menemukan tablet yang melayani shard itu.
4. VTGate meneruskan query ke VTTablet yang tepat.
5. VTTablet mengeksekusi di MySQL, lalu mengembalikan hasil ke VTGate, yang meneruskannya ke aplikasi.

Jika query tidak menyebut kolom sharding key, VTGate harus melakukan scatter-gather: mengirim query ke semua shard dan menggabungkan hasilnya. Ini bekerja, tapi lebih lambat — salah satu alasan desain skema yang baik sangat penting.

#VReplication dan Streaming

VReplication adalah mesin replikasi berbasis log MySQL yang dipakai Vitess untuk banyak tugas: migrasi data antar shard, resharding, streaming ke data warehouse, dan online schema change. Ia bekerja dengan membaca binlog dari sumber dan menerapkannya ke target. Kita akan memakai VReplication berulang kali di episode 10 dan 16.

#Penutup

Pada episode 2 ini kalian sudah memahami arsitektur inti Vitess: VTGate sebagai query serving layer yang tidak menyimpan data, VTTablet sebagai agen yang mengelola setiap MySQL, Topology Service sebagai sumber kebenaran metadata, serta konsep keyspace, shard, dan vindex yang mengatur penyebaran serta routing data.

Inti yang harus dibawa pulang:

• VTGate merutekan query tanpa menyimpan data; ia scalable secara horizontal.
• VTTablet mengelola satu MySQL dan menjalankan background job seperti backup.
• Topology Service adalah sumber kebenaran: etcd, ZooKeeper, atau Consul.
• Keyspace itu seperti database, shard itu potongan data, vindex itu pemetaan nilai ke shard.
• Query dengan kolom sharding key = fast path satu shard; tanpa kolom itu = scatter ke semua shard.

Di episode 3 berikutnya kita mulai beraksi: instalasi dan deployment dasar Vitess di Kubernetes menggunakan Helm, mengkonfigurasi keyspace dan shard pertama, lalu memverifikasi komponen dan koneksi MySQL. Sampai jumpa!