Apa Itu MongoDB? Fitur, Pemodelan Dokumen, dan Kapan Menggunakannya

MongoDB adalah database yang menyimpan data sebagai dokumen daripada mengorganisasikannya terutama ke dalam tabel relasional. Pertimbangkan penggunaannya untuk data yang sering dibaca bersama, seperti katalog produk dengan atribut yang bervariasi atau profil pengguna bersarang, sambil tetap merancang skema dan memeriksa kinerja.

Panduan ini menjelaskan model penyimpanan MongoDB, fitur, kasus penggunaan, dan kriteria adopsi. Untuk gambaran yang lebih luas, lihat perbandingan model NoSQL dan basis data relasional.

Bagaimana MongoDB menyimpan data?

Sebuah dokumen terdiri dari pasangan bidang dan nilai. Sebuah koleksi adalah pengelompokan logis dari dokumen-dokumen, dan sebuah basis data dapat berisi koleksi untuk tujuan yang berbeda, seperti produk, pesanan, dan pelanggan.

MongoDB menyimpan dokumen sebagai BSON (Binary JSON). BSON merepresentasikan struktur JSON (JavaScript Object Notation) dalam bentuk biner dan mendukung tipe tambahan, termasuk tanggal dan nilai ObjectId. Karena itu, MongoDB tidak tepat dipahami sebagai penyimpanan yang sekadar menyimpan berkas teks JSON. Referensi dokumen MongoDB menjelaskan tipe data dan aturan pengenal.

JSON produk fiksi ini menggambarkan bentuk sebuah dokumen. Dalam koleksi standar, _id mengidentifikasi sebuah dokumen. Contoh ini menggunakan string yang dapat dibaca; sebuah aplikasi tetap memerlukan format pengenal dan aturan penanganan duplikasi.

{
  "_id": "book-101",
  "name": "Database Basics",
  "category": "books",
  "price_krw": 24000,
  "attributes": {
    "author": "Mina Kim",
    "pages": 320
  },
  "tags": [
    "database",
    "beginner"
  ]
}

attributes adalah objek bersarang dan tags adalah array. Buku dapat memiliki bidang penulis dan jumlah halaman sedangkan elektronik memiliki informasi baterai. Pertahankan aturan bersama untuk jenis harga, bidang yang wajib, dan nilai yang hilang.

Fitur utama dan kondisinya

Skema dan validasi yang fleksibel

Sebuah skema mendefinisikan bidang, tipe, dan kondisi yang wajib. MongoDB tidak mengharuskan setiap dokumen dalam satu koleksi memiliki bidang yang sama secara default. Fleksibilitas itu tidak menghilangkan desain skema.

Validasi skema dapat membatasi jenis dan rentang nilai yang diizinkan. Koordinasikan pemeriksaan aplikasi dan validasi basis data untuk mencegah harga angka/string yang tercampur atau representasi tanggal yang tidak konsisten. Sebelum menambahkan aturan ke data yang sudah ada, identifikasi dokumen yang tidak sesuai dan putuskan bagaimana pembaruan akan ditangani.

Kueri, agregasi, dan data terkait

Kueri MongoDB menggunakan kondisi field dan operator daripada menerima pernyataan SQL secara langsung. Pelajari sintaks yang digunakan oleh driver atau shell bahasa Anda. Notasi titik mengakses field yang bersarang, dan kueri juga dapat mengekspresikan kondisi array.

Sebuah pipeline agregasi memproses dokumen melalui tahap-tahap seperti penyaringan, pengelompokan, dan perhitungan. Misalnya, menyaring item pesanan yang tidak dibatalkan dan total kuantitas berdasarkan produk. Panduan pipeline agregasi menjelaskan bagaimana tahapan bekerja.

$lookup menyediakan join outer kiri ke koleksi lain, sehingga pernyataan "MongoDB tidak memiliki join" tidak akurat. Tinjau dukungan $lookup dan kondisi kinerjanya. Jangan menganggap bahwa referensi secara otomatis menerima penegakan integritas referensial yang terkait dengan batasan kunci asing relasional.

Indeks dan kinerja

Indeks adalah struktur data yang dapat mengurangi data yang perlu diperiksa untuk menemukan dokumen yang cocok. Indeks satu bidang dan indeks gabungan memenuhi pola akses yang berbeda. Dokumentasi indeks MongoDB menjelaskan manfaat kueri sekaligus biaya penulisannya.

Lebih banyak indeks memerlukan penyimpanan dan kerja untuk memeliharanya selama penulisan. Kinerja juga tergantung pada ukuran dokumen, campuran baca/tulis, memori, disk, dan jaringan. Evaluasi kueri yang representatif menggunakan rencana eksekusi dan beban realistis daripada mengasumsikan NoSQL secara inheren cepat.

