Dengan mesin penyimpanan MMAPv1, pembaruan di tempat sering disorot sebagai strategi pengoptimalan karena indeks untuk dokumen menunjuk langsung ke lokasi file dan offset. Memindahkan dokumen ke lokasi penyimpanan baru (terutama jika ada banyak entri indeks untuk diperbarui) memiliki lebih banyak overhead untuk MMAPv1 daripada pembaruan di tempat yang hanya perlu memperbarui bidang yang diubah. Lihat:Karakteristik Penyimpanan Rekam di MMAPv1.
WiredTiger tidak mendukung pembaruan di tempat karena secara internal menggunakan MVCC (Kontrol konkurensi multiversi), yang biasanya digunakan oleh sistem manajemen basis data. Ini adalah peningkatan teknis yang signifikan atas tampilan sederhana di MMAP, dan memungkinkan untuk membangun fitur yang lebih canggih seperti tingkat isolasi dan transaksi. Indeks WiredTiger memiliki tingkat tipuan (merujuk pada RecordID internal alih-alih lokasi file &offset), sehingga pemindahan dokumen pada tingkat penyimpanan bukanlah titik kesulitan yang signifikan.
Namun, artikel ini juga mengatakan bahwa "Meskipun [WiredTiger] tidak mengizinkan pembaruan di tempat, itu masih bisa berperforma lebih baik daripada MMAP untuk banyak beban kerja".
Ini berarti bahwa meskipun MMAPv1 mungkin memiliki jalur yang lebih efisien untuk pembaruan di tempat, WiredTiger memiliki keunggulan lain seperti kompresi dan kontrol konkurensi yang ditingkatkan. Anda mungkin dapat membuat beban kerja yang hanya terdiri dari pembaruan di tempat untuk beberapa dokumen yang mungkin berkinerja lebih baik di MMAPv1, tetapi beban kerja sebenarnya biasanya lebih bervariasi. Satu-satunya cara untuk mengonfirmasi dampak untuk beban kerja tertentu adalah dengan menguji di lingkungan yang representatif.
Namun, pilihan umum MMAPv1 vs WiredTiger dapat diperdebatkan jika Anda ingin merencanakan masa depan:WiredTiger telah menjadi mesin penyimpanan default sejak MongoDB 3.2 dan beberapa fitur produk yang lebih baru tidak didukung oleh MMAPv1. Misalnya, MMAPv1 tidak mendukung Majority Read Concern yang berarti tidak dapat digunakan untuk Replica Set Config Servers (diperlukan untuk sharding di MongoDB 3.4+) atau Change Streams (MongoDB 3.6+). MMAPv1 tidak akan digunakan lagi dalam rilis utama MongoDB (4.0) berikutnya dan saat ini dijadwalkan untuk dihapus di MongoDB 4.2.
Apa implikasi sebenarnya yang harus saya waspadai ketika saya menggunakan WiredTiger? Misalnya, tanpa pembaruan di tempat, apakah ukuran basis data akan bertambah dengan cepat?
Hasil penyimpanan bergantung pada beberapa faktor termasuk desain skema, beban kerja, konfigurasi, dan versi server MongoDB Anda. MMAPv1 dan WiredTiger menggunakan strategi alokasi rekaman yang berbeda, tetapi keduanya akan mencoba menggunakan ruang yang telah dialokasikan sebelumnya yang ditandai sebagai bebas/dapat digunakan kembali. Secara umum WiredTiger lebih efisien dengan penggunaan ruang penyimpanan, dan juga memiliki keunggulan kompresi untuk data dan indeks. MMAPv1 mengalokasikan ruang penyimpanan tambahan untuk mencoba mengoptimalkan pembaruan di tempat dan menghindari pemindahan dokumen, meskipun Anda dapat memilih strategi "tanpa bantalan" untuk koleksi di mana beban kerja tidak mengubah ukuran dokumen dari waktu ke waktu.
Ada investasi yang signifikan dalam meningkatkan dan menyetel WiredTiger untuk beban kerja yang berbeda sejak pertama kali diperkenalkan di MongoDB 3.0, jadi saya sangat menganjurkan pengujian dengan seri rilis produksi terbaru untuk hasil terbaik. Jika Anda memiliki pertanyaan spesifik tentang desain skema dan pertumbuhan penyimpanan, saya sarankan memposting detail di DBA StackExchange untuk diskusi.
Saya juga mengetahui bahwa WiredTiger di MongoDB 3.6 menambahkan kemampuan untuk menyimpan delta daripada menulis ulang seluruh dokumen (https://jira.mongodb.org/browse/DOCS-11416). Apa artinya ini, tepatnya?
Ini adalah detail implementasi yang meningkatkan struktur data internal WiredTiger untuk beberapa kasus penggunaan. Secara khusus, WiredTiger di MongoDB 3.6+ dapat lebih efisien dalam bekerja dengan perubahan kecil pada dokumen besar (dibandingkan dengan rilis sebelumnya). Cache WiredTiger harus dapat mengembalikan beberapa versi dokumen selama mereka digunakan oleh sesi internal terbuka (MVCC, seperti yang disebutkan sebelumnya), jadi untuk dokumen besar dengan pembaruan kecil akan lebih efisien untuk menyimpan daftar delta. Namun, jika terlalu banyak delta yang terakumulasi (atau delta mengubah sebagian besar bidang dalam dokumen) pendekatan ini mungkin kurang berkinerja daripada mempertahankan banyak salinan dokumen lengkap.
Saat data dimasukkan ke disk melalui pos pemeriksaan, versi lengkap dokumen masih perlu ditulis. Jika Anda ingin mempelajari lebih lanjut tentang beberapa internal, ada rangkaian video MongoDB Path To Transactions mengikuti pengembangan fitur untuk mendukung transaksi multi-dokumen di MongoDB 4.0.
Juga apa yang saya tidak mengerti adalah bahwa saat ini sebagian besar (jika tidak semua) hard drive memiliki ukuran sektor 4096 byte, jadi Anda tidak dapat menulis ke hard drive hanya 4 byte (misalnya) tetapi harus menulis blok penuh 4096 byte (jadi baca dulu, perbarui 4 byte di dalamnya lalu tulis). Karena sebagian besar dokumen seringkali <4096 byte, apakah ini berarti bahwa penulisan ulang seluruh dokumen diperlukan dalam hal apa pun (bahkan dengan MMAP). Apa yang saya lewatkan?
Tanpa terlalu jauh ke detail implementasi dan mencoba menjelaskan semua bagian yang bergerak yang terlibat, pertimbangkan bagaimana pendekatan yang berbeda berlaku untuk beban kerja di mana banyak dokumen sedang diperbarui (bukan pada tingkat dokumen tunggal) serta dampaknya pada penggunaan memori (sebelum dokumen ditulis ke disk). Bergantung pada faktor-faktor seperti ukuran dan kompresi dokumen, satu blok I/O dapat mewakili sebagian kecil dokumen (ukuran maksimal 16 MB) hingga beberapa dokumen.
Di MongoDB alur umumnya adalah bahwa dokumen diperbarui dalam tampilan dalam memori (misalnya, cache WiredTiger) dengan perubahan yang tetap ada pada disk dalam format jurnal hanya-tambah cepat sebelum secara berkala di-flush ke file data. Jika O/S hanya perlu menulis blok data yang telah diubah, menyentuh lebih sedikit blok data membutuhkan lebih sedikit I/O keseluruhan.
