KAL
Menu

Apa itu MongoDB ?

Mengenal MongoDB sebagai basis data dokumen, model data mirip JSON yang lentur, dan alasan penggunaannya.

Daftar isi

Topik ini memperkenalkan MongoDB sebagai basis data dokumen, mulai dari bentuk data yang disimpannya sampai alasan pemilihannya. Pembahasan mencakup model dokumen, aturan bentuk data yang lentur (schema), dan dampak keduanya terhadap kecepatan pengembangan aplikasi. Setelah membacanya, konsep dokumen, koleksi, dan schema dapat langsung dipakai sepanjang jalur ini.

Basis data dokumen#

MongoDB adalah basis data dokumen (document database), yaitu sistem penyimpanan data yang unit dasarnya berupa dokumen, bukan baris pada tabel. Satu dokumen menyimpan kumpulan pasangan nama dan nilai yang disebut field, dan bentuknya sangat mirip objek pada JSON. Karena struktur data pada banyak bahasa pemrograman juga berbentuk objek dan array, bentuk data pada kode aplikasi dan pada penyimpanan MongoDB menjadi hampir sama.

Secara internal, MongoDB menyimpan dokumen dalam format BSON (Binary JSON), yaitu representasi biner yang lebih ringkas dan lebih kaya tipe daripada teks JSON biasa. Saat perintah diketik di mongosh (shell resmi MongoDB) atau dikirim dari aplikasi, dokumen tetap tampak seperti JSON, sedangkan penyimpanan dan pertukaran data di jaringan memakai bentuk binernya. Perbedaan ini tidak terlihat saat menulis perintah, tetapi format BSON inilah yang membuat MongoDB dapat menyimpan tipe data yang tidak dimiliki JSON, seperti tanggal dan bilangan desimal presisi tinggi.

Dokumen-dokumen yang membahas tema yang sama dikelompokkan ke dalam koleksi (collection). Koleksi untuk catatan pengukuran suhu laboratorium, misalnya, dapat dinamai pengukuran. Koleksi berperan mirip tabel pada basis data relasional, tetapi tidak memaksakan daftar kolom yang sama pada semua isinya.

Dokumen sebagai satuan data#

Contoh berikut menyisipkan satu dokumen pengukuran ke dalam basis data bernama praktik. Perintah diketik di dalam mongosh, shell yang membaca dan menafsirkan perintah JavaScript. Pada blok pertama, perintah use praktik mengarahkan mongosh ke basis data tersebut, lalu dokumen disisipkan dengan insertOne(). Basis data dan koleksinya tidak perlu disiapkan terlebih dahulu karena MongoDB membuat keduanya begitu dokumen pertama disisipkan.

mongosh 
use praktik
db.pengukuran.insertOne({
  kodeSampel: "LBR-104",
  perangkat: "suhu-lab-1",
  suhuC: 24.6,
  kelembapanPersen: 61,
  dicatatPada: new Date("2026-01-12T09:30:00Z")
})
text Keluaran 
switched to db praktik
{
  acknowledged: true,
  insertedId: ObjectId('6ae85b772737ab44cfce5f47')
}

Gunakan findOne() tanpa argumen untuk membaca satu dokumen pertama dari koleksi.

mongosh 
db.pengukuran.findOne()
text Keluaran 
{
  _id: ObjectId('6ae85b772737ab44cfce5f47'),
  kodeSampel: 'LBR-104',
  perangkat: 'suhu-lab-1',
  suhuC: 24.6,
  kelembapanPersen: 61,
  dicatatPada: ISODate('2026-01-12T09:30:00.000Z')
}

Dokumen pada keluaran terdiri atas field dengan tipe yang beragam. Field kodeSampel dan perangkat berupa string, suhuC berupa bilangan desimal, kelembapanPersen berupa bilangan bulat, dan dicatatPada berupa tanggal. Field _id adalah penanda unik yang ditambahkan MongoDB, sedangkan field lainnya ditulis persis seperti pada perintah insertOne(). Sebuah field juga boleh berisi objek bersarang atau array, sehingga struktur data yang rumit tetap tercakup dalam satu dokumen tanpa dipecah ke tempat lain. Satu dokumen seperti ini berperan sama dengan satu baris pada tabel relasional, tetapi seluruh isinya berada dalam satu unit yang utuh.

Schema yang lentur#

