Tema ini menjelaskan praktik terbaik untuk transaksi dan Read/Write Concern di ApsaraDB for MongoDB.
Informasi latar belakang
MongoDB 4.0 mendukung transaksi mandiri (transaksi replika set). Anda dapat melakukan operasi pada transaksi dalam satu atau lebih koleksi dari instance replika set. MongoDB 4.2 mendukung transaksi terdistribusi (transaksi shard). Anda dapat melakukan operasi pada dokumen yang berbeda di beberapa koleksi lintas shard.
ApsaraDB for MongoDB selalu menjamin atomicitas operasi pada dokumen tunggal. Aplikasi Anda dapat menggunakan dokumen tertanam dan struktur array untuk membangun dokumen tunggal yang lebih erat kaitannya karena fleksibilitas struktur dokumen. Ini jauh lebih sederhana dibandingkan dengan database relasional tradisional, di mana Anda harus membuat beberapa koleksi yang mengikuti aturan struktur dan melakukan join atau memperbarui beberapa transaksi. Dalam sebagian besar skenario ApsaraDB for MongoDB yang melibatkan pemodelan data yang masuk akal, jaminan atomicitas operasi pada dokumen tunggal telah menghilangkan kebutuhan untuk transaksi terdistribusi.
Namun, beberapa skenario khusus, seperti keuangan dan akuntansi, masih memiliki kebutuhan kuat untuk transaksi terdistribusi. MongoDB 4.2 atau yang lebih baru sepenuhnya mendukung dokumen terdistribusi dan dapat memenuhi kebutuhan dalam skenario tersebut.
Transaksi
Informasi latar belakang
ApsaraDB for MongoDB dapat digunakan dengan cara yang sama seperti database relasional tradisional. API di ApsaraDB for MongoDB dapat digunakan dengan cara yang sama seperti database relasional tradisional. Tidak ada kurva pembelajaran yang terlibat.
Contoh berikut menunjukkan sebuah transaksi. Anda dapat melihat pengaturan API (startTransaction, abortTransaction, dan commitTransaction) dan terkait sesi, read concern, dan write concern.
// Membuat koleksi.
db.getSiblingDB("mydb1").foo.insertOne(
{abc: 0},
{ writeConcern: { w: "majority", wtimeout: 2000 } }
)
db.getSiblingDB("mydb2").bar.insertOne(
{xyz: 0},
{ writeConcern: { w: "majority", wtimeout: 2000 } }
)
// Memulai sesi.
session = db.getMongo().startSession( { readPreference: { mode: "primary" } } );
coll1 = session.getDatabase("mydb1").foo;
coll2 = session.getDatabase("mydb2").bar;
// Memulai transaksi.
session.startTransaction( { readConcern: { level: "local" }, writeConcern: { w: "majority" } } );
// Melakukan operasi dalam transaksi.
try {
coll1.insertOne( { abc: 1 } );
coll2.insertOne( { xyz: 999 } );
} catch (error) {
// Menggugurkan transaksi ketika terjadi kesalahan.
session.abortTransaction();
throw error;
}
// Menyimpan transaksi.
session.commitTransaction();
session.endSession();Perhatikan item berikut saat menggunakan transaksi:
Transaksi harus dikaitkan dengan sesi. Sebuah sesi hanya dapat memiliki satu transaksi yang sedang berlangsung pada satu waktu. Setelah sesi berakhir, transaksi yang sedang berlangsung yang terkait dengan sesi akan dibatalkan.
Transaksi terdistribusi dapat mencakup operasi pada dokumen yang berbeda di koleksi yang berbeda pada saat yang sama.
Saat transaksi dieksekusi, transaksi dapat membaca operasi tulis yang belum dikomit oleh transaksi. Namun, operasi lain di luar transaksi tidak dapat membaca operasi tulis yang belum dikomit dalam transaksi.
Data yang belum dikomit yang ditulis ke transaksi tidak direplikasi ke node sekunder sampai transaksi disimpan. Setelah transaksi disimpan, data yang ditulis ke transaksi direplikasi dan secara otomatis diterapkan ke semua node sekunder dalam instance replika set.
Saat Anda memodifikasi dokumen, transaksi mengunci dokumen untuk mencegah dokumen diubah oleh operasi lain hingga transaksi selesai. Transaksi tidak dapat memperoleh kunci pada dokumen yang perlu dimodifikasi karena transaksi lain mungkin sudah memegang kunci. Dalam hal ini, transaksi akan dibatalkan dan konflik tulis akan dilaporkan setelah 5 milidetik. Waktu pembatalan transaksi ditentukan oleh parameter kernel maxTransactionLockRequestTimeoutMillis. Untuk informasi lebih lanjut tentang parameter tersebut, lihat maxTransactionLockRequestTimeoutMillis.
Transaksi tunduk pada mekanisme ulang. Jika kesalahan ulang sementara dilaporkan, seperti gangguan jaringan sementara, transaksi akan diulang secara otomatis. Klien Anda tidak menyadari operasi ulang.
Transaksi memiliki siklus hidup. Transaksi yang berjalan lebih dari 60 detik akan dipaksa dibatalkan oleh thread latar belakang. Waktu pembatalan paksa untuk transaksi ditentukan oleh parameter kernel transactionLifetimeLimitSeconds. Untuk informasi lebih lanjut tentang parameter tersebut, lihat transactionLifetimeLimitSeconds.
Batasan
Transaksi terdistribusi tidak mengizinkan Anda untuk membuat koleksi dan indeks baru.
Transaksi tidak dapat ditulis ke koleksi capped.
Transaksi tidak dapat menggunakan tingkat baca snapshot untuk membaca koleksi capped. Hal ini berlaku untuk MongoDB 5.0 atau yang lebih baru.
Transaksi tidak dapat membaca atau menulis koleksi di database bernama
config/admin/local.Transaksi tidak dapat menulis data ke koleksi sistem dalam format
system.*.Transaksi tidak mendukung
explain.Transaksi tidak dapat menggunakan
getMoreuntuk membaca kursor yang dibuat di luar transaksi. Kursor yang dibuat dalam transaksi tidak dapat dibaca menggunakangetMoredi luar transaksi.Operasi pertama dalam transaksi tidak dapat berupa
killCursors/hello.Perintah non-CRUD seperti
listCollections, listIndexes, createUser, getParameter, dan counttidak dapat dieksekusi dalam transaksi.Anda tidak dapat mengatur parameter writeConcernMajorityJournalDefault menjadi false untuk shard dalam transaksi terdistribusi. Untuk informasi lebih lanjut tentang parameter tersebut, lihat writeConcernMajorityJournalDefault.
Transaksi terdistribusi tidak mendukung shard yang mengandung arbiter. Untuk informasi lebih lanjut tentang arbiter, lihat Production Considerations.
Praktik terbaik
Gunakan transaksi mandiri alih-alih transaksi terdistribusi
Dalam sebagian besar skenario, transaksi terdistribusi memberikan performa yang lebih buruk daripada transaksi mandiri atau operasi tulis yang tidak melibatkan transaksi. Hal ini karena operasi yang melibatkan transaksi memerlukan operasi yang lebih kompleks. Model data denormalisasi (dokumen tertanam dan struktur array) adalah pilihan optimal untuk pemodelan data di ApsaraDB for MongoDB. Pemodelan data yang masuk akal dan transaksi mandiri dapat sepenuhnya memenuhi persyaratan transaksi aplikasi Anda dalam sebagian besar skenario.
Hindari transaksi jangka panjang
Secara default, ApsaraDB for MongoDB secara otomatis membatalkan transaksi terdistribusi yang berjalan lebih dari 60 detik. Untuk menyelesaikan masalah timeout, bagi transaksi menjadi bagian-bagian yang lebih kecil untuk mengeksekusi transaksi dalam periode waktu tertentu. Pastikan bahwa pernyataan query dioptimalkan dan berikan cakupan indeks yang sesuai untuk mengakses data dalam transaksi dengan cepat.
Jangan modifikasi sejumlah besar dokumen dalam transaksi
ApsaraDB for MongoDB tidak memberlakukan batasan jumlah dokumen yang dapat dibaca dalam transaksi. Namun, jika Anda memodifikasi sejumlah besar dokumen dalam transaksi, beban kerja sinkronisasi data antara node utama dan sekunder dapat meningkat, yang menyebabkan penundaan sinkronisasi dan masalah lain pada node sekunder. Kami merekomendasikan agar Anda memodifikasi hingga 1.000 dokumen dalam transaksi. Jika Anda ingin memodifikasi lebih dari 1.000 dokumen dalam transaksi, kami merekomendasikan agar Anda membagi transaksi menjadi beberapa bagian dan memodifikasi dokumen dalam batch.
Jangan jalankan transaksi besar yang melebihi ukuran 16 MB
Dalam MongoDB 4.0, transaksi diwakili oleh entri oplog tunggal. Entri tersebut harus berukuran maksimal 16 MB. Di ApsaraDB for MongoDB, oplog mencatat konten tambahan dalam kasus operasi pembaruan, dan mencatat seluruh dokumen dalam kasus operasi penyisipan. Oleh karena itu, semua catatan oplog untuk semua pernyataan dalam transaksi harus berukuran maksimal 16 MB. Jika batas ini terlampaui, transaksi akan dibatalkan dan sepenuhnya dibatalkan. Kami merekomendasikan agar Anda membagi transaksi besar menjadi set operasi yang lebih kecil yang masing-masing berukuran 16 MB atau kurang.
MongoDB 4.2 atau yang lebih baru membuat beberapa entri oplog untuk menyimpan semua operasi tulis dalam transaksi. Dengan cara ini, transaksi tunggal dapat melebihi ukuran 16 MB. Namun, kami merekomendasikan agar Anda tetap menjaga ukuran transaksi dalam 16 MB. Transaksi besar dapat menyebabkan masalah lain.
Rancang logika yang tepat untuk menangani rollback transaksi di klien Anda
Ketika transaksi dibatalkan secara abnormal, pengecualian dikembalikan ke driver dan transaksi dibatalkan. Tambahkan logika untuk menangkap dan mencoba kembali transaksi yang dibatalkan karena pengecualian sementara, seperti pergantian primary/secondary dan kegagalan node, ke aplikasi Anda. Driver yang disediakan oleh ApsaraDB for MongoDB menggunakan tulisan yang dapat diulang untuk secara otomatis mencoba kembali komit transaksi. Namun, aplikasi Anda tetap perlu menangani pengecualian dan kesalahan transaksi yang tidak dapat diselesaikan oleh tulisan yang dapat diulang seperti TransactionTooLarge, TransactionTooOld, dan TransactionExceededLifetimeLimitSeconds. Untuk informasi lebih lanjut tentang tulisan yang dapat diulang, lihat Retryable Writes.
Hindari operasi DDL dalam transaksi
Operasi DDL pada koleksi, seperti createIndex atau dropDatabase, diblokir oleh transaksi aktif yang berjalan pada koleksi. Dalam hal ini, semua transaksi yang mencoba mengakses koleksi yang sama tidak dapat memperoleh kunci dalam waktu tertentu, yang menyebabkan transaksi baru dibatalkan.
MongoDB 4.4 atau yang lebih baru mengoptimalkan batasan terkait yang ditentukan oleh parameter shouldMultiDocTxnCreateCollectionAndIndexes. Anda dapat melakukan operasi createCollection atau createIndex pada transaksi terdistribusi. Namun, operasi tersebut memiliki batasan berikut. Untuk informasi lebih lanjut tentang parameter tersebut, lihat MongoDB Server Parameters.
Anda hanya dapat secara implisit membuat koleksi.
Anda dapat melakukan operasi pada koleksi yang tidak ada.
Anda dapat melakukan operasi pada koleksi yang tidak berisi data.
Oleh karena itu, kami merekomendasikan agar Anda menghindari operasi DDL dalam transaksi.
Gulung balik transaksi yang tidak ingin Anda komit dan transaksi yang memiliki kesalahan secepat mungkin
Semua modifikasi transaksi yang tidak dikomit disimpan dalam cache WiredTiger. Jika sistem berisi beberapa transaksi yang tidak ingin Anda komit dan transaksi yang memiliki kesalahan, cache WiredTiger mungkin mengalami beban yang lebih tinggi dan menyebabkan masalah lain. Kendalikan durasi operasi pada transaksi dan gulung balik transaksi yang tidak ingin Anda komit secepat mungkin untuk melepaskan sumber daya.
Tingkatkan nilai parameter terkait timeout jika transaksi sering dibatalkan karena timeout untuk mendapatkan kunci
Secara default, jika operasi dalam transaksi tidak dapat memperoleh kunci yang diperlukan dalam 5 milidetik, transaksi secara otomatis dibatalkan. Jika transaksi dibatalkan atau disimpan, transaksi melepaskan semua kunci yang ditempati. Jika transaksi sering dibatalkan karena timeout untuk mendapatkan kunci, tingkatkan nilai parameter maxTransactionLockRequestTimeoutMillis. Untuk informasi lebih lanjut, lihat maxTransactionLockRequestTimeoutMillis.
Jika masalah tetap ada, tinjau operasi dalam transaksi, periksa apakah transaksi berisi operasi yang mungkin menempati kunci untuk waktu yang lama, seperti operasi DDL dan query yang perlu dioptimalkan.
Hindari konflik tulis yang disebabkan oleh memodifikasi dokumen yang sama di dalam dan di luar transaksi
Jika operasi tulis di luar transaksi yang sedang berlangsung telah memodifikasi dokumen, dan operasi dalam transaksi juga mencoba memodifikasi dokumen, transaksi dibatalkan karena konflik tulis. Jika transaksi yang sedang berlangsung telah memperoleh kunci yang diperlukan untuk memodifikasi dokumen, operasi tulis eksternal harus menunggu hingga transaksi selesai sebelum mereka dapat memodifikasi dokumen.
Saat konflik tulis terjadi, operasi tulis di luar transaksi tidak gagal atau mengembalikan kesalahan ke klien Anda. ApsaraDB for MongoDB terus mencoba operasi dan menambahkan penghitung writeConflicts setiap kali hingga operasi berhasil. Klien Anda tidak menyadari pengecualian tersebut. Namun, permintaan membutuhkan waktu lama untuk direspons.
Dalam sebagian besar kasus, sejumlah kecil konflik tulis tidak memiliki dampak signifikan. Namun, jika sejumlah besar konflik tulis terjadi, performa database mungkin menurun. Anda dapat menggunakan log audit atau log kueri lambat untuk memeriksa apakah sejumlah besar konflik tulis terjadi.
Risiko kernel
Jika Anda membuat transaksi jangka panjang atau mencoba melakukan sejumlah besar operasi dalam transaksi, cache WiredTiger mengalami beban tinggi karena cache harus menyimpan data dan mempertahankan status data untuk semua operasi tulis berikutnya dalam transaksi yang belum dikomit. Transaksi yang sedang berlangsung menggunakan snapshot yang sama. Oleh karena itu, operasi tulis baru terus bertambah di cache WiredTiger selama transaksi berjalan. Operasi tulis di cache WiredTiger dapat dihapus sampai transaksi yang berjalan di snapshot lama disimpan atau dibatalkan. Dalam sebagian besar kasus, beban berlebih cache WiredTiger yang disebabkan oleh transaksi jangka panjang menghasilkan lebih banyak masalah, seperti database macet, peningkatan latensi respons yang signifikan, pemanfaatan CPU tinggi, bahkan deadlock yang memengaruhi bisnis Anda. Beban berlebih cache terjadi ketika pemanfaatan cache dan pemanfaatan cache kotor mesin penyimpanan WiredTiger melebihi ambang batas tertentu. Untuk informasi lebih lanjut tentang risiko kernel, lihat SERVER-50365 dan SERVER-51281.
Untuk mencegah risiko, kami merekomendasikan agar Anda meningkatkan instance ApsaraDB for MongoDB Anda yang sering menangani transaksi jangka panjang atau melakukan sejumlah besar operasi dalam transaksi ke MongoDB 5.0 atau yang lebih baru.
Read Concern
Informasi latar belakang
Read Concern menyediakan tingkat konsistensi data dan isolasi berikut. Untuk informasi lebih lanjut, lihat Read Concern.
"local": Default untuk membaca terhadap node primer atau node sekunder dalam instance replika set. Data dibaca dari database lokal. Data yang dibatalkan mungkin dibaca."available": Default untuk membaca terhadap node sekunder dalam instance kluster sharded. Data yang dibatalkan mungkin dibaca. Versi shard tidak diperiksa sebelum data dibaca. Oleh karena itu, dokumen yatim mungkin dibaca. Tingkat ini memberikan latensi akses terendah."majority": Data yang diakui oleh mayoritas node dibaca. Data tidak dibatalkan."linearizable": Tingkat linearisasi yang memerlukan konsistensi data tertinggi. Operasi baca harus menunggu hingga semua operasi tulis diakui oleh mayoritas node. Tingkat ini memberikan performa terburuk dan hanya tersedia untuk node primer."snapshot": Data yang diakui oleh mayoritas node dibaca berdasarkan snapshot. Snapshot pada titik waktu tertentu dapat dikaitkan dengan operasi baca. Anda dapat mengonfigurasi parameter atClusterTime untuk menentukan timestamp untuk operasi baca. Untuk informasi lebih lanjut tentang parameter tersebut, lihat Read Concern and atClusterTime.
Perhatikan item berikut:
Data terbaru pada node mongos tidak mewakili versi terbaru data dalam instance replika set terlepas dari tingkat read concern.
Anda dapat menentukan tingkat read concern yang berbeda untuk operasi yang berbeda. Anda juga dapat menentukan tingkat read concern default untuk instance yang menjalankan MongoDB 4.4 atau yang lebih baru pada server. Tingkat read concern operasi memiliki prioritas lebih tinggi daripada yang ada di server.
Saat data dibaca dari database
local, tingkat read concern yang Anda tentukan diabaikan. Dalam hal ini, Anda selalu dapat membaca semua data lokal dari databaselocal.Transaksi terdistribusi hanya mendukung tingkat read concern
"local","majority", dan"snapshot".Sesi konsisten secara kausal hanya mendukung tingkat read concern
"majority".
Praktik terbaik
Tentukan tingkat read concern hanya untuk transaksi terdistribusi
Anda tidak perlu menentukan tingkat read concern untuk setiap operasi dalam transaksi terdistribusi. Tingkat read concern transaksi menggantikan pengaturan lain atau tingkat read concern default.
Read Concern, mirip dengan Write Concern, dapat diterapkan pada semua query pada database terlepas dari apakah query dilakukan pada dokumen tunggal atau sekumpulan dokumen atau dienkapsulasi dalam transaksi baca multi-dokumen.
Gunakan tingkat read concern "majority" dalam sebagian besar kasus
Untuk memastikan konsistensi dan isolasi data, kami merekomendasikan agar Anda menggunakan tingkat read concern "majority". Aplikasi Anda hanya dapat membaca data ketika data direplikasi ke mayoritas node dalam instance replika set. Oleh karena itu, data tidak dibatalkan ketika node dipilih sebagai node primer.
Baca data dari node primer dan gunakan tingkat read concern "local" atau "linearizable" dalam skenario di mana tulisan sendiri dibaca
Untuk membaca modifikasi yang ditulis secepat mungkin setelah operasi tulis selesai, baca data dari node primer dan gunakan tingkat read concern "local" atau "linearizable". Jika tingkat write concern "majority" digunakan, tingkat read concern "majority" dapat digunakan.
Anda dapat menggunakan sesi konsisten secara kausal untuk instance yang menjalankan MongoDB 3.6 atau yang lebih baru dalam skenario tersebut.
Konfigurasikan parameter maxTimeMS jika tingkat read concern "linearizable" digunakan dalam skenario yang memerlukan konsistensi data tertinggi
Tingkat read concern "linearizable" memastikan bahwa node primer dalam instance replika set masih merupakan node primer instance ketika data dibaca dari node dan bahwa data yang dikembalikan oleh node tidak dibatalkan ketika node dipilih sebagai node primer baru. Namun, tingkat ini memiliki dampak signifikan pada latensi. Konfigurasikan parameter maxTimeMS untuk mencegah operasi baca diblokir tanpa batas ketika mayoritas node gagal.
Write Concern
Informasi latar belakang
Gunakan format berikut untuk mengonfigurasi Write Concern: Untuk informasi lebih lanjut tentang Write Concern, lihat Write Concern.
{ w: <value>, j: <boolean>, wtimeout: <number> }Write Concern yang menentukan tingkat jaminan persistensi data menyediakan tingkat berikut:
{w: 0}: Operasi tulis tidak diakui selesai dan data yang ditulis mungkin hilang.
{w: 1}: Operasi tulis diakui selesai. Default untuk instance yang menjalankan versi sebelum MongoDB 5.0. Kehilangan data mungkin terjadi karena data tidak disimpan secara persisten.
{j: true}: Operasi tulis diakui selesai dan disiram ke log WAL yang disimpan secara persisten. Operasi tidak hilang.
{ w: "majority" }: Operasi tulis dapat diakui hingga operasi direplikasi ke mayoritas node dalam instance replika set. Data tidak dibatalkan. Default untuk instance yang menjalankan MongoDB 5.0 atau yang lebih baru.
Pengakuan replika: Operasi tulis dapat diakui hingga operasi direplikasi ke sejumlah node tertentu dalam instance replika set.
Pengakuan kustom: Konfigurasikan parameter settings.getLastErrorModes untuk menentukan metode pengakuan kustom lainnya menggunakan tag. Untuk informasi lebih lanjut tentang parameter tersebut, lihat settings.getLastErrorModes.
Perhatikan item berikut:
Anda dapat menentukan tingkat write concern untuk operasi tulis atau transaksi. Jika Anda tidak menentukan tingkat, tingkat write concern default digunakan.
CatatanTingkat write concern global default diubah dari
{w:1}menjadi{w:"majority"}pada instance yang menjalankan MongoDB 5.0 atau yang lebih baru dan menggunakan arsitektur topologi tiga-replika standar. Hal ini dapat menyebabkan penurunan performa setelah Anda meningkatkan instance Anda ke MongoDB 5.0 atau yang lebih baru.Node tersembunyi, node latensi, atau node lain dengan prioritas 0 dalam instance replika set dapat dianggap sebagai anggota node yang ditentukan oleh tingkat write concern
"majority".Anda dapat menentukan tingkat write concern yang berbeda untuk operasi yang berbeda. Anda juga dapat menentukan tingkat write concern default untuk instance yang menjalankan MongoDB 4.4 atau yang lebih baru pada server. Tingkat write concern operasi memiliki prioritas lebih tinggi daripada yang ada di server.
Saat data ditulis ke database
local, tingkat write concern yang Anda tentukan diabaikan.Sesi konsisten secara kausal hanya mendukung tingkat write concern
"majority".
Praktik terbaik
Tentukan tingkat write concern hanya untuk transaksi terdistribusi
Anda tidak perlu menentukan tingkat write concern untuk setiap operasi tulis dalam transaksi. Jika tidak, kesalahan akan dilaporkan.
Gunakan tingkat write concern "majority" dalam skenario umum
Tingkat write concern “majority" memastikan bahwa mayoritas node dalam instance replika set mengakui operasi tulis. Kehilangan data atau pembatalan tidak terjadi jika terjadi kegagalan node atau pergantian primary/secondary mengalami pengecualian.
Gunakan tingkat write concern {w:1} dalam skenario yang memerlukan performa tulis tertinggi dan fokus pada latensi replikasi node sekunder
Dalam sebagian besar kasus, tingkat write concern {w:1} memberikan performa tulis yang lebih tinggi dan cocok untuk skenario di mana frekuensi tulis tinggi. Perhatikan latensi replikasi pada node sekunder. Jika latensi replikasi tinggi, node primer mungkin gagal dibatalkan. Untuk informasi lebih lanjut, lihat ROLLBACK. Jika latensi replikasi melebihi periode retensi oplog, node sekunder masuk ke status pemulihan abnormal dan gagal pulih secara otomatis dari kegagalan, yang mengurangi ketersediaan instance. Untuk informasi lebih lanjut tentang status tersebut, lihat RECOVERING.
Masalah di atas dapat terjadi dalam instance ApsaraDB for MongoDB yang menjalankan versi sebelum MongoDB 5.0 ketika Anda menulis batch sejumlah besar data ke instance atau menggunakan Data Transmission Service (DTS) untuk memigrasi data ke instance. Untuk menyelesaikan masalah ini, kami merekomendasikan agar Anda menggunakan tingkat write concern "majority".
Tentukan tingkat write concern yang tepat untuk operasi
Tentukan tingkat write concern untuk operasi berdasarkan persyaratan operasi. Misalnya, Anda dapat menggunakan transaksi dengan tingkat write concern yang ditentukan untuk data transaksi keuangan untuk memastikan atomicitas, gunakan tingkat write concern "majority" untuk data pemain inti untuk memastikan bahwa data tidak dibatalkan, dan gunakan tingkat write concern default atau {w:1} untuk data log.
ApsaraDB for MongoDB menyediakan fleksibilitas yang ditingkatkan untuk memungkinkan Anda menentukan tingkat write concern berdasarkan kebutuhan bisnis Anda.