Belajar Vitess - Sejarah, Latar Belakang & Mengapa Memilih Vitess

#Pendahuluan

Di episode 0 kalian sudah menyiapkan environment. Sekarang pertanyaannya bergeser dari "bagaimana" ke "mengapa": kenapa Vitess itu ada, apa masalah yang dia pecahkan, dan kapan kalian sebaiknya memilihnya dibandingkan solusi lain. Episode 1 ini adalah cerita asal-usul — dan cerita asal-usul selalu penting karena ia menjelaskan mengapa Vitess dirancang dengan cara tertentu.

Roadmap episode 1: pertama kita telusuri kelahiran Vitess di dalam YouTube, kedua perjalanannya menjadi proyek open source dan terakreditasi CNCF, ketiga perbandingan jujur dengan MySQL tradisional, Galera, dan database cloud managed, dan terakhir use case di mana Vitess benar-benar bersinar. Akhir episode, kalian bisa menjawab dengan yakin: "kapan saya butuh Vitess?"

#Lahirnya Vitess dari Dalam YouTube

Kisah Vitess dimulai sekitar tahun 2010, ketika YouTube menghadapi masalah yang sangat nyata: MySQL single instance tidak sanggup lagi menampung skala traffic video mereka. Penyelesaian ala engineer saat itu adalah sharding manual — memecah database menjadi banyak instance, lalu menulis logika routing di dalam kode aplikasi.

Masalahnya, sharding manual itu menyakitkan. Setiap skema baru harus dipikirkan bagaimana dipecah, setiap query harus tahu harus pergi ke instance mana, dan operasi seperti resharding adalah mimpi buruk yang memakan waktu berbulan-bulan. Aplikasi dan database jadi tidak bisa dipisahkan — pindah instance berarti ubah kode.

Dari rasa sakit inilah Sugu Sougoumarane dan tim di YouTube membangun solusi yang kelak bernama Vitess: sebuah layer di depan MySQL yang menyerap semua kerumitan sharding, replikasi, dan routing, sehingga aplikasi tetap menulis SQL biasa seolah-olah menghadapi satu database besar.

#Evolusi Menjadi Proyek Open Source dan CNCF

Pada 2015, Vitess dirilis sebagai proyek open source. Ini langkah penting: bukan hanya YouTube yang butuh database scalable, tapi seluruh industri. Vitess lulus uji kelayakan di tahun 2017 ketika menjadi proyek CNCF (Cloud Native Computing Foundation) — organisasi yang sama yang menaungi Kubernetes — dan mencapai status graduated pada 2018.

Apa arti status graduated? Artinya proyek ini telah terbukti stabil, memiliki governance yang sehat, dan dipakai di produksi oleh banyak perusahaan besar. Beberapa pengguna Vitess yang terkenal antara lain Slack, GitHub, dan banyak platform e-commerce yang menangani traffic lonjakan seperti hari belanja online.

Keanggotaan CNCF juga menandakan satu hal penting: Vitess lahir sebelum Kubernetes populer, tapi ia tumbuh bersama ekosistem cloud native. Integrasi dengan Kubernetes, Prometheus, dan operasi GitOps menjadi bagian dari DNA-nya. Ini yang membedakannya dari solusi sharding custom yang dibuat perusahaan-perusahaan besar secara internal.

#Perbandingan dengan Solusi Lain

#MySQL Tradisional dan Replikasi Manual

MySQL vanilla menangani sharding lewat logika aplikasi: aplikasi tahu tabel mana ada di instance mana. Pendekatan ini bekerja di skala kecil, tapi runtuh saat skala naik — resharding jadi proyek besar, failover manual, dan tidak ada satu sumber kebenaran tentang lokasi data.

Vitess menghilangkan beban itu. Aplikasi cukup terhubung ke VTGate, dan Vitess yang menentukan shard mana yang dituju. Kolom sharding key dipilih saat desain keyspace, dan operasi seperti resharding bisa berjalan online tanpa mengubah kode aplikasi sama sekali.

SELECT user_id, email FROM users WHERE user_id = 42

Query di atas ditulis aplikasi tanpa tahu atau peduli user_id itu berada di shard berapa. Vitess yang menyelesaikan sisanya.

#Galera Cluster

Galera (misalnya MariaDB Galera Cluster dan Percona XtraDB Cluster) menangani replikasi sinkron multi-primary. Kekuatannya: semua node bisa menerima tulis, konflik dideteksi di level transaksi, dan tidak ada lag replikasi. Kekurangannya: Galera tidak menangani sharding sama sekali — semua node menyimpan semua data, jadi kapasitas total dibatasi oleh node terbesar.

