Pertimbangan Prestasi Transaksi
Pelajar akan mengukur overhed transaksi berbilang dokumen dan mereka bentuk skema yang meminimumkan keperluan terhadapnya dalam laluan panas.
Pertimbangan Prestasi Transaksi ialah pelajaran MongoDB Academy percuma di CoddyKit. Ini ialah pelajaran 4 daripada 4. Anda boleh membaca keseluruhan pelajaran di bawah secara percuma — kemudian berlatih secara praktikal dalam pelayar menggunakan penyunting kod terbina dalam dan tutor kecerdasan buatan 24/7. Pelajaran ini merupakan sebahagian daripada laluan pembelajaran MongoDB Academy, dan kemajuan anda disegerakkan merentas web serta aplikasi CoddyKit. Kursus MongoDB Academy merangkumi sejumlah 4 pelajaran.
Transaksi Mempunyai Overhed Sebenar
Transaksi berbilang dokumen dalam MongoDB menyediakan jaminan ACID yang kukuh tetapi melibatkan overhed prestasi yang boleh diukur. Transaksi ini melibatkan perjalanan pergi balik rangkaian tambahan untuk pengurusan sesi, mengekalkan kunci yang menyekat penulis serentak, menggunakan ruang oplog dan memerlukan penyelarasan merentas ahli set replika untuk keprihatinan tulis majoriti. Memahami overhed ini membantu anda mereka bentuk sistem yang hanya menggunakan transaksi apabila diperlukan.
Perebutan Kunci dan Konflik Tulis
Transaksi MongoDB menggunakan penguncian pada peringkat dokumen dengan kawalan keserentakan optimistik. Apabila transaksi membaca dokumen, transaksi mengambil gambaran tetapi tidak menguncinya. Pada masa pelaksanaan, MongoDB menyemak sama ada penulis lain telah mengubah dokumen tersebut—jika ya, transaksi dibatalkan dengan konflik tulis. Konflik yang kerap menunjukkan bahawa berbilang transaksi bersaing untuk dokumen yang sama dan sangat sibuk, lalu menyebabkan percubaan semula serta pengurangan daya pemprosesan.
// A 'hot document' that many transactions modify simultaneously
// causes frequent WriteConflict errors and retry storms:
db.counters.updateOne({ _id: 'globalOrderCount' }, { $inc: { value: 1 } }, { session });
// Better: use $inc on individual order documents (sharded by orderId),
// or use a dedicated sequence generator outside the transaction.Kos Pengasingan Gambar
Transaksi membaca daripada gambar konsisten yang diambil pada masa transaksi bermula. Apabila penulis lain melaksanakan perubahan sepanjang jangka hayat transaksi anda, MongoDB mesti mengekalkan versi lama dokumen yang diubah (melalui mekanisme MVCC WiredTiger) supaya transaksi anda masih dapat melihat gambar tersebut. Transaksi yang berjalan lama menyebabkan WiredTiger mengekalkan lebih banyak sejarah versi dalam memori dan cakera, lalu berpotensi mencetuskan tekanan cache yang memperlahankan keseluruhan kluster.
Had 60 Saat Wujud atas Sebab yang Munasabah
MongoDB membatalkan transaksi yang melebihi 60 saat (boleh dikonfigurasikan, tetapi jarang sekali patut ditambah). Transaksi yang berjalan selama beberapa minit mengekalkan data gambar dan menghalang pemangkasan oplog. Inilah sebabnya operasi yang berjalan lama seperti pemprosesan kelompok, pengagregatan kompleks atau menunggu respons API luaran tidak boleh sama sekali dilakukan dalam transaksi. Pastikan transaksi mengambil masa milisaat, bukan saat.
// WRONG: calling an external API inside a transaction
await session.withTransaction(async () => {
const order = await db.collection('orders').findOne({ _id: orderId }, { session });
const result = await externalPaymentAPI.charge(order.amount); // Could take seconds!
await db.collection('orders').updateOne({ _id: orderId }, { $set: { paid: true } }, { session });
});
// RIGHT: call external API outside the transaction
const result = await externalPaymentAPI.charge(amount); // Do this FIRST
if (result.success) {
await db.collection('orders').updateOne({ _id: orderId }, { $set: { paid: true, txnId: result.id } });
}Had Saiz Oplog: 16 MB bagi Setiap Transaksi
Setiap operasi tulis dalam transaksi direkodkan dalam oplog. MongoDB mengehadkan jumlah ruang oplog yang boleh digunakan oleh satu transaksi kepada kira-kira 16 MB. Jika transaksi anda melibatkan sejumlah besar dokumen atau dokumen yang besar, transaksi itu boleh melebihi had ini dan dibatalkan dengan ralat TransactionTooLarge. Jika anda perlu memproses kelompok besar, pecahkannya kepada transaksi yang lebih kecil, setiap satunya mengandungi beberapa ratus dokumen.
// WRONG: inserting 100,000 documents in one transaction
await session.withTransaction(async () => {
for (const doc of largeArray) { // 100k docs = way over 16MB
await db.collection('logs').insertOne(doc, { session });
}
});
// RIGHT: batch into smaller transactions of ~500 docs
const BATCH_SIZE = 500;
for (let i = 0; i < largeArray.length; i += BATCH_SIZE) {
const batch = largeArray.slice(i, i + BATCH_SIZE);
await session.withTransaction(async () => {
await db.collection('logs').insertMany(batch, { session });
});
}Reka Bentuk Skema untuk Meminimumkan Transaksi
Pengoptimuman prestasi terbaik untuk transaksi ialah menggunakannya dengan lebih sedikit. Atomisiti satu dokumen MongoDB bermaksud operasi pada satu dokumen sentiasa mematuhi ACID. Reka bentuk skema anda supaya operasi yang mesti atomik menyentuh sesedikit dokumen yang mungkin. Pendekatan paling berkesan ialah membenamkan data berkaitan yang sentiasa dikemas kini bersama-sama ke dalam satu dokumen.
// Without embedding: two documents to update atomically (needs transaction)
await accounts.updateOne({ _id: userId }, { $set: { name: 'Alice' } }, { session });
await profiles.updateOne({ userId: userId }, { $set: { displayName: 'Alice' } }, { session });
// With embedding: one document — no transaction needed
await users.updateOne(
{ _id: userId },
{ $set: { name: 'Alice', 'profile.displayName': 'Alice' } }
// No session needed — single-document update is atomicMengukur Overhed Transaksi
Gunakan explain('executionStats') dan pemprofil pangkalan data untuk mengukur overhed sebenar transaksi anda. Transaksi muncul dalam log pertanyaan perlahan dan koleksi system.profile dengan medan transaction yang telah diisi. Jejaki metrik seperti tempoh purata transaksi, kadar konflik penulisan dan bilangan percubaan semula bagi setiap jenis transaksi. Metrik ini menunjukkan sama ada overhed transaksi menjejaskan belanjawan kependaman aplikasi anda.
// Enable the profiler to capture slow transactions (threshold: 100ms)
db.setProfilingLevel(1, { slowms: 100 });
// Query the profile for recent slow transactions
db.system.profile.find(
{ 'transaction': { $exists: true } },
{ millis: 1, 'transaction.timingStats': 1, op: 1 }
).sort({ ts: -1 }).limit(10);Mengelakkan Kunci yang Dipegang Lama Dengan findOneAndUpdate
Apabila anda perlu menyemak dan mengubah suai satu dokumen secara atomik, findOneAndUpdate menyediakan keatomikan ACID tanpa transaksi. Ia mencari dokumen yang sepadan dengan penapis secara atomik, menggunakan kemas kini dan mengembalikan sama ada dokumen lama atau baharu dalam satu operasi pada pelayan. Ini ialah corak yang disyorkan untuk pola seperti uji-dan-tetapkan, pembilang atomik dan menuntut item baris gilir.
// Atomically claim a pending task — no transaction needed
const task = await db.collection('taskQueue').findOneAndUpdate(
{ status: 'pending' },
{ $set: { status: 'processing', claimedAt: new Date(), workerId: workerId } },
{ returnDocument: 'after', sort: { priority: -1 } }
);
if (!task) {
console.log('No pending tasks');
}Corak Komit Dua Fasa sebagai Alternatif
Sebelum MongoDB 4.0 memperkenalkan transaksi natif, pembangun melaksanakan komit dua fasa secara manual untuk mencapai keatomikan berbilang dokumen. Dalam corak ini, satu 'dokumen transaksi' pusat menjejaki keadaan operasi (tertunda, digunakan, selesai, dibalikkan). Walaupun transaksi natif lebih diutamakan pada masa ini, memahami komit dua fasa menerangkan sebab overhed transaksi wujud dan membantu dalam situasi yang tidak membenarkan transaksi digunakan (contohnya, kelompok terpecah merentas serpihan dalam versi MongoDB yang lebih lama).
// Two-phase commit concept (legacy pattern, prefer native transactions):
// 1. Insert a 'pending' transaction document
// 2. Apply to each document, recording txn ID
// 3. Update transaction to 'committed'
// 4. On failure, query for pending transactions and roll backKebimbangan Bacaan dan Pertukaran Prestasinya
Transaksi secara lalai menggunakan readConcern: 'snapshot', yang menyediakan pengasingan penuh tetapi mungkin perlu menunggu majoriti ahli set replika mengesahkan bahawa mereka telah menerima data terkini. readConcern: 'local' lebih pantas tetapi mungkin membaca data yang akan dibatalkan semasa pertukaran kuasa. Bagi kebanyakan transaksi aplikasi, 'snapshot' ialah pilihan yang betul. Gunakan 'local' hanya jika anda telah mempertimbangkan implikasi ketekalan dengan teliti.
// 'snapshot' — full isolation, may be slightly slower
session.startTransaction({ readConcern: { level: 'snapshot' }, writeConcern: { w: 'majority' } });
// 'local' — faster reads, weaker consistency guarantee
session.startTransaction({ readConcern: { level: 'local' }, writeConcern: { w: 'majority' } });Ringkasan: Peraturan Prestasi Transaksi
Lima peraturan untuk penggunaan transaksi berprestasi tinggi: (1) Pastikan transaksi singkat—milisaat, bukan saat. (2) Jangan sekali-kali melakukan I/O di luar pangkalan data dalam transaksi. (3) Kurangkan bilangan dokumen yang disentuh bagi setiap transaksi untuk mengurangkan skop konflik. (4) Gunakan operasi satu dokumen atau pembenaman apabila boleh supaya transaksi dapat dielakkan sepenuhnya. (5) Pantau kadar konflik penulisan dan reka bentuk semula dokumen yang sering diakses jika konflik kerap berlaku.
Semakan Pantas
Uji pemahaman anda tentang konsep MongoDB dan pangkalan data NoSQL daripada pelajaran ini.
Imbas Kembali Pelajaran
Dalam pelajaran ini, anda mempelajari bahawa: transaksi menambah overhed melalui pengasingan syot kilat, perebutan kunci dan penggunaan ruang oplog, transaksi hendaklah singkat (milisaat) dan jangan sekali-kali melakukan I/O perlahan di dalamnya, dan pengoptimuman terbaik selalunya ialah mereka bentuk semula skema supaya keatomikan satu dokumen menghapuskan keperluan terhadap transaksi berbilang dokumen. Seterusnya, kita akan meneroka change stream untuk suapan peristiwa masa nyata daripada koleksi MongoDB.
Pelajari JavaScript dengan tutor kecerdasan buatan — percuma
Tulis dan jalankan kod sebenar dalam pelayar anda, dapatkan bantuan segera daripada tutor kecerdasan buatan yang tersedia 24/7, dan sambung semula dari tempat anda berhenti di web atau dalam aplikasi.
- Kursus
- 30
- Pelajaran
- 120
Soalan Lazim
Adakah pelajaran “Pertimbangan Prestasi Transaksi” percuma?
Ya — teks penuh “Pertimbangan Prestasi Transaksi” boleh dibaca secara percuma di web ini. Untuk berlatih secara interaktif menggunakan penyunting kod terbina dalam dan tutor kecerdasan buatan 24/7, serta membuka kunci baki kursus MongoDB Academy, tingkat taraf kepada CoddyKit PRO. Kursus MongoDB Academy merangkumi sejumlah 4 pelajaran.
Apakah yang akan saya pelajari dalam “Pertimbangan Prestasi Transaksi”?
Pelajar akan mengukur overhed transaksi berbilang dokumen dan mereka bentuk skema yang meminimumkan keperluan terhadapnya dalam laluan panas. Anda berlatih MongoDB Academy menggunakan kod praktikal yang dijalankan terus dalam pelayar, manakala tutor kecerdasan buatan 24/7 menjawab soalan anda semasa anda mengikuti pelajaran.
Adakah saya memerlukan pengalaman untuk memulakan MongoDB Academy?
Tiada pengalaman terdahulu diperlukan. Pembelajaran MongoDB Academy di CoddyKit disusun untuk pelajar daripada peringkat pemula hingga lanjutan, jadi anda boleh bermula di sini atau dari awal dan belajar mengikut kadar anda sendiri. Ini ialah pelajaran 4 daripada 4.
Berapa lamakah pelajaran “Pertimbangan Prestasi Transaksi” diambil?
Kebanyakan pelajaran CoddyKit mengambil masa kira-kira 5–10 minit. Setiap pelajaran ringkas dan interaktif, jadi anda boleh membuat kemajuan secara berterusan dan menyambung tepat dari tempat anda berhenti di web atau aplikasi.
Bolehkah saya menulis dan menjalankan kod dalam pelajaran MongoDB Academy ini?
Ya. Setiap pelajaran MongoDB Academy menyertakan penyunting kod terbina dalam, jadi anda boleh menulis dan menjalankan kod sebenar terus dalam pelayar serta menerima maklum balas kecerdasan buatan serta-merta — tanpa memerlukan persediaan setempat.
Semua pelajaran dalam kursus ini
- Jaminan ACID dalam Gedung Dokumen Teragih
- Memulakan Sesi dan Transaksi Berbilang Dokumen
- Pengendalian Ralat dan Logik Percubaan Semula
- Pertimbangan Prestasi Transaksi