Transaksi dan jaminan baca/tulis

Pembaruan dokumen tunggal bersifat atomik: tidak menerapkan pembaruan tersebut secara parsial. Untuk perubahan yang harus berhasil atau gagal secara bersamaan di beberapa dokumen, pertimbangkan transaksi multi-dokumen pada set replika atau klaster sharded. Jangan menganggap kemampuan yang sama ada di server tunggal.

ACID berarti Atomisitas, Konsistensi, Isolasi, dan Ketahanan. Tinjau kondisi penyebaran dan konfigurasi dalam dokumentasi transaksi. Ketika pembuatan pesanan dan pengurangan inventaris mempengaruhi dokumen yang berbeda, tentukan batas transaksi, penanganan permintaan bersamaan, dan perilaku percobaan ulang.

Read concern mengontrol status data yang dapat diamati oleh sebuah pembacaan, sementara write concern mengontrol tingkat pengakuan untuk sebuah penulisan. Tetapkan jaminan yang diperlukan sebelum memberi tahu pengguna bahwa pembayaran telah selesai, dan bedakan operasi yang dapat menerima nilai lama dari replika.

Haruskah data terkait disematkan atau direferensikan?

Penyematan menempatkan data terkait di dalam satu dokumen. Referensi menautkan ke identifikasi dokumen lain. panduan pemodelan merekomendasikan menyimpan bersama apa yang diakses bersama; panduan penyematan-versus-referensi menjelaskan keuntungan dan kerugian untuk hubungan dan pembaruan.

Menyalin alamat pengiriman ke dalam pesanan dapat mempertahankan makna historisnya. Menyalin detail kontak pelanggan saat ini ke setiap pesanan membuat salinan yang perlu diperbarui ketika detail tersebut berubah. Pertama-tama bedakan fakta historis dari nilai yang harus selalu terkini.

Dokumen BSON biasa memiliki ukuran maksimum 16 mebibyte (MiB). Menambahkan setiap komentar atau entri log ke satu array dapat mencapai batas tersebut dan meningkatkan biaya pembaruan. Gunakan koleksi terpisah, referensi, atau kelompok dengan ukuran terbatas sambil mempertimbangkan batas ukuran dokumen MongoDB.

Kasus penggunaan mana yang layak dipertimbangkan?

Ini adalah alasan untuk mengevaluasi model dokumen, bukan jaminan berdasarkan label industri. Bacaan dan pembaruan nyata harus menjadi dasar pemilihan.

Juga bandingkan basis data relasional ketika pelaporan lintas-tabel yang fleksibel, hubungan dan batasan yang dibagikan, atau pembaruan banyak-ke-banyak yang kompleks adalah persyaratan utama. Menyimpan JSON saja tidak membenarkan mengganti database yang ada. Periksa apakah model dokumen meningkatkan kueri penting dan beban kerja operasional.

Contoh kecil penyisipan-dan-kueri

Perintah berikut menggunakan MongoDB Shell, mongosh. Sambungkan terlebih dahulu ke penyebaran latihan terpisah, menggunakan akun dengan izin baca, tulis, dan pembuatan indeks untuk basis data target serta shell yang telah terinstal. Lihat Dokumentasi MongoDB Shell untuk petunjuk koneksi.

Contoh ini menyisipkan satu produk ke dalam product_catalog di basis data mongodb_intro_demo. Mulailah dengan koleksi kosong dengan nama ini di lingkungan latihan, dan pastikan koneksi Anda menargetkan lingkungan tersebut sebelum menjalankan perintah.

db = db.getSiblingDB("mongodb_intro_demo");

db.product_catalog.insertMany([
{
  "_id": "book-101",
  "name": "Database Basics",
  "category": "books",
  "price_krw": 24000,
  "attributes": {
    "author": "Mina Kim",
    "pages": 320
  },
  "tags": [
    "database",
    "beginner"
  ]
}
]);

insertMany() menyisipkan dokumen. Mengulangi _id yang sama dalam koleksi standar menghasilkan kesalahan duplicate-key. Untuk latihan berulang, gunakan basis data latihan baru atau secara eksplisit identifikasi dan tangani hanya dokumen contoh yang Anda tambahkan. Jangan menghapus koleksi yang ada untuk mengatasi kesalahan itu.

Query ini menemukan produk di books yang berharga di bawah 30.000 won Korea, mengembalikan identifier, nama, dan harga mereka, serta mengurutkan berdasarkan harga naik. Dengan hanya data contoh yang ada, book-101 memenuhi kondisi tersebut.