Schema mengatur field apa saja yang dimiliki sebuah data beserta tipe nilainya. Pada basis data relasional, schema dideklarasikan lebih dulu melalui definisi tabel, sehingga setiap baris wajib mengikuti kolom yang sudah ditetapkan. MongoDB memindahkan keputusan itu ke tingkat dokumen. Dua dokumen dalam satu koleksi boleh memiliki field yang berbeda, dan perbedaan itu tidak dianggap error.

Perilakunya terlihat pada contoh berikut. Dokumen kedua tidak memiliki kelembapanPersen dan dicatatPada, tetapi menambah field catatan yang belum pernah ada sebelumnya. Pembacaan seluruh isi koleksi dilakukan dengan find().

mongosh 
db.pengukuran.insertOne({
  kodeSampel: "LBR-105",
  perangkat: "suhu-lab-2",
  suhuC: 25.1,
  catatan: "dipasang setelah kalibrasi ulang"
})
db.pengukuran.find()
text Keluaran 
{
  acknowledged: true,
  insertedId: ObjectId('6ae85b772737ab44cfce5f48')
}
[
  {
    _id: ObjectId('6ae85b772737ab44cfce5f47'),
    kodeSampel: 'LBR-104',
    perangkat: 'suhu-lab-1',
    suhuC: 24.6,
    kelembapanPersen: 61,
    dicatatPada: ISODate('2026-01-12T09:30:00.000Z')
  },
  {
    _id: ObjectId('6ae85b772737ab44cfce5f48'),
    kodeSampel: 'LBR-105',
    perangkat: 'suhu-lab-2',
    suhuC: 25.1,
    catatan: 'dipasang setelah kalibrasi ulang'
  }
]

Keluaran menunjukkan dua dokumen yang tetap hidup berdampingan dalam satu koleksi meskipun bentuknya tidak seragam. Menambah field baru tidak menuntut perintah semacam ALTER TABLE, dan dokumen lama tidak perlu dimigrasi hanya agar isinya seragam. Sifat inilah yang disebut schema lentur (flexible schema). Dampak langsungnya terasa pada iterasi pengembangan, karena perubahan kebutuhan data tidak lagi menghentikan aplikasi untuk menunggu perubahan struktur di server basis data.

Alasan MongoDB dipakai#

Alasan pertama yang paling sering disebut adalah schema lentur beserta kecepatan iterasi yang menyertainya. Field baru cukup ditulis pada dokumen yang memang membutuhkannya, sehingga aplikasi dapat berjalan tanpa menunggu perubahan struktur di server. Bagi produk yang kebutuhan datanya masih sering berubah, hilangnya jeda migrasi memperpendek jarak antara ide dan uji coba.

Alasan kedua adalah kedekatan model dokumen dengan struktur data pada kode aplikasi. Objek, array, dan struktur bersarang pada bahasa pemrograman modern memiliki padanan langsung berupa dokumen, array, dan subdokumen pada MongoDB. Lapisan penerjemah antara kode dan penyimpanan menjadi tipis, sehingga pembacaan dan penulisan data tidak menuntut banyak persiapan.

MongoDB juga dirancang untuk tumbuh melebihi kapasitas satu server. Data dapat dibagi ke beberapa mesin melalui mekanisme sharding, sehingga penambahan kapasitas dilakukan dengan menambah mesin, bukan mengganti satu mesin dengan yang lebih besar. Karakter ini relevan ketika volume data tumbuh lebih cepat daripada kemampuan satu perangkat keras.

Pilihan tersebut bukan berarti basis data relasional kehilangan tempatnya. Kebutuhan akan transaksi yang menyentuh banyak baris sekaligus, atau struktur data yang sudah mapan dan saling terhubung rapat, tetap nyaman ditangani model relasional. MongoDB memberi manfaat paling jelas pada data yang bentuknya beragam, tumbuh cepat, dan lazim dibaca sebagai unit utuh, misalnya catatan aktivitas, dokumen profil, dan data sensor.

Ringkasan#

  • MongoDB adalah basis data dokumen yang menyimpan data sebagai dokumen mirip JSON di dalam koleksi.
  • Satu dokumen berisi pasangan field dan nilai, lengkap dengan _id yang dihasilkan otomatis bila tidak disediakan.
  • Schema pada MongoDB bersifat lentur, sehingga dokumen dalam satu koleksi boleh memiliki field yang berbeda tanpa memicu error.
  • Keleluasaan schema mempercepat iterasi pengembangan, dengan tanggung jawab menjaga keteraturan bentuk dokumen di sisi aplikasi.

Referensi#