Belajar MongoDB - Sejarah, Konsep NoSQL & Mengapa Memilih MongoDB

#Pendahuluan

Di episode 0 kalian sudah menyiapkan environment MongoDB dengan rapi. Sekarang saatnya memahami mengapa database ini ada di dunia, dan mengapa kalian harus repot-repot mempelajarinya. Banyak developer yang langsung menulis query tanpa memahami paradigma di baliknya — dan akhirnya memakai MongoDB seperti memakai MySQL, sebuah kesalahan klasik yang berujung pada schema buruk dan performa jeblok.

Episode 1 ini adalah fondasi konseptual. Roadmap-nya: pertama kita bedah keterbatasan RDBMS klasik yang memunculkan gerakan NoSQL, kedua kita pahami empat kategori NoSQL dan posisi MongoDB di dalamnya, ketiga kita telusuri sejarah kelahiran MongoDB, keempat kita bahas alasan kuat mengapa memilih MongoDB, dan terakhir kita bandingkan MongoDB dengan tiga database populer lainnya. Akhir episode, kalian akan punya jawaban siap pakai saat ditanya "kenapa sih pakai MongoDB?"

#Evolusi Database dan Munculnya Paradigma NoSQL

#Keterbatasan RDBMS pada Era Modern

Selama puluhan tahun, RDBMS (Relational Database Management System) seperti MySQL dan PostgreSQL adalah standar penyimpanan data. Konsepnya indah: data dinormalisasi ke dalam tabel-tabel berelasi dengan primary key dan foreign key, lalu dijamin konsisten lewat ACID transactions. Namun di era web modern, muncul tiga tekanan yang membuat RDBMS terasa berat:

• Big Data volume — data terabyte yang harus diproses cepat; relasi antar tabel yang kompleks membuat query melambat.
• High write throughput — workload seperti log, event, dan analytics menulis jutaan baris per hari; lock dan transaction overhead RDBMS menjadi bottleneck.
• Schema yang sering berubah — produk digital berubah cepat; ALTER TABLE untuk setiap perubahan kolom adalah birokrasi yang menyakitkan.

RDBMS menjawab masalah dengan scaling vertikal: menaikkan CPU, RAM, dan storage satu server. Pendekatan ini mahal dan ada batas fisiknya. Dunia modern butuh scaling horizontal: menambah server biasa-biasa saja dalam jumlah banyak, dan membiarkan software membagi data di antara mereka.

Istilah NoSQL muncul sekitar akhir tahun 2000-an sebagai gerakan yang menantang dogma relational. Perlu diluruskan: NoSQL bukan berarti "no SQL" secara harfiah — banyak yang mengartikannya sebagai "Not Only SQL". Intinya, NoSQL menawarkan trade-off yang berbeda: mengorbankan sebagian konsistensi ketat dan struktur kaku demi skalabilitas, fleksibilitas, dan kecepatan.

#Kategori NoSQL

NoSQL bukan satu teknologi, melainkan payung untuk empat keluarga besar, masing-masing mengoptimalkan hal yang berbeda:

MongoDB masuk ke kategori Document Store. Dokumennya menyimpan seluruh data terkait dalam satu struktur hierarkis — sangat mirip cara aplikasi modern merepresentasikan objek di memory. Perhatikan tabel di atas: setiap kategori menang satu domain. Key-Value juara kecepatan akses sederhana, Wide-Column juara tulis massal, Graph juara relasi rumit, dan Document juara fleksibilitas data semi-terstruktur.

#Sejarah MongoDB

MongoDB lahir dari perusahaan bernama 10gen (sekarang MongoDB Inc.) yang didirikan pada tahun 2007. Menariknya, 10gen awalnya bukan perusahaan database — mereka membangun platform cloud sebagai service (PaaS), mirip dengan konsep awal Heroku. Saat mengembangkan produk tersebut, mereka kesulitan mencari database yang mampu menyimpan data semi-terstruktur dan diskalakan horizontal dengan mudah. Database yang ada saat itu terasa kaku untuk kebutuhan mereka.

Jadi mereka memutuskan membangun database sendiri. Nama "Mongo" terinspirasi dari kata Inggris "humongous" — mencerminkan ambisi untuk menangani dataset yang sangat besar. MongoDB pertama kali dirilis sebagai open-source pada tahun 2009, dan dengan cepat menarik perhatian developer karena kemudahan penggunaannya: JSON-like documents yang terasa natural, tanpa perlu mendefinisikan schema terlebih dahulu.

