SQL vs NoSQL: pilih dari pola akses, bukan dari tren
Lima keluarga database (relasional, key-value, document, wide-column, graph), ACID vs BASE, dan kalimat yang aman diucapkan di interview
Sebelumnya, lesson 0007 menutup modul Skalabilitas: server aplikasi sudah stateless dan bisa diperbanyak di belakang load balancer. Sekarang bottleneck pindah ke tempat state disimpan, yaitu database. Modul Data mulai dari pertanyaan yang hampir selalu muncul di langkah 3 (API + data model): "database apa yang Anda pakai, dan kenapa?"
1. Lima keluarga database
"NoSQL" bukan satu jenis database, tapi payung untuk beberapa model data. Yang membedakan adalah bentuk data dan cara Anda mengaksesnya.
| Keluarga | Model data | Akses yang cepat | Contoh |
|---|---|---|---|
| Relasional (SQL) | tabel, baris, kolom, foreign key | query bebas, JOIN, transaksi multi-tabel | PostgreSQL, MySQL |
| Key-value | key → value (blob) | get/put satu key | Dynamo, Redis |
| Document | dokumen JSON-like bersarang | ambil/simpan satu dokumen utuh | MongoDB |
| Wide-column | row key → banyak kolom, terurut per row key | scan rentang row key, write volume besar | Bigtable, HBase, Cassandra |
| Graph | node, relationship, property | traversal relasi berlapis (teman dari teman) | Neo4j |
- Key-value. Paper Dynamo menulis: "There are many services on Amazon's platform that only need primary-key access to a data store", misalnya shopping cart dan session management; untuk pola itu, "the common pattern of using a relational database would lead to inefficiencies and limit scale and availability." [1]
- Document. MongoDB menyimpan "data records as BSON documents", yaitu representasi biner dari JSON, dan satu dokumen dibatasi 16 mebibytes. [2] Cocok untuk data yang dibaca utuh sebagai satu objek (profil produk dengan atribut berbeda per kategori).
- Wide-column. "A Bigtable is a sparse, distributed, persistent multi-dimensional sorted map", di-index oleh row key, column key, dan timestamp, dan data disimpan "in lexicographic order by row key". [3] Cocok untuk time series, log event, dan data yang diakses per rentang key.
- Graph. Neo4j "stores data as nodes, relationships, and properties instead of in tables or documents". [4] Cocok kalau query utamanya traversal (rekomendasi, deteksi fraud lewat relasi).
Cara memilihnya: mulai dari pertanyaan "query apa yang paling sering dan paling penting?", bukan dari nama produk.
Latihan 1 — Keluarga database
Jawab tanpa scroll ke atas. Soal yang sama akan muncul lagi, diacak, di review 0019.
Kuis di lesson ini adalah feedback cepat, bukan bukti penguasaan; yang dicatat hanya hasil review 0019.
2. ACID vs BASE
ACID (Atomicity, Consistency, Isolation, Durability) adalah jaminan transaksi di database relasional. Dokumentasi PostgreSQL merangkum intinya: transaksi "bundles multiple steps into a single, all-or-nothing operation"; langkah di tengah tidak terlihat oleh transaksi lain, dan kalau gagal, "none of the steps affect the database at all." [5] Seberapa ketat isolasinya bisa diatur: di PostgreSQL, "Read Committed is the default isolation level", dan Serializable "provides the strictest transaction isolation". [6]
BASE (Basically Available, Soft state, Eventually consistent) adalah singkatan untuk sikap sebaliknya: utamakan ketersediaan, terima bahwa replika boleh sempat berbeda, dan pastikan semuanya akhirnya sama. Dynamo adalah contoh aslinya: "Experience at Amazon has shown that data stores that provide ACID guarantees tend to have poor availability", sehingga Dynamo "does not provide any isolation guarantees and permits only single key updates", dan dirancang sebagai "eventually consistent data store; that is all updates reach all replicas eventually." [1]
Garis pembagi di interview: uang, stok, dan apa pun yang tidak boleh dobel atau hilang butuh transaksi ACID. Counter, feed, dan data yang boleh terlambat beberapa detik bisa hidup dengan eventual consistency. Detail model konsistensinya di lesson 0011.
Latihan 2 — ACID vs BASE
Jawab tanpa scroll ke atas.
3. Kapan tidak perlu
Komponen yang dibahas di sini adalah database NoSQL tambahan (atau mengganti database relasional dengan NoSQL).
- Sinyal yang membenarkan. Pola akses memang hanya per key atau per dokumen pada volume yang sudah terukur melampaui satu database relasional yang sudah di-tuning (index, query, scale vertical, read replica dari 0009); atau model datanya memang graph/time series dan query utamanya traversal atau scan rentang. Untuk 1.000 user aktif harian (di bawah 1 QPS rata-rata, lesson 0004), sinyal ini tidak ada.
- Biaya dan risiko. Kehilangan JOIN dan transaksi multi-baris: aturan integritas pindah ke kode aplikasi. Database kedua berarti backup, monitoring, dan keahlian operasional kedua. Eventual consistency membawa kelas bug baru (data lama terbaca).
- Alternatif lebih murah. Tetap di PostgreSQL. Atribut yang bervariasi bisa disimpan di kolom
jsonb, yang "significantly faster to process" daripadajsondan "also supports indexing" (GIN index untuk mencari key di dalam dokumen). [7] Satu database relasional + jsonb menutup sebagian besar kebutuhan "fleksibel seperti document store".
Kalimat untuk interview: "Untuk skala ini saya mulai dengan PostgreSQL karena butuh transaksi untuk order. Kalau write ke tabel event melewati kapasitas satu node setelah tuning, tabel itu kandidat pindah ke wide-column store."
Latihan lisan — Ucapkan dengan suara keras
Pasang timer dan jawab dengan suara keras, seolah sedang interview. Jangan buka jawaban contoh sebelum selesai.
"Untuk sistem e-commerce kecil (order, pembayaran, katalog produk), Anda memilih SQL atau NoSQL? Jelaskan alasannya dan kapan Anda akan berubah pikiran." (60 detik)
Bandingkan dengan jawaban contoh dan checklist-nya
"Saya mulai dari pola akses. Order dan pembayaran butuh transaksi all-or-nothing: kurangi stok, buat order, catat pembayaran harus berhasil semua atau tidak sama sekali. Itu ACID, jadi database relasional seperti PostgreSQL. Katalog punya atribut berbeda per kategori, tapi itu cukup dengan kolom jsonb yang bisa di-index, tanpa database kedua. NoSQL baru masuk kalau ada pola akses khusus yang terukur: misalnya event clickstream yang write-nya melewati kapasitas satu node setelah tuning, cocok ke wide-column; atau session dan cart yang hanya diakses per key, cocok ke key-value. Trade-off-nya: NoSQL melepas JOIN dan transaksi multi-key, dan banyak yang eventual consistent, jadi integritas pindah ke aplikasi. Untuk skala kecil satu PostgreSQL sudah cukup."
Checklist: apakah Anda menyebut…
- memilih dari pola akses (query dominan), bukan dari nama produk?
- order/pembayaran butuh transaksi ACID (all-or-nothing)?
- relasional sebagai default, atribut fleksibel cukup dengan jsonb?
- minimal satu keluarga NoSQL yang tepat beserta pola aksesnya (key-value, document, wide-column, graph)?
- biaya NoSQL: tanpa JOIN/transaksi multi-key, eventual consistency, operasional database kedua?
- membenarkan perubahan dengan angka atau metrik (mis. write melewati kapasitas satu node setelah tuning)?
Lulus jika minimal 4 dari 6.
Berikutnya, lesson 0009: sebelum mengganti database, perbaiki yang ada dulu. Index B-tree, lalu leader-follower replication dan read replica.
Istilah: GLOSSARY.md (bagian "Data") · Indeks: semua lesson System Design
Ada yang belum jelas? Tanyakan ke saya (agent) di terminal, misalnya: "kapan Cassandra lebih masuk akal daripada PostgreSQL untuk data time series?", "apa beda isolation level Read Committed dan Serializable dengan contoh?", atau "bagaimana mendesain kolom jsonb supaya query-nya tetap memakai index?"
Sumber: [1] DeCandia et al. 2007, Dynamo: Amazon's Highly Available Key-value Store (SOSP) · [2] MongoDB docs: Documents · [3] Chang et al. 2006, Bigtable: A Distributed Storage System for Structured Data (OSDI) · [4] Neo4j docs: What is a graph database · [5] PostgreSQL docs: Transactions (tutorial) · [6] PostgreSQL docs: Transaction Isolation · [7] PostgreSQL docs: JSON Types