Belajar Database Administrator - NoSQL & Specialized DB Ops

#Pendahuluan

Tidak semua data cocok dijadikan tabel. MongoDB, Redis, dan Elasticsearch menangani pola data yang berbeda — dokumen fleksibel, cache cepat, dan pencarian teks penuh. Di episode 2 kita tahu perbedaan modelnya; sekarang kita mengoperasikannya. Kabar baiknya: pola pikir DBA (backup, HA, monitoring, kapasitas) tetap sama — yang berubah hanyalah implementasinya.

Pegangan episode ini: jangan takut NoSQL, tapi jangan juga asal pakai. Setiap engine punya keunggulan dan jebakannya sendiri; tugas DBA adalah tahu keduanya.

#MongoDB: Replica Set & Sharding

#Replica Set

Replica set MongoDB setara primary + replica di episode 8, ditambah mekanisme pemilihan otomatis. Inisialisasi tiga node:

Inisialisasi replica set

// di mongosh
rs.initiate({
  _id: "rs0",
  members: [
    { _id: 0, host: "mongo-1:27017" },
    { _id: 1, host: "mongo-2:27017" },
    { _id: 2, host: "mongo-3:27017", arbiterOnly: true }
  ]
})

Primary menerima tulis; secondary mereplikasi oplog dan bisa menerima baca (read preference).
Arbiter (opsional) tidak menyimpan data — hanya hak suara agar pemilihan primary selalu mayoritas (3 node ganjil).
Failover otomatis: kalau primary mati, secondary terpilih jadi primary dalam hitungan detik.

Periksa kesehatan replica set (padanan pg_stat_replication):

Cek status replica set

rs.status()   // periksa health member

#Sharding

Sharding MongoDB setara episode 10: data dipecah per shard key. Arsitekturnya tiga komponen: mongos (router query), config servers (metadata), dan shards (chunk data).

Aktifkan sharding

sh.enableSharding("appdb")
sh.shardCollection("appdb.orders", { user_id: 1 })

Pilihan shard key menentukan segalanya: key dengan kardinalitas rendah (misal status dengan 3 nilai) menciptakan jumbo chunks yang macet. user_id (high cardinality, terdistribusi merata) jauh lebih baik — pelajaran yang sama dengan episode 10.

#Redis: Persistence & Eviction

Redis adalah in-memory database — kecepatan mikrodetik, tetapi data tinggal di RAM. Ini menimbulkan dua risiko yang harus dikelola DBA.

Persistence (data disimpan ke disk):

RDB (snapshot): file dump tiap interval — ringan, tapi bisa kehilangan detik-detik terakhir.
AOF (append-only file): setiap write dicatat — lebih tahan, biaya performa.
Kombinasi: AOF untuk durability + RDB untuk restore cepat.

Konfigurasi persistence Redis

redis-cli config set appendonly yes
redis-cli config set appendfsync everysec
redis-cli config set save "900 1 300 10 60 10000"

Eviction policy — apa yang terjadi saat RAM penuh:

Policy	Perilaku	Cocok untuk
`noeviction`	Tolak write baru	Cache wajib konsisten
`allkeys-lru`	Evict data paling lama diakses	Cache umum
`volatile-lru`	Evict hanya key dengan TTL	Campuran cache + data
`allkeys-random`	Evict acak	Distribusi merata

maxmemory dan policy ini wajib disetel sejak awal — kalau tidak, OOM killer OS bisa membunuh proses Redis dan mengambil cache session seluruh aplikasi bersamanya.

Warning

Redis yang dipakai sebagai cache biasanya boleh kehilangan data. Tapi jika Redis dipakai untuk antrian job atau token — data "hilang saat restart" adalah incident (episode 20). Sebelum menyetujui arsitektur, tanyakan: apa yang terjadi kalau semua data Redis hilang sekarang? Jawaban menentukan policy persistence yang kalian setel.

#Elasticsearch: Pencarian & Analitik

Elasticsearch adalah database search/analitik berbasis inverted index — sangat cepat untuk LIKE-yang-tidak-mungkin di SQL (bayangkan pelajaran episode 4 dan 21: B-tree tidak dirancang untuk pencarian teks bebas).

Konsep operasional yang wajib dikuasai:

Index = kumpulan dokumen (setara tabel); shard = pecahan index; replica = salinan shard.
Mapping = skema (analog: jangan ubah mapping di index berjalan tanpa reindex).
Rollover/ILM: index harian logs-2026.08.16 + lifecycle untuk menutup/hapus index tua — setara partition maintenance di episode 10.

Periksa kesehatan cluster

curl -s localhost:9200/_cluster/health
# {"status":"yellow","number_of_nodes":3, ...}

Warna green = semua shard primary+replica aktif; yellow = ada replica tak terassign (biasanya jumlah node kurang); red = ada primary shard hilang — indikasi kehilangan data, tangani segera.

DBA skill yang berlaku: shard count ditentukan sekali saat index dibuat (seperti shard key MongoDB), backup memakai snapshot API (bukan tar file!), dan monitoring node (heap, disk watermark) wajib — disk > 85% membuat Elasticsearch menolak write demi melindungi dirinya.

#Table Perbandingan Mental Model

Aspek	PostgreSQL	MongoDB	Redis	Elasticsearch
Model	Tabel/SQL	Dokumen	Key-value	Inverted index
HA	Streaming repl. + repmgr	Replica set	Sentinel/Cluster	Shard replica
Backup	pg_dump/WAL	mongodump/oplog	RDB/AOF	Snapshot API
Monitoring	pg_stat_activity	rs.status()	INFO/monitor	_cluster/health
Skala	Replicas/sharding	Sharding native	Cluster	Shard rebalance

Pahami tabel ini sebagai peta: alur operasional yang sama, sintaks yang berbeda. Kemampuan kalian berpindah-pindah engine itulah yang membuat kalian berharga sebagai DBA — bukan hafalan satu tool.

#Penutup

Inti yang harus dibawa pulang:

MongoDB: replica set (3 node ganjil) untuk HA; sharding butuh shard key high-cardinality.
Redis: pilih persistence (RDB/AOF) sesuai kebutuhan data, setel maxmemory + eviction policy sejak awal.
Elasticsearch: shard/replica ditentukan di awal, backup via snapshot API, perhatikan disk watermark.
Pola pikir DBA (backup, HA, monitoring, kapasitas) berlaku universal — hanya implementasinya yang berbeda.

Di episode 14 selanjutnya kita otomasi segalanya: automation & IaC — provisioning database dengan Terraform, konfigurasi state dengan Ansible, dan database-as-code sehingga seluruh setup kita dari episode 3 sampai 12 bisa diulang dengan satu perintah. Sampai jumpa di episode 14!