NoSQL dengan MongoDB

Bab 20 menutup pembahasan RDBMS relasional di Bagian V setelah berturut-turut membahas PostgreSQL pada Bab 18, MySQL pada Bab 19, dan MariaDB pada Bab 20 itu sendiri. Bab 21 mengambil arah yang berbeda dengan memperkenalkan MongoDB, database NoSQL berbasis dokumen yang paling banyak dipakai di kategorinya, jauh meninggalkan model tabel dan baris yang sudah kita kenal dari tiga RDBMS sebelumnya. Kita akan memahami terlebih dahulu perbedaan mendasar model data NoSQL dibandingkan RDBMS, menginstal MongoDB 8.0 langsung dari repository resminya, mempraktikkan operasi CRUD melalui mongosh, mengaktifkan authentication yang ternyata tidak otomatis aktif sejak awal instalasi, hingga menyoroti satu catatan penting soal kompatibilitas repository resmi MongoDB dengan rilis Ubuntu 26.04 yang masih tergolong baru.

21.1 Konsep NoSQL vs RDBMS: Dokumen vs Tabel

Seorang Developer yang sedang membangun katalog produk untuk aplikasi e-commerce sering menemui masalah yang sama: produk kategori pakaian punya atribut ukuran dan warna, produk kategori elektronik punya atribut daya dan garansi, sementara produk kategori buku punya atribut penulis dan jumlah halaman. Memaksakan seluruh kombinasi atribut ini ke dalam satu tabel relasional di PostgreSQL atau MySQL biasanya berakhir dengan banyak kolom bernilai NULL atau desain Entity-Attribute-Value yang rumit untuk di-query. Kasus seperti inilah yang menjadi alasan utama NoSQL lahir dan berkembang menjadi kategori database tersendiri sejak akhir tahun 2000-an.

21.1.1 Model Data Document-Oriented vs Relational

NoSQL bukan satu produk tunggal, melainkan payung besar untuk beberapa model data yang sama-sama menghindari struktur tabel kaku ala RDBMS, mulai dari key-value store seperti Redis, column-family store seperti Cassandra, graph database seperti Neo4j, hingga document store yang menjadi fokus bab ini lewat MongoDB. Alih-alih baris pada tabel, MongoDB menyimpan data sebagai dokumen dalam format BSON (Binary JSON), yakni representasi biner dari JSON yang menambahkan tipe data tambahan seperti tanggal dan angka desimal presisi tinggi. Sekumpulan dokumen yang sejenis dikelompokkan ke dalam collection, padanan konsep tabel di RDBMS, namun tanpa keharusan setiap dokumen di dalamnya memiliki struktur field yang identik. Fleksibilitas ini bukan berarti MongoDB selalu dipakai tanpa validasi struktur sama sekali; lewat opsi $jsonSchema pada db.createCollection(), Sysadmin maupun Developer tetap bisa memaksakan aturan validasi pada field tertentu jika suatu collection production butuh kontrol struktur yang lebih ketat, meskipun pembahasan mendalamnya berada di luar cakupan bab pengenalan ini.

Perbedaan paling mencolok terletak pada cara data yang saling berelasi disimpan. RDBMS menormalisasi data ke banyak tabel terpisah lalu menggabungkannya kembali saat query lewat JOIN, sedangkan MongoDB cenderung menganut pola embedded document: data yang sering diakses bersamaan, misalnya detail alamat pengiriman di dalam dokumen pesanan, langsung disisipkan sebagai sub-dokumen di dalam dokumen induknya. Pola ini menghilangkan kebutuhan JOIN untuk kasus pembacaan data yang sering terjadi bersamaan, dengan konsekuensi data bisa terasa terduplikasi dibandingkan desain relasional yang serba ternormalisasi.

Miskonsepsi yang perlu diluruskan sejak awal: NoSQL tidak berarti MongoDB mengabaikan transaksi ACID yang sudah dibahas sejak Bagian 18.1 PostgreSQL. Sejak versi 4.0, MongoDB sudah mendukung multi-document transaction dengan jaminan ACID penuh, meskipun secara desain penggunaannya tetap lebih jarang dibutuhkan dibandingkan RDBMS karena pola embedded document sudah menyelesaikan banyak kasus yang di RDBMS membutuhkan transaksi lintas tabel.

21.1.2 Kapan Memilih NoSQL, Kapan Tetap RDBMS