Vitess berbeda: sharding adalah fitur inti. Kapasitas tumbuh dengan menambah shard, bukan dengan mengganti hardware yang lebih besar. Ini bukan soal Galera buruk — Galera hebat untuk konsistensi, Vitess hebat untuk skala horizontal.

#Database Cloud Managed

Layanan seperti Amazon Aurora, Cloud SQL, atau RDS menawarkan kemudahan luar biasa: backup otomatis, failover kelolaan, dan hampir tanpa beban operasional. Tetapi kemampuan sharding-nya terbatas atau tersembunyi. Beberapa layanan mendukung "sharding" lewat partisi logis atau layanan terpisah, tapi jarang sefleksibel dan se-transparan Vitess.

Vitess memberi kontrol penuh: kalian memilih topology, kebijakan failover, dan strategi sharding sendiri. Ini cocok untuk tim yang butuh fleksibilitas maksimum, atau yang ingin menghindari vendor lock-in. Tentu dengan konsekuensi: kalian yang bertanggung jawab mengoperasikannya.

#Perbandingan Kunci dalam Satu Tabel

Agar lebih mudah dibandingkan, ringkasan perbedaan utamanya:

Tabel di atas bukan penilaian "siapa terbaik", melainkan peta trade-off: Vitess menuntut operasi paling berat, tapi memberi skala horizontal yang tidak diberikan solusi lain. Pilihan yang tepat bergantung pada konteks tim dan beban.

#Use Case yang Cocok

#High-scale OLTP

Use case pertama dan utama: workload tulis yang sangat tinggi. Ketika satu MySQL tidak sanggup lagi menampung tulis, Vitess membagi beban ke banyak primary di banyak shard. Inilah alasan utama YouTube, Slack, dan GitHub memakainya.

#Multi-tenant Database

Vitess sangat cocok untuk SaaS multi-tenant. Setiap tenant bisa dipetakan ke shard tertentu, atau tenant besar mendapat shard sendiri. Isolasi menjadi jelas, dan kapasitas bisa ditambah per tenant tanpa menggangu tenant lain.

#Migrasi Legacy MySQL

Sudah punya database MySQL besar yang terasa berat? Vitess mendukung migrasi bertahap. Kalian bisa mulai tanpa sharding — satu shard yang diurus Vitess — lalu reshard saat dibutuhkan. Migrasi ini mengurangi risiko dibandingkan menulis ulang sharding dari nol.

vtctlclient ListAllKeyspaces

Perintah vtctlclient ListAllKeyspaces menampilkan daftar keyspace — konsep yang akan kita bedah di episode 2. Untuk sekarang, cukup catat bahwa menjalankan Vitess tanpa sharding adalah jalan masuk yang sah dan umum dilakukan.

#Kapan Tidak Perlu Vitess

Agar fair, kita juga harus tahu kapan Vitess bukan pilihan yang tepat:

• Skala kecil. Jika database masih bisa muat di satu server yang besar, Vitess menambah kompleksitas tanpa imbalan. Komponen VTGate, VTTablet, dan Topology Service butuh dirawat.
• Tim kecil tanpa kapasitas operasional. Vitess adalah platform yang harus dioperasikan. Tanpa tim yang sanggup memantau dan memelihara, biaya operasinya bisa melebihi manfaatnya.
• Workload dominan OLAP. Vitess dioptimalkan untuk transaksi. Analitik besar lebih baik dijalankan di data warehouse (kita bahas di episode 17).
• Kebutuhan konsistensi lintas shard yang ketat. Meski didukung, transaksi lintas shard tetap kompleks. Jika hampir semua transaksi melintasi banyak shard, pertimbangkan desain ulang.

#Penutup

Pada episode 1 ini kalian sudah memahami dari mana Vitess berasal, bagaimana ia berkembang menjadi proyek CNCF yang teruji, dan bagaimana posisinya dibandingkan MySQL tradisional, Galera, dan database cloud managed. Kalian juga sudah melihat use case utamanya: high-scale OLTP, multi-tenant, dan migrasi legacy MySQL.

Inti yang harus dibawa pulang:

• Vitess lahir dari rasa sakit sharding manual di YouTube sekitar 2010.
• Proyek CNCF dengan status graduated sejak 2018, dipakai oleh Slack dan GitHub.
• Sharding adalah fitur inti Vitess, sementara Galera hanya menangani replikasi.
• Cloud managed menawarkan kemudahan, Vitess menawarkan kontrol dan skalabilitas horizontal.
• Vitess bisa dimulai tanpa sharding dan direshard belakangan — migrasi bertahap itu sah.

Di episode 2 berikutnya kita bedah konsep dasar dan arsitektur utama: peran VTGate, VTTablet, Topology Service, dan MySQL instances, plus bagaimana data dibagi ke shard dan query dirutekan. Sampai jumpa!