Belajar Database Administrator - Arsitektur Database & Storage

#Pendahuluan

Di episode 1 kita memahami siapa DBA; sekarang kita masuk ke apa yang ia kelola. Sebelum mengatur shared_buffers, membuat index, atau memilih engine, kalian harus paham arsitektur database: bagaimana data disimpan di disk, kenapa transaction tidak pernah kehilangan data, dan mengapa query dengan index jauh lebih cepat.

Analogi sederhana: database adalah perpustakaan. Relasional = rak berlabel rapi dengan kartu katalog (index), dokumen NoSQL = kotak arsip fleksibel tanpa format wajib, dan WAL adalah buku catatan yang selalu ditulis dulu sebelum isi rak diubah — sehingga kalau listrik mati, pustakawan tahu persis di mana terakhir berhenti. Episode ini membedah ketiganya.

#Relasional vs NoSQL

Perbedaan paling mendasar bukan pada "teknologi", melainkan pada model data dan konsistensi:

Poin penting bagi DBA: bukan soal mana yang "lebih baik", tapi mana yang cocok dengan workload. Bank butuh relasional + ACID; sistem rekomendasi yang menyimpan profil pengguna fleksibel cocok dengan dokumen; sesi aplikasi yang perlu dibaca dalam mikrodetik cocok dengan Redis. DBA profesional fasih keduanya.

#OLTP vs OLAP

Database juga dibedakan oleh tipe beban kerjanya:

• OLTP (Online Transaction Processing): banyak transaksi kecil dan cepat — order, payment, login. Karakteristiknya: random I/O, query pendek, concurrent tinggi, konsistensi kuat. PostgreSQL, MySQL, MongoDB di sini.
• OLAP (Online Analytical Processing): sedikit query besar yang menyapu jutaan baris untuk agregasi — laporan, dashboard bisnis. Karakteristiknya: sequential scan besar, columnar storage, batch. Snowflake, BigQuery, ClickHouse di sini.

Mengapa DBA perlu membedakan? Karena keputusan administrasi sangat berbeda: OLTP dituning dengan index + buffer pool + replica baca; OLAP dituning dengan partitioning, materialized view, dan columnar compression. Memperlakukan keduanya sama adalah kesalahan klasik.

#Struktur Penyimpanan: Halaman, B-tree, dan Index

Database relasional menyimpan data dalam page (blok) berukuran tetap — PostgreSQL 8 KB, MySQL/InnoDB 16 KB. Page disusun sebagai heap (data acak) plus index yang menyusun pointer secara terstruktur.

Index default di kedua engine adalah B-tree. Mengapa B-tree? Karena ia menjaga data tetap terurut dan memungkinkan pencarian, insert, dan delete dalam O(log N):

• 1 juta baris tanpa index → scan linear, bisa ratusan ribu page dibaca.
• Dengan B-tree → sekitar log₂(1.000.000) ≈ 20 langkah dari root ke leaf.

Inilah alasan satu index yang tepat bisa mempercepat query dari 5 detik menjadi 5 milidetik. Kita akan mengoptimalkan index secara praktis di episode 4 dan 6.

#Write-Ahead Log (WAL) dan Durability

Konsep paling penting dalam arsitektur storage adalah WAL (Write-Ahead Log). Aturan emasnya: data tidak boleh ditulis ke halaman utama sebelum catatan perubahannya ditulis ke log terlebih dahulu. Alurnya:

1. Aplikasi mengirim UPDATE users SET balance = balance - 100 WHERE id = 1.
2. Perubahan dicatat sebagai log record di WAL (dengan fsync untuk menjamin sampai ke disk).
3. Data halaman di buffer pool diperbarui di memori.
4. Saat checkpoint, halaman kotor dibersihkan ke file data utama.