Sysadmin yang menerima permintaan provisioning database baru dari tim Developer perlu memahami bahwa pilihan RDBMS vs NoSQL bukan soal mana yang lebih baik secara mutlak, melainkan soal kecocokan dengan karakteristik data. Praktik industri modern justru condong ke polyglot persistence: memakai lebih dari satu jenis database dalam satu sistem, masing-masing untuk kebutuhan yang paling cocok dengannya. Data transaksi keuangan yang butuh konsistensi ketat dan relasi antar tabel yang jelas tetap lebih aman disimpan di PostgreSQL atau MariaDB seperti pada Bab 18 dan 20, sementara data katalog produk, log aktivitas, atau konten yang strukturnya sering berubah-ubah lebih nyaman dikelola di MongoDB.

Tabel di atas bukan aturan mutlak, tetapi cukup untuk menjadi bahan pertimbangan awal Sysadmin sebelum menyetujui permintaan provisioning database baru dari Developer.

21.2 Instalasi MongoDB dari Repository Resmi

Berbeda dari PostgreSQL dan MariaDB yang tersedia langsung dari repository resmi Ubuntu, MongoDB sejak Oktober 2018 mengubah lisensinya menjadi SSPL (Server Side Public License) mulai versi 4.x ke atas. Lisensi ini tidak memenuhi kriteria open source versi Debian Free Software Guidelines, sehingga Debian dan Ubuntu menghentikan penyertaan paket mongodb-org versi modern di repository resminya. Oleh karena itu, instalasi MongoDB versi terbaru wajib dilakukan lewat repository resmi milik MongoDB Inc. sendiri, bukan lewat apt install mongodb biasa yang hanya akan mengarah ke paket lawas atau bahkan tidak ditemukan sama sekali.

21.2.1 Menambahkan GPG Key dan Repository APT

Langkah Praktik

1. Pastikan gnupg dan curl sudah terpasang untuk proses import GPG key.

   sudo apt update
   sudo apt install -y gnupg curl

2. Unduh dan import public key resmi MongoDB 8.0.

   curl -fsSL https://pgp.mongodb.com/server-8.0.asc | \
     sudo gpg -o /usr/share/keyrings/mongodb-server-8.0.gpg --dearmor

3. Tambahkan repository resmi ke /etc/apt/sources.list.d/. Perhatikan bahwa baris di bawah ini sengaja memakai codename noble (Ubuntu 24.04 LTS), bukan codename Ubuntu 26.04 yang sedang kita pakai. Alasan lengkapnya dibahas pada Bagian 21.5.

   echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg ] https://repo.mongodb.org/apt/ubuntu noble/mongodb-org/8.0 multiverse" | \
     sudo tee /etc/apt/sources.list.d/mongodb-org-8.0.list

Verifikasi dan Troubleshooting

• Pastikan file /usr/share/keyrings/mongodb-server-8.0.gpg berhasil terbentuk dan tidak berukuran nol byte sebelum melanjutkan ke langkah berikutnya.
• Jika perintah apt update pada langkah berikutnya menampilkan error NO_PUBKEY, ulangi proses import GPG key karena kemungkinan file key gagal terunduh sempurna akibat koneksi terputus di tengah jalan.

21.2.2 Instalasi Package dan Verifikasi Service

Langkah Praktik

1. Perbarui daftar paket agar repository baru terbaca, lalu pasang meta-package mongodb-org.

   sudo apt update
   sudo apt install -y mongodb-org

   Paket mongodb-org secara otomatis menarik beberapa komponen sekaligus sebagai dependency: mongodb-org-server (daemon utama), mongodb-org-mongos (router untuk sharded cluster), mongodb-mongosh (shell interaktif modern), serta mongodb-org-tools yang berisi utilitas seperti mongodump dan mongorestore untuk kebutuhan Bab 23 nanti.
2. Jalankan dan aktifkan service mongod agar otomatis start setiap kali server boot.

   sudo systemctl start mongod
   sudo systemctl enable mongod
   sudo systemctl status mongod

3. Konfirmasikan versi yang benar-benar terpasang.

   mongod --version

Verifikasi dan Troubleshooting

