Belajar Cloud Computing - Non-Relational (NoSQL) & In-Memory Databases

#Pendahuluan

Di episode 9 kita membahas database relasional: RDBMS managed, high availability multi-AZ, hingga distributed SQL seperti Aurora dan Spanner. Relasional unggul karena skema ketat, transaksi ACID, dan bahasa query yang universal. Namun makin banyak aplikasi modern yang datanya tidak nyaman dipaksa masuk ke tabel dengan kolom tetap — data yang bentuknya berubah-ubah, dibaca dengan latensi sangat rendah, atau harus melayani jutaan request per detik.

Episode 10 ini membahas kebalikannya: NoSQL dan in-memory databases. Kalian akan belajar kapan relasional mulai tidak cukup, empat model data NoSQL, peran cache in-memory, layanan managed di AWS, GCP, dan Azure, serta praktik menulis item JSON dan menyimpannya ke DynamoDB lewat CLI.

#Kapan Relasional Mulai Tidak Cukup

Tidak ada database yang buruk — yang ada adalah database yang salah tempat. Relasional hebat untuk data yang terstruktur, berelasi, dan butuh konsistensi ketat seperti transaksi keuangan. Ia kesulitan pada tiga kondisi:

• Skala besar: jutaan item dengan query yang harus berespons dalam milidetik.
• Skema dinamis: atribut baru muncul sewaktu-waktu, seperti profil pengguna yang bisa bertambah field kapan saja.
• Volume baca ekstrem: data yang sama dibaca ribuan kali — di sinilah cache, bukan query berulang, menjadi jawaban.

#Empat Model Data NoSQL

Kata "NoSQL" menyatukan empat keluarga yang sangat berbeda. Menyamakan semuanya adalah kesalahan pemula — pilihan kalian harus bergantung pada pola akses aplikasi.

#Document

Data disimpan sebagai dokumen berformat JSON atau BSON, seperti satu entri kamus yang bisa bersarang. Satu dokumen bisa berisi nama, alamat, dan daftar pesanan sekaligus — tidak perlu join. Cocok untuk profil pengguna, katalog produk, dan konten CMS. Perwakilannya: MongoDB, Firestore, Cosmos DB.

#Key-Value

Model paling sederhana: satu key unik yang memetakan ke satu value, seperti kamus raksasa. Pembacaan selalu melalui key — sangat cepat dan sangat terukur, tetapi tanpa kemampuan query kompleks. Cocok untuk sesi pengguna, fitur flag, dan data referensi kecil. Perwakilannya: DynamoDB dalam mode sederhana, Redis, Memcached.

#Wide-Column

Data disimpan per baris, tetapi setiap baris boleh memiliki kolom berbeda-beda — gabungan antara tabel dan dokumen. Cocok untuk analitik dan data time-series yang besar, tempat satu baris menyimpan jutaan nilai dengan timestamp. Perwakilannya: Cassandra, Bigtable.

#In-Memory

Data disimpan sepenuhnya di RAM, bukan disk. Hasilnya: pembacaan dalam mikrodetik hingga milidetik. Keluarga ini berbeda secara fundamental — tujuannya bukan menyimpan data utama, melainkan mempercepat data yang sering dibaca. Perwakilannya: Redis, Memcached.

#In-Memory Cache: Mengapa dan Kapan

Cache in-memory ada karena satu alasan sederhana: banyak query database berulang-ulang menjawab pertanyaan yang sama. Setiap kali aplikasi membaca profil yang sama seratus kali per detik, database mengulang pekerjaan yang hasilnya identik.

Pola klasiknya disebut cache-aside: aplikasi mengecek cache dulu; jika ada, langsung dipakai (cache hit); jika tidak ada, ambil dari database, simpan ke cache, lalu kembalikan (cache miss). Setiap item diberi TTL (time to live) — masa kedaluwarsa — sehingga data tidak basi selamanya.

Bayangkan warung kopi yang sering ditanya "menu apa saja hari ini?" — melayani pertanyaan itu dari papan menu (cache) jauh lebih cepat daripada membuka kulkas setiap kali ditanya (database). Itulah esensi caching.

