Belajar Database Administrator - Capacity Planning & Scaling

#Pendahuluan

Setelah mengamankan database di episode 9, kita menatap masa depan: kapasitas. Server yang sesak diam-diam adalah penyebab terbesar downtime mendadak. Capacity planning adalah seni membaca data pertumbuhan dan menyiapkan jalan sebelum macet — bukan menunggu macet, lalu buru-buru menambah instance.

Kesalahan paling mahal seorang DBA: menambah resource berdasarkan panik, bukan data. Episode ini mengajarkan kalian mengukur, memilih strategi, dan mendokumentasikan rencana — sehingga kapan pun ditanya "kapan kita perlu naik kapasitas?", kalian punya jawaban angka, bukan perasaan.

#Mengukur Baseline: Data Dulu, Baru Keputusan

Semua perencanaan dimulai dari pengukuran. Kumpulkan dari dashboard episode 7:

Contoh perhitungan sederhana: tabel orders tumbuh 8 GB/bulan dan disk sisa 120 GB → sekitar 15 bulan sebelum penuh. Dengan ambang aman 80%, kalian punya waktu ~10 bulan untuk bertindak. Itulah bahasa bisnis yang membuat CFO mau mendengarkan: "kita butuh upgrade sekitar Q3, berdasarkan tren 10 bulan ini."

#Scale-Up vs Scale-Out

Dua arah utama scaling:

Aturan praktis DBA: scale-up untuk langkah cepat, scale-out untuk janji jangka panjang. Naikkan instance dulu (mudah, satu restart), sambil menyiapkan replikasi/sharding untuk beban yang terus naik. Jangan langsung sharding sebelum benar-benar perlu — ia mahal dalam kompleksitas operasional.

#Read Replicas: Strategi Pertama Scale-Out

Kebanyakan aplikasi adalah 80-90% baca. Solusi paling murah: pindahkan baca ke read replicas — infrastruktur yang sudah kita bangun di episode 8. Pola implementasi:

1. Primary melayani tulis + kritis.
2. Satu atau lebih replica melayani baca berat (reporting, dashboard, search).
3. Aplikasi/ORM membagi rute (read/write splitting).
4. Replica juga jadi kandidat failover (episode 8) dan backup (episode 5) tanpa menyentuh primary.

# contoh di aplikasi (pseudo): dua endpoint connection string
DB_PRIMARY=10.0.0.11:5432
DB_REPLICA=10.0.0.12:5432   # read-only

Bahaya yang harus dikelola: stale reads — data di replica bisa tertinggal beberapa detik (replikasi async). Query yang menulis lalu langsung membaca datanya sendiri harus tetap ke primary, atau hasilnya tidak konsisten.

#Sharding: Memecah Data, Bukan Menyalinnya

Ketika satu database terlalu besar walau sudah di-scale-up dan dibantu replica, tiba saatnya sharding: memecah data ke beberapa node berdasarkan kunci (shard key). Contoh nyata: orders di-shard per user_id ke 4 node.

node-1: user_id % 4 == 0   node-2: user_id % 4 == 1
node-3: user_id % 4 == 2   node-4: user_id % 4 == 3

Trade-off yang wajib dipahami sebelum sharding:

• Query lintas shard jadi mahal: join dan agregasi global harus dikumpulkan dari semua node (fan-out). Beberapa query mungkin tidak bisa dijalankan efisien lagi.
• Distribusi tidak selalu merata: pilih shard key dengan kardinalitas dan distribusi baik — user_id bagus, status (hanya 3 nilai) bencana.
• Operasional kompleks: rebalance saat menambah node, backup & HA per node, dan monitoring berlipat.

Di PostgreSQL, sharding bisa dilakukan dengan extension citus; MongoDB punya sharding native (episode 13); dan skala raksasa memakai solusi distributed seperti CockroachDB (episode 22). Prinsip kunci: sharding adalah pilihan terakhir, bukan langkah pertama.

#Partitioning: Saudara Kembar Sharding

Jangan tertukar: partitioning memecah tabel dalam satu database (bukan antar server). Tabel orders di-partition per bulan tetap berada di satu instance, tapi query yang menyentuh bulan tertentu hanya memindai partition itu:

CREATE TABLE orders (
    id BIGINT, created_at TIMESTAMPTZ, total_cents BIGINT
) PARTITION BY RANGE (created_at);
 
CREATE TABLE orders_2026_07 PARTITION OF orders
    FOR VALUES FROM ('2026-07-01') TO ('2026-08-01');
CREATE TABLE orders_2026_08 PARTITION OF orders
    FOR VALUES FROM ('2026-08-01') TO ('2026-09-01');

Manfaat: hapus data lama cukup dengan DROP TABLE orders_2026_01 (jauh lebih cepat dari DELETE), vacuum per partition, dan maintenance independen. Kita perdalam di episode 21 bersama materialized views.

#Menyusun Rencana Kapasitas

Rencana kapasitas yang baik adalah dokumen hidup:

1. Baseline: angka pertumbuhan data & beban dari 6-12 bulan terakhir.
2. Proyeksi: ukuran dan beban 12-24 bulan ke depan, dengan 3 skenario (konservatif, normal, agresif).
3. Titik aksi: ambang yang memicu tindakan (misal disk 70%, CPU p95 60% selama 2 minggu).
4. Pilihan strategi: kapan scale-up, kapan tambah replica, kapan partisi, kapan sharding.
5. Rencana biaya: perkiraan untuk tiap skenario — supaya bisa diajukan ke manajemen dengan angka.

Tambahkan jadwal review bulanan untuk membandingkan proyeksi vs kenyataan. Capacity planning bukan dokumen sekali jadi — ia dipelihara seperti database itu sendiri.

#Penutup

Inti yang harus dibawa pulang:

• Ukur baseline dulu (data, TPS, CPU/RAM/IO, koneksi, latensi) — keputusan tanpa angka adalah spekulasi.
• Scale-up untuk langkah cepat; scale-out (replicas → partition → sharding) untuk jangka panjang.
• Read replicas adalah strategi scale-out termurah — tapi kelola stale reads.
• Sharding itu mahal secara kompleksitas; pastikan benar-benar dibutuhkan.
• Rencana kapasitas = baseline + proyeksi + titik aksi + pilihan strategi + biaya, di-review bulanan.

Di episode 11 selanjutnya kita melakukan perjalanan berbahaya yang paling sering membuat DBA tegang: migration & upgrade — upgrade major version PostgreSQL, migrasi antar engine database, strategi zero-downtime migration, dan validasi data pasca-migrasi. Sampai jumpa di episode 11!