UNDER PRESSURE

Level 2 · Database adalah Leher Botol

Sesi 20: Kalau Satu Database Tidak Cukup: Sharding, Shard Key, & Cross-Shard Queries

Bayangkan jika satu buku besar nasabah sudah setinggi 5 meter dan terlalu tebal untuk dibolak-balik, lalu kita membaginya menjadi 10 buku terpisah di 10 lemari berbeda. Apa yang menjadi sangat mudah, dan apa yang mendadak menjadi mimpi buruk operasional?

Sesi 20 / 343 menit baca

1. Bayangkan Jika

Sebuah bank mencatat seluruh mutasi rekening 100 juta nasabah di satu lemari rak besi raksasa. Rak itu sudah penuh sesak, dan lantainya mulai retak karena beban fisik.

Direktur bank memutuskan membagi data ke 4 lemari terpisah: - Lemari 1: Nasabah huruf A–F - Lemari 2: Nasabah huruf G–L - Lemari 3: Nasabah huruf M–R - Lemari 4: Nasabah huruf S–Z

Mencari saldo nasabah bernama "Budi" sekarang 4 kali lebih cepat. Tapi apa yang terjadi ketika "Budi" (Lemari 1) mentransfer uang Rp 100.000 ke "Zainal" (Lemari 4)? Petugas harus mengunci kedua lemari bersamaan, menulis di buku 1, berlari menyeberang ruangan ke buku 4, dan jika di tengah jalan lampu padam, saldo Budi berkurang tapi saldo Zainal belum bertambah!

2. Apa yang Sebenarnya Terjadi

Ketika skala data menulis (Write Workload) menembus batas hardware satu mesin (disk I/O saturated, tabel berukuran puluhan TB), kita terpaksa melakukan Horizontal Partitioning / Sharding:

  1. Memilih Shard Key (Kunci Partisi): - Shard key adalah kolom acuan yang menentukan di database mana sebuah baris data disimpan:

    \text{Node ID} = \text{Hash}(\text{user\_id}) \pmod N
    - Good Shard Key: Terdistribusi merata (misal: UUID user_id atau tenant_id), sehingga beban IOPS dan kapasitas storage terbagi seimbang di semua shard.

  2. Bahaya Mematikan: Hot Shard: - Jika shard key dipilih berdasarkan negara (country_code) atau tanggal (created_at):

    • 85% pengguna dari Indonesia \rightarrow Shard Indonesia 100% CPU/Disk, sedangkan Shard Singapura 2% idle.
    • Shard key tanggal \rightarrow Semua write hari ini menghantam Shard Hari Ini, membiarkan shard hari kemarin dingin tanpa beban.

  3. Scatter-Gather (Cross-Shard Query): - Query dengan shard key (WHERE user_id = 123) bersifat Single-Shard Routing (sangat cepat, direct ke 1 node). - Query tanpa shard key (SELECT * FROM orders WHERE status = 'PENDING') memaksa proxy mengirim query ke SEMUA shard (scatter), menunggu semua shard membalas, lalu menggabungkan dan menyortir di memori (gather). Latensi melonjak tajam!

3. Bagaimana Jika Kita Coba...

"Kita pakai Two-Phase Commit (2PC) untuk transaksi antar-shard!"

Mengapa Two-Phase Commit (2PC) dihindari di skala besar? - Fase 1 (Prepare): Koordinator mengunci baris data di Shard A dan Shard B, lalu bertanya "Apakah siap commit?". - Fase 2 (Commit): Jika kedua shard menjawab "Siap", koordinator memerintahkan write permanen. - Kelemahan Fatal: Selama proses 2PC, gembok data (locks) ditahan melintasi jaringan. Jika terjadi latency jaringan atau node koordinator crash di tengah jalan, baris data di kedua shard terkunci selamanya (blocking protocol), membuat transaksi lain macet. - Solusi Modern: Ganti 2PC dengan Pola Saga (Eventual Consistency & Compensating Transaction).

4. Nama Resminya

  • Database Sharding: Memecah satu dataset logis ke banyak node database fisik independen.
  • Shard Key: Atribut/kolom penentu lokasi penyimpanan partisi data.
  • Scatter-Gather: Pola eksekusi query paralel ke seluruh shard dan penggabungan hasilnya.
  • Hot Shard: Ketimpangan distribusi data/trafik pada satu partisi tertentu.
  • Saga Pattern: Pola transaksi terdistribusi berbasis serangkaian transaksi lokal + aksi kompensasi (rollback logic).

5. Di Dunia Kita

  • NewSQL / Distributed SQL: Database seperti CockroachDB, TiDB, YugabyteDB, Google Spanner yang mengotomatisasi sharding di level engine (Raft consensus) sehingga developer tidak perlu mengelola routing manual.
  • Application-Level Sharding: Framework seperti Vitess (untuk MySQL) atau Citus (untuk PostgreSQL) yang bertindak sebagai coordinator proxy transparan.

6. Lensa Performance Tester

Metrik dan pengujian krusial: 1. Shard Data & Traffic Skew: Ukur deviasi standar kapasitas disk dan QPS antar shard. Shard yang skew > 15% menandakan shard key buruk. 2. Scatter-Gather Latency Penalty: Bandingkan response time p99 query dengan Shard Key vs query Cross-Shard. 3. Saga Compensating Latency: Uji skenario kegagalan: gagalkan step ke-3 pada transaksi multi-shard. Berapa detik waktu yang dibutuhkan hingga compensating event mengembalikan saldo pengguna ke kondisi awal?

7. Pertanyaan untuk Ronde Berikutnya

Kita sudah tahu cara membelah database ke 10 server. Tapi bagaimana jika bentuk data yang paling efisien untuk menulis transaksi (Normalized OLTP) ternyata bentuk yang paling lambat dan menyiksa untuk menampilkan riwayat analitik (Denormalized Query)?

Jawabannya ada di Sesi 21: Memisahkan Jalur Baca dan Jalur Tulis (CQRS & Materialized Views).