• Output systemctl status yang normal menampilkan status active (running), dengan proses mendengarkan pada port default 27017. Konfirmasikan lewat sudo ss -tlnp | grep 27017.
• Jika service gagal start, periksa log lewat sudo journalctl -u mongod -n 50 atau langsung ke file log native MongoDB di /var/log/mongodb/mongod.log. Penyebab paling umum di server baru adalah permission data directory /var/lib/mongodb yang tidak dimiliki oleh user mongodb.
• Catatan lapangan: MongoDB secara default hanya mendengarkan koneksi dari 127.0.0.1 lewat parameter bindIp di /etc/mongod.conf. Perilaku ini adalah pengaman bawaan yang baik dan sebaiknya tidak buru-buru diubah ke 0.0.0.0 sebelum authentication benar-benar aktif seperti yang akan kita bahas pada Bagian 21.4, mengingat cukup banyak insiden nyata di internet berupa instance MongoDB yang diekspos publik tanpa password dan berujung data dicuri atau disandera.

21.3 Operasi Dasar via mongosh: CRUD

mongosh adalah shell interaktif resmi MongoDB berbasis JavaScript, pengganti mongo lawas yang sudah dihentikan pengembangannya sejak MongoDB 6.0. Sysadmin maupun Developer memakai mongosh untuk hal yang sama seperti psql di PostgreSQL atau mariadb di MariaDB: menjalankan query, mengelola user, dan melakukan administrasi harian langsung dari command line.

21.3.1 Koneksi ke mongosh dan Struktur Database/Collection

Langkah Praktik

1. Masuk ke mongosh tanpa autentikasi terlebih dahulu, karena authorization memang belum kita aktifkan pada tahap ini.

   mongosh

2. Pindah ke database baru bernama webapp_catalog. Berbeda dari CREATE DATABASE eksplisit di RDBMS, MongoDB baru benar-benar membuat database dan collection begitu ada operasi tulis pertama yang mengarah ke sana.

   use webapp_catalog

3. Tampilkan daftar database yang sudah benar-benar berisi data.

   show dbs

Verifikasi dan Troubleshooting

• Perintah show dbs yang dijalankan sebelum ada operasi tulis apa pun tidak akan menampilkan webapp_catalog, karena database tersebut sejatinya belum tercipta di storage engine. Hal ini normal dan bukan tanda kegagalan, cukup lanjutkan ke Bagian 21.3.2 untuk membuktikannya.
• Prompt yang berubah menjadi webapp_catalog> menandakan sesi sudah berada dalam konteks database yang benar.

21.3.2 Create, Read, Update, Delete (CRUD)

Langkah Praktik

1. Buat satu dokumen produk di collection products, melanjutkan skenario katalog e-commerce dari Bagian 21.1.

   db.products.insertOne({
     name: "Keyboard Mekanik",
     category: "elektronik",
     price: 750000,
     stock: 25
   })

   Collection products dan database webapp_catalog otomatis tercipta pada saat perintah ini dijalankan, membuktikan sifat schemaless yang dibahas pada Bagian 21.1.1.
2. Tambahkan beberapa dokumen sekaligus dengan struktur field yang sengaja berbeda-beda, untuk membuktikan fleksibilitas skema.

   db.products.insertMany([
     { name: "Kaos Polos", category: "pakaian", price: 85000, size: ["S", "M", "L"] },
     { name: "Novel Laskar Pelangi", category: "buku", price: 65000, author: "Andrea Hirata", pages: 529 }
   ])

3. Baca seluruh dokumen di collection products.

   db.products.find()

   Tambahkan .pretty() di belakangnya untuk output yang lebih mudah dibaca pada dokumen dengan struktur bertingkat.
4. Baca dokumen dengan filter, misalnya produk berkategori elektronik dengan harga di atas 500 ribu.

   db.products.find({ category: "elektronik", price: { $gt: 500000 } })

5. Ubah nilai stock pada dokumen Keyboard Mekanik memakai operator $set.

   db.products.updateOne(
     { name: "Keyboard Mekanik" },
     { $set: { stock: 20 } }
   )

6. Hapus satu dokumen berdasarkan filter.

   db.products.deleteOne({ name: "Kaos Polos" })

Verifikasi dan Troubleshooting