db.product_catalog.find(
  { category: "books", price_krw: { $lt: 30000 } },
  { _id: 1, name: 1, price_krw: 1 }
).sort({ price_krw: 1 });

$lt berarti "kurang dari." Objek kedua menetapkan bidang yang dikembalikan, sebuah proyeksi, dan 1 di sort() berarti urutan naik. Referensi find() menjelaskan filter dan proyeksi.

Untuk filter harga spesifik kategori yang sering digunakan dan pengurutan, pertimbangkan indeks majemuk ini. Periksa distribusi aktual dan kueri lainnya sebelum menerapkan createIndex() di lingkungan produksi.

db.product_catalog.createIndex(
  { category: 1, price_krw: 1 }
);

Perintah berikut menjalankan kueri dan melaporkan statistik eksekusi tanpa mengubah dokumen. Dalam hasil explain("executionStats"), periksa rencana yang dipilih, kunci dan dokumen yang diperiksa, serta dokumen yang dikembalikan. Koleksi kecil mungkin menggunakan pemindaian koleksi; hanya membuat indeks tidak menunjukkan peningkatan kecepatan.

db.product_catalog.find(
  { category: "books", price_krw: { $lt: 30000 } }
).sort({ price_krw: 1 }).explain("executionStats");

Replikasi dan sharding memiliki tugas yang berbeda

Sebuah set replika adalah sekelompok server yang mempertahankan data yang sama. Biasanya, server primer menerima penulisan dan server sekunder menyalin perubahan; anggota yang memenuhi syarat dapat memilih primer baru setelah kegagalan. Panduan replikasi menjelaskan pemilihan dan replikasi asinkron.

Failover dapat menyebabkan keterlambatan atau kesalahan penulisan sementara, dan pembacaan sekunder dapat mencerminkan keterlambatan replikasi. Replikasi tidak secara tanpa syarat menjamin layanan tanpa gangguan atau mencegah setiap kehilangan data. Rancang percobaan ulang, penanganan permintaan duplikat, dan jaminan baca/tulis yang diperlukan bersama dengan aplikasi.

Sharding mendistribusikan data antarserver untuk penskalaan horizontal. Kunci shard memuat bidang yang dipakai untuk distribusi dan perutean kueri. Kunci yang memusatkan beban atau kueri yang harus mengunjungi setiap shard dapat membatasi manfaatnya. Panduan sharding MongoDB menjelaskan pemilihan kunci dan kompleksitas operasional.

Replikasi dan sharding dapat digunakan bersama-sama, tetapi memiliki tujuan yang berbeda. Periksa model, indeks, dan hambatan saat ini sebelum memperkenalkan sharding hanya karena data mungkin tumbuh. Harus ada alasan untuk menerima kompleksitas dan biaya tambahan.

Apa yang harus Anda periksa sebelum mengadopsi MongoDB?

1. Tentukan operasi penting. Spesifikasikan filter, pengurutan, dan unit pembaruan untuk detail produk, pencarian harga kategori, dan pembuatan pesanan; bandingkan implementasi relasional dan dokumen yang sebenarnya.
2. Tinjau model dan kebenarannya. Putuskan tentang embedding atau referensi, ukuran dokumen, validasi, indeks, transaksi, dan persyaratan baca segera.
3. Bandingkan beban perwakilan. Ukur latensi, throughput, dan kesalahan dengan data dan distribusi permintaan yang realistis. Catat versi, perangkat keras, dan pengaturan, serta periksa skenario kegagalan dan pemulihan.
4. Pilih model operasional. Tentukan antara manajemen sendiri dan layanan terkelola, dengan menetapkan tanggung jawab untuk cadangan, pemulihan, pemantauan, peningkatan, dan dukungan.
5. Siapkan migrasi dan jalur kembali. Tentukan konversi identifier/tipe, pemeriksaan data yang hilang, penulisan saat cutover, dan kondisi untuk kembali ke penyimpanan yang ada.

MongoDB Atlas adalah layanan cloud yang dikelola dengan pembagian tanggung jawab operasional yang berbeda dari penyebaran yang dikelola sendiri. Gunakan dokumentasi Atlas untuk memeriksa fitur dan opsi penyebaran yang diperlukan. Sertakan penyimpanan, cadangan, jaringan, dan pekerjaan operasional bersama dengan biaya instance.

Dalam produksi, tinjau akun dengan hak minimum, koneksi terenkripsi, pembatasan jaringan, dan pengelolaan kredensial menggunakan panduan keamanan MongoDB yang sesuai dengan penerapan Anda. Penghapusan tidak sengaja dapat menyebar ke replika, sehingga replikasi tidak menggantikan cadangan. Ikuti panduan metode pencadangan dan pastikan pemulihan benar-benar berfungsi.