Belajar Cloud Architect - Data Architecture (Storage & DB)
Data adalah aset paling berharga di cloud, dan arsitekturnya paling sering salah. Episode ini memetakan pola storage object/block/file, membandingkan relational vs NoSQL berdasarkan pola akses, membedah data lake vs warehouse, dan merancang arsitektur data end-to-end untuk pipeline analytics
#Pendahuluan
Di episode 4 kita memilih compute, tetapi compute tanpa data hanyalah mesin kosong. Data architecture adalah bagian arsitektur yang paling sulit diubah setelah dibangun — pindah dari satu database ke database lain jauh lebih menyakitkan daripada mengganti runtime. Keputusan data harus benar dari awal.
Episode ini membangun kerangka berpikir data: tiga pola storage dasar, relational vs NoSQL, data lake vs warehouse, lalu merakit semuanya menjadi arsitektur data end-to-end. Tidak ada "database terbaik" — yang ada adalah database yang tepat untuk pola akses tertentu.
#Tiga Pola Storage Dasar
| Pola | Contoh Cloud | Karakter | Dipakai Untuk |
|---|---|---|---|
| Block | EBS, GCE Persistent Disk, Azure Disk | I/O per blok, melekat ke VM | OS, database pada instance |
| File | EFS, Filestore, Azure Files | Shared filesystem via NFS/SMB | Aplikasi bersama file, container multi-node |
| Object | S3, GCS, Azure Blob | Data tak terstruktur, HTTP API, skalabilitas hampir tak terbatas | Backup, gambar, data lake, static assets |
Note
Kesalahan klasik: memakai object storage untuk workload yang butuh random write kecil (seperti database) atau memakai block storage untuk menyimpan file backup jangka panjang. Baca pola akses — object storage untuk data yang ditulis sekali dan banyak dibaca; block/file untuk data yang sering di-modify in-place.
#Relational vs NoSQL
#Kapan Memilih Relational (RDBMS)
Relational database (PostgreSQL, MySQL, SQL Server) menawarkan ACID transactions — atomik, konsisten, terisolasi, durable. Ini krusial untuk data yang butuh integritas ketat: transaksi keuangan, stok, akuntansi. Pola aksesnya terstruktur dengan schema tetap dan join antar-tabel.
BEGIN;
UPDATE account SET balance = balance - 100 WHERE id = 1;
UPDATE account SET balance = balance + 100 WHERE id = 2;
COMMIT;Query di atas menjamin: jika salah satu update gagal, semuanya dibatalkan. Tanpa ACID, transfer uang bisa kehilangan 100 di tengah jalan.
#Kapan Memilih NoSQL
NoSQL mengorbankan sebagian konsistensi/struktur demi skala dan kecepatan dalam pola akses tertentu:
| Jenis | Contoh | Terbaik Untuk |
|---|---|---|
| Key-value | DynamoDB, Redis | Caching, sesi, lookup cepat |
| Document | MongoDB, Cosmos DB | Data semi-terstruktur, schema fleksibel |
| Columnar | Bigtable, Cassandra | Write besar, time-series, wide table |
| Graph | Neptune, Neo4j | Relasi kompleks (sosial, rekomendasi) |
Aturan praktis: mulai dari relational, pindah ke NoSQL hanya saat pola akses terbukti tidak cocok dengan relational — bukan karena "biar keren". Trade-off ini persis topik episode 3 (latency vs consistency).
#Data Lake vs Warehouse vs Lakehouse
Pernah ada perdebatan besar: simpan data mentah apa adanya, atau simpan yang sudah terstruktur? Jawaban modernnya: keduanya.
| Konsep | Isi | Dipakai Untuk |
|---|---|---|
| Data Lake | Data mentah, format apa pun (raw) | Eksplorasi, machine learning, backup lengkap |
| Data Warehouse | Data terstruktur, sudah dimodelkan | Reporting bisnis, BI, analitik cepat |
| Lakehouse | Gabungan keduanya (lake + tabel terstruktur) | Fleksibilitas lake + performa warehouse |
Arsitektur umum: object storage sebagai data lake (murah, tak terbatas), lalu layer analytics membaca darinya untuk membuat tabel terstruktur yang dipakai BI tools.
#Praktik: Arsitektur Data End-to-End
Merakit semuanya untuk pipeline analytics e-commerce:
Alur di atas menunjukkan prinsip arsitektur data modern:
- Transaction store (RDS) melayani aplikasi dengan ACID.
- Event stream menangkap perilaku user secara real-time.
- Data lake menampung data mentah dari kedua sumber — murah dan lengkap.
- Data warehouse menyajikan data terstruktur untuk BI dan ML.
Pemisahan peran ini membuat tiap layer bisa diskalakan dan dioptimasi secara independen. Detail pipeline streaming akan kita perdalam di episode 13.
#Penutup
Inti yang harus dibawa pulang:
- Tiga pola storage: block (database/VM), file (shared), object (data lake/backup).
- Relational untuk integritas ACID; NoSQL untuk pola akses spesifik yang terbukti cocok.
- Data lake = data mentah; warehouse = data terstruktur; lakehouse = gabungan.
- Arsitektur data modern memisahkan transaction store, event stream, lake, dan warehouse.
Di episode 6 selanjutnya kita akan membahas networking architecture — desain VPC, multi-AZ & multi-region, segmentasi jaringan, serta koneksi hybrid. Sampai jumpa di episode 6!