• Setiap perintah insertOne, updateOne, dan deleteOne yang berhasil menampilkan objek hasil berisi field seperti acknowledged: true beserta jumlah dokumen yang terpengaruh, mirip fungsi pesan Query OK di MySQL/MariaDB yang sudah dikenal sejak Bagian 19.3.
• MongoDB otomatis menambahkan field _id bertipe ObjectId yang unik pada setiap dokumen baru jika tidak didefinisikan secara manual, berfungsi sebagai primary key implisit setara SERIAL atau AUTO_INCREMENT di RDBMS.
• Kesalahan umum Developer yang baru pindah dari RDBMS adalah lupa bahwa find() tanpa filter dan tanpa limit() akan mengembalikan seluruh dokumen di collection. Pada collection produksi yang berisi jutaan dokumen, kebiasaan ini bisa membebani memori server secara signifikan, sehingga selalu sertakan filter atau .limit() saat eksplorasi data di server production yang sudah berjalan.

21.4 Autentikasi dan Access Control Dasar

Instalasi MongoDB dari Bagian 21.2 secara default berjalan tanpa authentication sama sekali, siapa pun yang bisa terhubung ke port 27017 otomatis mendapatkan akses penuh tanpa perlu username atau password. Perilaku default ini pernah menjadi penyebab berbagai insiden keamanan nyata di masa lalu, ketika banyak instance MongoDB yang sengaja atau tidak sengaja diekspos ke internet publik tanpa authentication maupun firewall, lalu ditemukan dan dieksploitasi oleh Attacker yang mencari instance semacam ini secara massal. Mengaktifkan authentication sebelum server benar-benar dipakai untuk data sungguhan bukan langkah opsional, melainkan kewajiban dasar.

21.4.1 Mengaktifkan Authorization dan Membuat User Admin

Langkah Praktik

1. Selagi authentication masih nonaktif, masuk ke mongosh dan pindah ke database admin untuk membuat user administratif pertama.

   mongosh

   use admin
   db.createUser({
     user: "admin",
     pwd: passwordPrompt(),
     roles: [ { role: "userAdminAnyDatabase", db: "admin" }, "readWriteAnyDatabase" ]
   })

   Fungsi passwordPrompt() menampilkan input password tersembunyi di terminal, lebih aman dibandingkan mengetik password polos langsung di dalam perintah db.createUser yang berisiko tersimpan di history shell.
2. Keluar dari mongosh, lalu edit file konfigurasi /etc/mongod.conf untuk mengaktifkan authorization.

   security:
     authorization: enabled

3. Restart service mongod agar konfigurasi baru terbaca.

   sudo systemctl restart mongod

4. Uji koneksi kembali, kali ini wajib menyertakan credential.

   mongosh -u admin -p --authenticationDatabase admin

Verifikasi dan Troubleshooting

• Percobaan koneksi tanpa flag -u dan -p setelah authorization aktif harus langsung ditolak dengan pesan error Command find requires authentication saat mencoba operasi apa pun, membuktikan bahwa proteksi sudah benar-benar berjalan.
• Parameter --authenticationDatabase admin wajib disertakan karena user admin dibuat di database admin, bukan di database aplikasi. Melupakan parameter ini adalah kesalahan yang paling sering ditemui Sysadmin yang baru pertama kali mengaktifkan authentication MongoDB.

21.4.2 Membuat User Aplikasi dengan Role Terbatas

Sama seperti prinsip least privilege yang sudah diterapkan pada user aplikasi PostgreSQL di Bagian 18.3 dan MariaDB di Bagian 20.3, user admin sebaiknya tidak dipakai langsung oleh aplikasi Developer. Buat user terpisah yang hak aksesnya dibatasi hanya ke database webapp_catalog.

Langkah Praktik

1. Masuk sebagai admin, lalu pindah ke database webapp_catalog.

   mongosh -u admin -p --authenticationDatabase admin

   use webapp_catalog

2. Buat user aplikasi dengan role readWrite yang dibatasi hanya pada database ini.

   db.createUser({
     user: "webapp_user",
     pwd: passwordPrompt(),
     roles: [ { role: "readWrite", db: "webapp_catalog" } ]
   })

3. Uji login dengan user baru ini.

   mongosh -u webapp_user -p --authenticationDatabase webapp_catalog webapp_catalog

Verifikasi dan Troubleshooting