Kunci sejarah yang perlu diingat: MongoDB bukan dibuat oleh akademisi di laboratorium, melainkan oleh engineer yang punya masalah nyata di lapangan. Ini menjelaskan mengapa MongoDB sangat praktis dan berorientasi developer — dokumentasi bagus, query yang intuitif, dan integrasi bahasa pemrograman yang ekstensif. Sepanjang perjalanannya, MongoDB terus menambah kemampuan kelas enterprise: ACID multi-document transactions (4.0), replica set bawaan, sharding native, dan saat ini dikenal sebagai salah satu database paling populer di dunia.

#Mengapa Memilih MongoDB

#Flexible Schema (Schemaless)

Inilah pembeda terbesar dari RDBMS. Dalam satu collection MongoDB, setiap dokumen boleh memiliki struktur yang berbeda — satu dokumen products punya field weight, dokumen lain punya field color. Kalian tidak perlu ALTER TABLE untuk menambahkan field baru. Fleksibilitas ini sangat berharga untuk data yang tidak seragam atau terus berkembang:

{
  "_id": "product-001",
  "name": "Kemeja Flanel",
  "category": "fashion",
  "size": ["S", "M", "L"]
}

{
  "_id": "product-002",
  "name": "Monitor 27 inch",
  "category": "elektronik",
  "specs": {
    "panel": "IPS",
    "refreshRate": "144Hz"
  }
}

Kedua dokumen hidup berdampingan dalam collection products tanpa masalah. Bagi produk fashion, field size relevan; bagi produk elektronik, field specs lebih bermakna. Inilah kekuatan flexible schema.

#Format BSON dengan Rich Data Types

MongoDB menyimpan data dalam format BSON (Binary JSON) — representasi biner dari JSON yang mendukung tipe data lebih kaya daripada JSON murni: Date, Decimal128 untuk presisi uang, Binary untuk file, ObjectId, hingga UUID. Kita akan membedah BSON secara detail di episode 2.

#Horizontal Scalability Native

MongoDB dirancang untuk dipecah ke banyak server sejak awal. Replica Set untuk high availability (episode 15) dan Sharding untuk membagi dataset lintas server (episode 16) adalah fitur bawaan, bukan add-on. Inilah alasan MongoDB menjadi pilihan utama untuk aplikasi yang harus tumbuh tanpa migrasi besar-besaran.

#Performa Tinggi untuk Workload Tertentu

Dengan data yang diletakkan berdekatan dalam satu dokumen, MongoDB bisa mengambil data lengkap dalam satu query tanpa JOIN. Untuk workload read-heavy dengan data semi-terstruktur, performanya unggul jauh dari RDBMS yang harus menggabungkan banyak tabel.

#Perbandingan MongoDB vs PostgreSQL vs DynamoDB vs Firestore

Agar keputusan kalian berdasar data, berikut perbandingan keempat database paling sering dipakai:

#Penutup

Pada episode 1 ini kalian telah memahami latar belakang kelahiran NoSQL sebagai jawaban atas keterbatasan RDBMS di era big data — volume raksasa, write throughput tinggi, dan schema yang berubah cepat. Kalian juga mengenali empat kategori NoSQL dan posisi MongoDB sebagai document store, menelusuri sejarah MongoDB dari 10gen tahun 2007 hingga rilis open-source 2009, memahami keunggulan flexible schema, format BSON, horizontal scaling native, serta membandingkan MongoDB dengan PostgreSQL, DynamoDB, dan Firestore.

Inti yang harus dibawa pulang:

• NoSQL lahir karena RDBMS sulit diskalakan horizontal dan kaku terhadap perubahan schema.
• Document Store memodelkan data seperti objek aplikasi — natural dan fleksibel.
• MongoDB diciptakan 10gen karena kebutuhan nyata, dirilis open-source 2009, dan bernama dari kata "humongous".
• Flexible schema, rich BSON types, dan sharding native adalah pembeda utama MongoDB.
• Tidak ada database yang terbaik untuk semua kasus; pilih berdasarkan workload dan kebutuhan.

Di episode 2 berikutnya kita masuk ke jantung MongoDB: konsep dasar dan struktur data. Kalian akan memahami hierarki Database > Collection > Document > Field, membedah format BSON dan tipe data kaya di dalamnya, serta mengupas _id dan ObjectId 12-byte yang unik di setiap dokumen. Sampai jumpa di episode 2, dan bersiaplah menulis struktur data pertama kalian!