Belajar Database Administrator - Distributed & NewSQL
Kapan satu node database tidak lagi cukup dan bagaimana mendesain sistem yang tumbuh horizontal: memahami model konsistensi dan trade-off CAP, mengenal distributed SQL seperti CockroachDB dan YugabyteDB, Vitess untuk sharding MySQL, hingga kerangka evaluasi arsitektur yang jujur agar keputusan tidak terjebak hype
#Pendahuluan
Episode 21 menaikkan performa di dalam satu node; episode ini membahas batasnya. Read replicas menolong beban baca (episode 8), tapi beban tulis tetap satu titik. Saat tulis tumbuh, ukuran data menggelembung, atau aplikasi menuntut keberadaan di banyak region, kalian harus berpikir terdistribusi.
Distributed database menjanjikan banyak hal sekaligus: skala horizontal, high availability, dan konsistensi. Kenyataannya selalu ada trade-off. Episode ini memberi bahasa untuk mengevaluasi opsi — CockroachDB, YugabyteDB, Vitess — tanpa terjebak hype.
#Mengapa Satu Node Punya Batas
Scaling vertikal (episode 10) punya plafon: mesin terbesar mahal, dan saat mati semua mati. Read replicas menambah throughput baca, tapi tulis tetap satu titik — semua replikasi berasal dari satu primary. Jika laju tulis melebihi kemampuan satu server (misal puluhan ribu transaksi per detik), kalian harus membagi beban ke banyak node.
#Model Konsistensi: Bahasa Negosiasi
Ini konsep yang paling sering disalahpahami. Secara singkat:
| Model | Arti | Latensi tipikal |
|---|---|---|
| Strong (linearizable) | Baca selalu melihat tulis terbaru | Paling lambat di cluster |
| Snapshot isolation | Baca snapshot konsisten pada satu titik waktu | Sedang |
| Eventual consistency | Replica bisa sedikit tertinggal, lalu menyusul | Tercepat |
Semakin kuat konsistensi, semakin banyak koordinasi antar node — dan koordinasi memakan waktu. Di dunia nyata aplikasi jarang butuh strong consistency untuk semua data. SELECT katalog produk boleh eventual; saldo akun tidak boleh.
Kata kunci yang wajib kalian baca di dokumentasi: linearizable, snapshot isolation, dan serializable — apakah sistem benar-benar menjamin itu untuk transaksi multi-row atau hanya untuk operasi single-row.
#Distributed SQL: CockroachDB dan YugabyteDB
Dua proyek utama di kategori "distributed SQL": CockroachDB dan YugabyteDB. Keduanya:
- Wire-compatible dengan PostgreSQL (CockroachDB) atau perpaduan PostgreSQL dan Cassandra (YugabyteDB) — aplikasi bisa pindah dengan perubahan minimal.
- Memakai Raft consensus untuk mereplikasi data ke beberapa node secara sinkron — begitu tulis di-commit, data ada di mayoritas node.
- Memberikan ACID lintas node dengan SQL yang familier — tanpa sharding manual.
Setiap node bisa menerima baca dan tulis; data direplikasi sinkron; saat satu node mati, node lain mengambil alih tanpa failover manual (berbeda dengan episode 8 yang perlu pengelolaan failover sendiri).
Batas yang harus dipahami: konsistensi lintas region itu mahal. Menulis data yang harus konsisten ke seluruh dunia menambah latensi tiap transaksi. Solusi umum: geo-partitioning — data ditempatkan dekat usernya, dan hanya data yang benar-benar global yang ditulis lintas region.
#Vitess: Sharding untuk MySQL
Vitess mengambil pendekatan berbeda: bukan database baru, melainkan lapisan routing di depan MySQL yang mengelola sharding. Dikembangkan di YouTube dan dipakai banyak perusahaan dengan beban tulis MySQL raksasa.
Vitess membagi tabel menjadi banyak shard (masing-masing MySQL sendiri), dan Vtgate (query router) menerjemahkan query aplikasi ke shard yang benar. Keunggulan utamanya resharding online: menambah atau membagi shard tanpa downtime — sesuatu yang sangat sulit dilakukan manual (episode 10). Harganya: kompleksitas operasional yang tinggi dan model data harus "shardable" (ada shard key yang jelas).
#Kerangka Evaluasi: Kapan Pakai Apa
| Opsi | Cocok untuk | Perhatikan |
|---|---|---|
| Single node + replicas | Beban baca besar, tulis terkendali | Batas tulis dan storage |
| Partitioning (ep. 21) | Satu tabel raksasa, data per-waktu | Terbatas satu node |
| CockroachDB/YugabyteDB | Butuh SQL + ACID + multi-region, tulis tumbuh | Konsistensi lintas region mahal, tim perlu skill baru |
| Vitess | Beban tulis MySQL raksasa, butuh resharding | Kompleksitas operasional tinggi |
Sebelum memilih, jawab lima pertanyaan:
- Berapa laju tulis puncak dan proyeksi pertumbuhannya?
- Apakah data harus konsisten kuat lintas region, atau boleh eventual?
- Seberapa dalam skill tim dengan sistem baru itu?
- Berapa biaya operasional (node, lisensi, cloud) dibandingkan satu node yang lebih besar?
- Apakah workload sudah optimal dulu (episode 6 dan 21)? Banyak "kebutuhan distributed" hilang setelah tuning.
Warning
Distributed database bukan jalan pintas menuju performa. Jika workload satu node belum optimal, memindahkannya ke cluster terdistribusi biasanya menghasilkan sistem yang lebih kompleks, lebih lambat untuk query sederhana, dan lebih mahal. Ukur dulu; distribusikan setelah terbukti perlu.
#Pitfall Umum Distributed
- Distributed bukan berarti cepat: untuk query yang menyentuh satu node, sistem terdistribusi justru lebih lambat karena overhead koordinasi. Yang dijual adalah skala, bukan kecepatan per query.
- Mengabaikan latensi lintas region: query yang menunggu quorum antar region jauh lebih lambat — ukur p95 nyata sebelum membuat janji.
- Data panas di region yang salah: data harus dekat dengan usernya; geo-partitioning mengendalikan latensi dan biaya transfer.
- Menganggap operasionalnya sama: backup, monitoring, dan upgrade cluster terdistribusi punya pola sendiri — jangan asumsikan runbook single-node otomatis berlaku.
#Praktik: Evaluasi Arsitektur Terdistribusi
Langkah praktis yang bisa kalian lakukan tanpa membeli cluster:
- Karakterisasi workload: catat puncak tulis, ukuran data, dan kebutuhan konsistensi tiap fitur aplikasi.
- Buat matriks: fitur mana butuh strong consistency, mana yang boleh eventual.
- Prototype kecil: jalankan CockroachDB atau YugabyteDB lokal (mode single-node) dan uji API aplikasi kalian.
- Benchmark lintas-region di cloud bila perlu — ukur p95, bukan klaim vendor.
- Dokumentasikan keputusan: pilihan, trade-off, dan alasannya — bahan post-mortem jika nanti menyesal.
#Penutup
Inti yang harus dibawa pulang:
- Satu node punya batas; distributed adalah trade-off, bukan peningkatan gratis.
- Pahami model konsistensi sebagai bahasa negosiasi dengan vendor.
- CockroachDB/YugabyteDB: SQL + ACID lintas node via Raft; Vitess: sharding MySQL via query router.
- Evaluasi dengan workload nyata, ukur p95, dan pastikan tuning satu node sudah optimal dulu.
Di episode 23 selanjutnya kita berbicara tentang uang: cost & resource optimization — right-sizing, storage tiering, dan FinOps database — bagaimana menurunkan tagihan cloud tanpa mengorbankan performa. Sampai jumpa di episode 23!