Arsitektur MongoDB

Kita bisa memakai database bertahun-tahun tanpa memahami isinya, tetapi saat query melambat atau server berhenti tak terduga, pengetahuan arsitektur menjadi penentu. MongoDB bukan satu benda monolitik: ada proses server yang menerima perintah, storage engine yang menulis ke disk, journal yang menjaga ketahanan data, dan lapisan klien yang beragam.

Materinya: komponen inti, mongod dan interface klien, WiredTiger, journaling, namespace, serta pratinjau replikasi dan sharding.

Komponen Utama dalam Satu Pandangan #

Diagram berikut merangkum perjalanan satu operasi dari aplikasi sampai ke penyimpanan fisik:

Alurnya berjalan dari atas ke bawah. Aplikasi dan tool interaktif tidak pernah menyentuh berkas data secara langsung — semuanya melewati interface klien, lalu berbicara dengan mongod melalui wire protocol MongoDB di atas TCP (port bawaan 27017). Di dalam mongod, query diolah dan diserahkan ke WiredTiger yang membawa data ke memori dan disk:

mongod dan Interface Klien #

mongod adalah proses server utama MongoDB — huruf “d” menandakan daemon, program yang berjalan di latar belakang. Satu instance mongod mengelola banyak database sekaligus. Untuk sharded cluster ada proses tambahan mongos yang merutekan query ke shard yang tepat; kita bahas di bagian akhir chapter.

Di sisi klien, MongoDB menyediakan tiga jalur utama:

• mongosh — shell interaktif berbasis Node.js; menggantikan mongo shell lama yang dihapus sejak MongoDB 6.0.
• MongoDB Compass — antarmuka grafis untuk menjelajah data, membangun aggregation, dan membaca explain plan.
• Driver resmi — pustaka untuk puluhan bahasa — Node.js, Python, Java, Go, C#/.NET — yang dipanggil langsung dari kode aplikasi.

WiredTiger, Storage Engine Default #

Storage engine adalah lapisan di dalam mongod yang bertugas menyimpan dan membaca data di memori serta disk. Sejak MongoDB 3.2 posisi itu dipegang WiredTiger, kini satu-satunya storage engine di edisi Community setelah MMAPv1 dihapus pada MongoDB 6.0.

Tiga kemampuan WiredTiger yang paling terasa dampaknya:

• Concurrency di level document. Penulisan pada document yang berbeda tidak saling mengunci satu sama lain, sehingga banyak klien dapat menulis bersamaan ke satu collection.
• Kompresi data. WiredTiger mengompresi blok data di disk dengan algoritma snappy secara bawaan; alternatifnya zstd dan zlib bila rasio kompresi lebih penting daripada kecepatan.
• Kompresi index. Prefix compression bawaan membuat index lebih hemat ruang memori.

Sehari-hari kita jarang menyentuh konfigurasi storage engine; yang perlu dipahami konsekuensinya: berkas di disk sering lebih kecil dari ukuran logis data karena kompresi.

Journaling dan Ketahanan Data #

Ketahanan data WiredTiger berdiri di atas dua mekanisme yang bekerja sama:

1. Checkpoint. WiredTiger secara berkala menuliskan kondisi data yang konsisten ke berkas data di disk — secara bawaan setiap 60 detik, atau lebih cepat bila journal menumpuk 2 GB.
2. Journal (write-ahead log). Setiap perubahan terlebih dahulu dicatat ke journal sebelum dianggap selesai. Secara bawaan, journal dikomit sekitar setiap 100 milidetik.

Ketika proses mongod berhenti tak terduga, saat start ulang mongod memutar ulang journal sejak checkpoint terakhir, sehingga semua perubahan yang sudah dikomit tetap utuh. Seberapa ketat jaminan ini diatur oleh write concern — topik yang kita bahas tuntas di section replikasi.

Namespace: Menunjuk Database dan Collection #

MongoDB menyebut gabungan nama database dan nama collection sebagai namespace, ditulis database.collection. Namespace toko.produk, misalnya, menunjuk collection produk di database toko. Pesan log dan perintah administratif memakai penamaan ini.

Secara fisik, WiredTiger menyimpan setiap collection dan setiap index dalam berkas terpisah di direktori data (dbPath), sehingga menambah collection berarti menambah berkas baru. Setiap collection juga otomatis memiliki unique index pada _id — pencarian berdasarkan _id terlayani index sejak collection dibuat.

Replikasi dan Sharding: Pratinjau #

Dua kemampuan di atas berlaku untuk satu instance mongod. Untuk ketersediaan dan skala, MongoDB menyusun beberapa instance menjadi pola yang lebih besar:

• Replica set — sekumpulan mongod dengan data yang sama: satu primary menerima seluruh penulisan, secondary meneruskan perubahan lewat oplog. Bila primary tidak tersedia, anggota lain mengadakan pemilihan otomatis — dokumentasi menyarankan minimal tiga anggota dengan hak suara.
• Sharding — memecah satu collection besar ke beberapa shard berdasarkan shard key, dengan mongos sebagai perute query dan config server sebagai penyimpan metadata; jalan skala horizontal ketika satu server sudah tidak sanggup menampung data atau beban.

Kedua topik ini memiliki section tersendiri; kita bedah tuntas di sana.

Rangkuman #

• Alur data berjalan bertingkat: aplikasi → interface klien (mongosh/Compass/driver) → mongod → WiredTiger → berkas di disk, melalui wire protocol di atas TCP port 27017.
• WiredTiger, satu-satunya storage engine di edisi Community: concurrency per document, kompresi data, dan prefix compression pada index.
• Journaling menjaga ketahanan data lewat write-ahead log yang dikomit sekitar tiap 100 milidetik dan checkpoint tiap 60 detik atau 2 GB journal.
• Namespace database.collection adalah cara resmi menunjuk data; setiap collection dan index menempati berkas WiredTiger terpisah.
• Replica set memberi ketersediaan tinggi lewat primary-secondary dan pemilihan otomatis; sharding memberi skala horizontal lewat shard key, mongos, dan config server.