Distributed SQL (NewSQL): Menggabungkan Kehebatan SQL dan NoSQL

Dilema Puluhan Tahun di Industri IT

Selama 20 tahun terakhir, *Software Architect* harus menelan pil pahit dan memilih salah satu:

1. Pilih SQL (MySQL/Postgres): Datamu sangat aman, relasinya kuat, dan kalkulasi uang tidak pernah salah (ACID). TAPI, saat lalu lintas aplikasi membludak, database ini sangat susah dipencar ke beberapa server (Horizontal Scaling / Sharding sulit).
2. Pilih NoSQL (MongoDB/Cassandra): Sangat gampang didistribusikan ke ratusan server murah untuk menahan jutaan request. TAPI, data bisa jadi tidak konsisten dan tidak cocok untuk menghitung saldo Bank.

Bagaimana jika kita menginginkan kekuatan Transaksi Keuangan SQL digabungkan dengan Kelenturan Skala Server NoSQL? Impian mustahil itu akhirnya terwujud di dekade ini dengan lahirnya era Distributed SQL (NewSQL).

Mengenal CockroachDB dan TiDB

Database NewSQL modern (yang paling terkenal adalah CockroachDB, TiDB, dan YugabyteDB) dirancang dari nol dengan arsitektur Cloud-Native.

Dari kacamata *Backend Developer* (di sisi Node.js), kamu mengetikkan *Query* SQL biasa (SELECT * FROM users JOIN orders). Kamu tidak sadar ada yang aneh. TAPI, di belakang layar komputernya, keajaiban terjadi.

Kelebihan Mengguncang NewSQL (Plus)

• Horizontal Scaling Otomatis: Kamu pasang CockroachDB di 5 Server berbeda. Saat data di Server 1 penuh, CockroachDB akan secara otomatis memotong data tabelnya dan memindahkannya ke Server 2 dan 3 di latar belakang tanpa mematikan aplikasi! Semua server bekerja barengan memproses *Query* SQL secara paralel.
• Survive the Disaster (Tahan Banting): Sesuai namanya (Cockroach = Kecoak), *database* ini sangat susah mati. Jika satu Data Center (Gedung Server) di Jakarta meledak, komponen *database* di Singapura akan otomatis mengambil alih fungsi Utama (Master) tanpa kehilangan satu sen pun data transaksi. Ketaatan ACID-nya 100% terjaga.

Kekurangan NewSQL (Minus)

Kesempurnaan ini harus dibayar mahal oleh Hukum Fisika (Latency). Karena datanya tersebar di banyak server yang saling berbicara sebelum menyepakati satu transaksi (*Distributed Consensus / Raft*), waktu yang dibutuhkan untuk mengeksekusi satu *Query* sederhana akan sedikit lebih lambat (ada tambahan beberapa milidetik) dibandingkan dengan menjalankan MySQL biasa di satu mesin tunggal. NewSQL juga butuh biaya *server* yang tinggi untuk merakit kelompok minimal 3 *Nodes/Servers*.