• Jalankan db.products.find() dan db.products.insertOne({ name: "Test" }) sebagai webapp_user untuk membuktikan akses baca dan tulis berfungsi normal pada database webapp_catalog.
• Coba pindah ke database lain, misalnya use admin lalu db.system.users.find(), dan pastikan operasi tersebut ditolak dengan pesan not authorized. Kegagalan ini justru menjadi bukti bahwa pembatasan role bekerja sebagaimana mestinya, persis seperti pengujian role app_readonly pada Bagian 20.3.3 di bab sebelumnya.

21.5 Catatan Kompatibilitas Rilis dengan Ubuntu 26.04 LTS

Perhatikan kembali baris repository pada Bagian 21.2.1 yang sengaja memakai codename noble (Ubuntu 24.04 LTS), padahal server yang kita pakai di seluruh series ini menjalankan Ubuntu 26.04 LTS dengan codename Resolute Raccoon. Perbedaan ini bukan salah ketik, melainkan langkah antisipasi yang perlu dipahami Sysadmin sebelum praktik.

21.5.1 Kenapa Repository Resmi Bisa Tertinggal dari Rilis Ubuntu Terbaru

MongoDB Inc. hanya menerbitkan build mongodb-org untuk codename Ubuntu tertentu yang sudah melalui proses pengujian dan sertifikasi resmi di pihak mereka, bukan secara otomatis mengikuti setiap rilis Ubuntu baru sejak hari pertama dirilis. Pada rilis-rilis Ubuntu sebelumnya, jeda antara tanggal rilis resmi Ubuntu dan tanggal codename tersebut muncul di repo.mongodb.org biasa berkisar beberapa bulan, karena tim MongoDB perlu memvalidasi kompatibilitas toolchain build dan baseline glibc/OpenSSL milik rilis baru tersebut. Oleh karena Ubuntu 26.04 LTS masih tergolong baru pada masa penulisan materi ini, ada kemungkinan besar codename resolute belum tersedia sebagai target resmi di repository MongoDB pada saat series ini dipraktikkan.

21.5.2 Strategi Aman Sebelum Praktik

Sysadmin perlu memverifikasi status dukungan resmi ini secara langsung sebelum mengikuti langkah instalasi di Bagian 21.2, alih-alih menganggapnya sebagai fakta yang pasti berlaku selamanya. Buka halaman dokumentasi instalasi resmi MongoDB untuk Ubuntu di www.mongodb.com/docs/manual/administration/install-on-linux, lalu periksa apakah codename resolute sudah tercantum sebagai target yang didukung.

• Jika resolute sudah tercantum di dokumentasi resmi, gunakan langsung codename tersebut untuk menggantikan noble pada baris repository di Bagian 21.2.1.
• Jika belum tercantum, tetap gunakan noble sebagai fallback seperti pada contoh Bagian 21.2.1. Pendekatan ini bukan pernyataan resmi dari MongoDB Inc., melainkan kebiasaan lapangan yang cukup umum dipakai Sysadmin saat repository resmi belum menyediakan build untuk rilis distro terbaru, mengingat baseline glibc dan OpenSSL antar rilis LTS Ubuntu yang berdekatan umumnya masih cukup kompatibel satu sama lain.
• Cara tercepat untuk membuktikan status dukungan ini secara langsung di server sendiri adalah mengganti noble dengan resolute pada baris repository di Bagian 21.2.1, lalu menjalankan sudo apt update. Error 404 Not Found yang mengarah ke path dists/resolute/ berarti build untuk codename tersebut memang belum tersedia dan baris repository perlu dikembalikan ke noble, sedangkan apt update yang berjalan mulus menandakan dukungan resmi sudah bisa dipakai.
• Apa pun pilihannya, uji hasil instalasi secara menyeluruh mengikuti Bagian 21.2.2 sebelum server ini dipakai untuk data produksi, karena kompatibilitas lintas codename seperti ini tidak pernah dijamin resmi dan tetap berisiko menimbulkan masalah yang tidak terduga di kemudian hari.

Sampai di sini, server telah menjalankan MongoDB 8.0 lengkap dengan database webapp_catalog yang terisi dokumen produk, dilindungi oleh authentication yang sudah diaktifkan, serta terpisah rapi antara user admin dan webapp_user yang read-write terbatas. Bab 22 melanjutkan Bagian V dengan memasang web UI untuk mempermudah pengelolaan visual ketiga jenis database yang sudah kita praktikkan, mulai dari phpMyAdmin, pgAdmin 4, hingga mongo-express khusus untuk MongoDB.