#Layanan Managed NoSQL dan Cache di Cloud

Ketiga cloud besar menyediakan semua keluarga di atas sebagai layanan terkelola — kalian tidak menginstall apa pun, hanya membuat resource dan memanggil API-nya:

• AWS: DynamoDB (key-value dan document), ElastiCache (Redis dan Memcached).
• GCP: Firestore (document), Bigtable (wide-column), Memorystore (Redis dan Memcached).
• Azure: Cosmos DB (multi-model: document, key-value, wide-column, graph), Azure Cache for Redis.

#Praktik: Item JSON DynamoDB dan Perintah CLI

DynamoDB menyimpan data sebagai item, dan setiap item adalah koleksi atribut. Kekuatannya terletak pada skema fleksibel: item berikut memiliki atribut berbeda-beda dalam tabel yang sama — sesuatu yang mustahil di tabel relasional.

{
  "pk": { "S": "user#42" },
  "sk": { "S": "profile" },
  "name": { "S": "Arman" },
  "age": { "N": "29" },
  "active": { "BOOL": true },
  "skills": { "SS": ["cloud", "devops"] },
  "address": {
    "M": {
      "city": { "S": "Jakarta" },
      "zip": { "S": "12345" }
    }
  }
}

Setiap atribut ditulis dengan tipe datanya: S untuk string, N untuk number, BOOL untuk boolean, SS untuk set of strings, dan M untuk map bersarang. Item lain dalam tabel yang sama bisa saja hanya berisi dua atribut — tidak ada schema constraint di level tabel.

Menyimpan item ini ke tabel users dilakukan dengan aws dynamodb put-item:

aws dynamodb put-item \
  --table-name users \
  --item '{
    "pk": { "S": "user#42" },
    "sk": { "S": "profile" },
    "name": { "S": "Arman" },
    "age": { "N": "29" },
    "skills": { "SS": ["cloud", "devops"] }
  }'

Perhatikan pola yang dianjurkan di DynamoDB: pasangan pk dan sk adalah partition key dan sort key — inilah "alamat" item di dalam tabel. Desain key yang baik meniru cara aplikasi mengakses data: jika aplikasi selalu membaca profil berdasarkan ID pengguna, maka pk berisi ID itu.

#Komparasi Layanan NoSQL dan Cache Big 3

Konsep di balik semua produk ini identik: skema fleksibel untuk NoSQL, dan penyimpanan di RAM untuk cache. Berpindah antar provider berarti belajar API dan penamaan baru, bukan belajar ulang konsep. Nilai paling berharga di pasar kerja adalah kemampuan menilai kapan memakai document, key-value, wide-column, atau cache — bukan menghafal tombol di satu konsol.

#Penutup

Pada episode 10 ini kalian telah memahami kapan NoSQL diperlukan — skala besar, skema dinamis, dan pola baca ekstrem — berikut empat model datanya: document, key-value, wide-column, dan in-memory. Kalian juga mengenal layanan managed di tiga cloud — DynamoDB, Firestore, Bigtable, Cosmos DB, ElastiCache, Memorystore, dan Azure Cache for Redis — serta praktik menulis item JSON dan menyimpannya lewat aws dynamodb put-item.

Kunci yang harus dibawa pulang:

• Pilih berdasarkan pola akses, bukan nama produk — empat model data NoSQL menjawab empat kebutuhan yang berbeda.
• Cache mempercepat, tidak menyimpan — in-memory cache melindungi database, bukan menggantikannya.
• NoSQL bukan pengganti relasional — ia pilihan lain untuk konteks yang berbeda, dan engineer yang baik menguasai keduanya.

Semua yang kita bahas sejauh ini masih mengharuskan kalian berpikir tentang server — berapa kapasitas, berapa instance, berapa node. Episode 11 akan membalik logika itu sepenuhnya: Serverless & Function as a Service (FaaS) — aplikasi yang berjalan hanya saat ada event, skala dari nol ke jutaan, dan tagihan dihitung per eksekusi dalam milidetik.