Belajar Vitess - Query Routing & VTGate

#Pendahuluan

Episode 4 mengatur data ke dalam shard. Sekarang kita bedah mesin yang membuat penyebaran itu transparan bagi aplikasi: VTGate. VTGate adalah orkestrator semua query — ia memutuskan ke shard mana sebuah query pergi, bagaimana hasil digabungkan jika harus menyentuh banyak shard, dan bagaimana query dipotong-potong agar MySQL tiap shard hanya menerima pekerjaan yang relevan.

Roadmap episode 5: peran VTGate dalam routing, fast path satu shard, query lintas shard dan scatter-gather, query planning dan dukungan SQL, lalu mode kegagalan yang perlu diwaspadai. Ini episode yang paling sering dipakai saat debugging query di produksi.

#Peran VTGate dalam Routing

VTGate adalah proxy MySQL stateless yang menghadap aplikasi. Tiga tugas intinya: parsing (memahami SQL), planning (membuat rencana eksekusi lintas shard), dan execution (mengirim ke shard dan menggabungkan hasil). Karena stateless, VTGate mudah di-scale — tambah Pod VTGate, tambah kapasitas.

Aplikasi melihat satu "MySQL raksasa". VTGate yang memikul kerumitan di belakang layar, termasuk memilih shard yang tepat lewat kombinasi VSchema dan Topology Service.

#Fast Path: Query Satu Shard

Query yang memfilter kolom sharding key adalah fast path — VTGate menghitung shard dari nilai vindex dan mengirim query ke satu shard saja:

SELECT name FROM users WHERE user_id = 42

Karena user_id adalah kolom sharding key dengan vindex hash, VTGate tahu persis shard mana yang menyimpan user_id = 42. Satu round-trip, tanpa penggabungan. Inilah alasan desain skema menekankan sharding key yang sering dipakai query.

#Query Lintas Shard dan Scatter-Gather

Query tanpa kolom sharding key harus menyentuh semua shard — ini disebut scatter atau scatter-gather. Contohnya:

SELECT COUNT(*) FROM users WHERE name = 'Arman'

VTGate mengirim query ke setiap shard, menerima hasil parsial, lalu menggabungkan hasilnya. Untuk COUNT(*) hasilnya dijumlahkan; untuk ORDER BY dan LIMIT VTGate melakukan sortir dan pemotongan global. Ini bekerja, tapi biayanya naik seiring jumlah shard.

Penting untuk dipahami: JOIN lintas shard didukung, dengan syarat. Join antar tabel yang co-located (sharding key sama) bisa diselesaikan di satu shard. Join yang melintasi shard berbeda akan memaksa VTGate melakukan gather dan join di memory — bekerja tapi mahal.

vtctlclient VtGateExecute -json "SELECT COUNT(*) FROM users" commerce

Perintah vtctlclient VtGateExecute mengeksekusi query melalui VTGate dari sisi admin — berguna untuk mengetes bagaimana VTGate menangani query tanpa aplikasi.

#Query Planning dan Dukungan SQL

VTGate menulis ulang dan memecah query sebelum dikirim ke shard. Teknik utamanya adalah query splitting: query global dipecah menjadi query per-shard yang hanya membawa data yang relevan. Contoh query WHERE user_id IN (1, 2, 3) dipecah per shard berdasarkan lokasi masing-masing nilai.

Dukungan SQL di VTGate luas, tapi tidak total. Hal-hal yang perlu kalian ketahui:

• Didukung penuh: query dasar SELECT, INSERT, UPDATE, DELETE, agregasi, JOIN co-located, transaksi single-shard.
• Terbatas: JOIN lintas shard (bisa tapi mahal), GROUP BY lintas shard (didukung untuk agregasi tertentu), subquery dalam bentuk tertentu.
• Tidak didukung: beberapa fungsi MySQL yang bergantung pada state global, seperti operasi yang melintasi shard tanpa kolom pengarah (misalnya UPDATE massal tanpa filter sharding key) — Vitess akan menolak dengan tegas untuk mencegah update tidak sengaja yang melampaui batas.

Saat query ditolak, pesan errornya biasanya jelas. Ini fitur keamanan, bukan bug: Vitess lebih baik menolak query berbahaya daripada menjalankannya secara salah.

#Mode Kegagalan yang Perlu Dikenali

Beberapa kegagalan yang paling sering dijumpai di VTGate:

• Query timeout. VTGate punya batas waktu default per query. Query lambat lintas shard mudah kena timeout.
• Scatter overload. Terlalu banyak scatter query membuat VTGate dan semua shard kewalahan. Pantau metrik scatter dari episode 7.
• Primary not serving. Jika primary shard mati, VTGate menolak query tulis sampai failover selesai.
• Topology service down. VTGate memakai cache topologi, jadi query biasanya tetap jalan, tapi operasi yang butuh metadata segar terganggu.

Untuk memeriksa status shard dan kesehatan query, vtctlclient adalah teman terbaik:

vtctlclient ListShardHealth
vtctlclient GetTablet -tablet <alias>

#Query Splitting dalam Praktik

Salah satu teknik yang paling sering dipakai VTGate adalah query splitting. Ambil contoh query dengan nilai berulang:

SELECT * FROM users WHERE user_id IN (5, 1000, 2500000)

Jika ketiga nilai itu berada di shard yang berbeda, VTGate memecah query menjadi tiga query per-shard, masing-masing hanya memuat nilai yang relevan, lalu menggabungkan hasilnya. Setiap shard hanya mengerjakan porsinya sendiri — tidak ada shard yang menanggung query penuh.

Pola ini juga berlaku untuk UPDATE dan DELETE dengan IN — asalkan kolomnya adalah sharding key. Itu sebabnya filter WHERE user_id IN (...): justru disarankan, bukan dihindari. VTGate menangani pemecahan dan penggabungan otomatis.

#Menentukan Akses ke Keyspace dan Tabel

Untuk query yang tidak menyebut keyspace, VTGate memakai keyspace yang dipilih lewat USE atau default. Pemetaan keyspace dan tabel bisa dilihat langsung:

vtctlclient GetVschema commerce

vtctlclient GetVschema menampilkan VSchema aktif — peta tabel, vindex, dan status sharding. Saat debugging routing query, ini tempat pertama untuk memverifikasi bahwa konfigurasi sesuai harapan.

#Penutup

Pada episode 5 ini kalian sudah memahami bagaimana VTGate merutekan query: fast path satu shard untuk query dengan kolom sharding key, scatter-gather untuk query lintas shard, query planning dengan splitting, serta batas dukungan SQL dan mode kegagalan yang umum.

Inti yang harus dibawa pulang:

• VTGate stateless dan scalable horizontal; ia memikul semua kerumitan routing.
• Query dengan kolom sharding key adalah fast path satu shard — desain skema mengejarnya.
• Query tanpa kolom sharding key menyebar ke semua shard dan digabungkan hasilnya.
• JOIN lintas shard bekerja tapi mahal; JOIN co-located jauh lebih disukai.
• Vitess menolak UPDATE/DELETE tanpa filter sharding key demi keamanan.
• Kenali mode kegagalan: timeout, scatter overload, dan primary down.

Di episode 6 berikutnya kita jaga ketersediaan: replikasi dan failover — topologi primary dan replica, failover otomatis dengan vtctld dan pseudo-GTID, serta strategi backup dan recovery. Sampai jumpa!