Keuntungannya dua arah: (a) durability — jika crash, database memutar ulang (replay) WAL saat startup dan tidak ada commit yang hilang; (b) performansi — menulis log kecil berurutan (sequential) jauh lebih cepat daripada menulis random ke banyak halaman besar. Inilah juga fondasi dari backup point-in-time (PITR) yang kita bahas di episode 5.

#Arsitektur Internal PostgreSQL

Saat psql terhubung, inilah anatomi PostgreSQL:

• Postmaster: proses utama yang menerima koneksi dan mem-fork backend process untuk tiap koneksi.
• Backend process: satu per koneksi, mengeksekusi query — ini sebabnya "thousands of connections" bisa memakan ribuan proses (masalah yang kita tangani di episode 3 dengan connection pooler).
• Shared memory: shared_buffers (cache halaman), wal_buffers, dan lock table yang dipakai semua backend.
• WAL: file di pg_wal/ — sumber PITR dan replikasi streaming.
• Data directory: PGDATA berisi base/ (tabel & index), pg_wal/, pg_stat/, dan lain-lain.

$ ls /var/lib/postgresql/16/main/
base  pg_wal  pg_stat  pg_tblspc  postgresql.conf  pg_hba.conf  ...

Setiap database adalah subdirektori di base/; setiap tabel dan index adalah file terpisah. Pemahaman ini berguna saat kapasitas disk menipis dan kalian perlu tahu file mana yang membesar.

#Arsitektur Internal MySQL

MySQL/InnoDB sedikit berbeda:

• Instance: mysqld dengan thread pool (bukan proses per koneksi) — lebih hemat resource untuk koneksi banyak.
• Storage engine: arsitektur plugin. InnoDB adalah default (transaksi, foreign key, crash recovery). MyISAM lama tanpa transaksi — hindari untuk produksi.
• Buffer pool: cache halaman (innodb_buffer_pool_size), setara shared_buffers.
• Redo log: file ib_logfile* — setara WAL.
• Binlog: log pernyataan perubahan untuk replikasi dan PITR — wajib diaktifkan untuk backup point-in-time.

Perbedaan praktis yang terlihat sebagai DBA: SHOW PROCESSLIST untuk melihat koneksi MySQL, vs pg_stat_activity di PostgreSQL; dan cara keduanya menangani concurrent writes berbeda (MVCC di keduanya, tapi detail isolation-nya tidak identik).

#Pitfall Konseptual

1. Menganggap buffer pool hanya "cache bonus". Sebenarnya ia adalah area kerja utama — kalau terlalu kecil, setiap query menyentuh disk dan latensi meledak. Tuning-nya dibahas episode 6.
2. Menyetel shared_buffers terlalu besar. Di Linux, lebih dari ~30% RAM malah memicu kontensi I/O saat checkpoint. Ada batas wajar — bukan "makin besar makin baik".
3. Melupakan perbedaan WAL vs binlog. Di PostgreSQL, replikasi dan PITR memakai WAL yang sama; di MySQL, replikasi memakai binlog sedangkan crash recovery memakai redo log. Kalau mengoperasikan keduanya, jangan tertukar.

#Penutup

Inti yang harus dibawa pulang:

• Relasional = struktur + ACID; NoSQL = fleksibilitas + skala horizontal; OLTP vs OLAP menentukan strategi tuning.
• Index B-tree membuat pencarian O(N) menjadi O(log N) — fondasi semua optimasi query.
• WAL/redo log adalah jaminan durability dan bahan baku PITR + replikasi.
• PostgreSQL: proses per koneksi, shared_buffers, PGDATA. MySQL: thread pool, innodb_buffer_pool_size, binlog.

Di episode 3 selanjutnya kita masuk ke instalasi & konfigurasi dasar — mem-bootstrap PostgreSQL dan MySQL produksi-ready: postgresql.conf dan my.cnf yang benar, manajemen user & privilege, serta connection pool dengan pgbouncer. Pastikan lab episode 0 sudah menyala, karena mulai sekarang praktiknya nyata. Sampai jumpa di episode 3!