Urus niaga asid di mongodb

Ya, MongoDB menyokong urus niaga asid. 1. Ia menyokong operasi asid tunggal dari versi 4.0, dan urus niaga multi-dokumen dari 4.2, termasuk set replika dan kluster shard. 2. Urus niaga multi-dokumen perlu dimulakan melalui sesi. Semua operasi mesti diluluskan dalam sesi. Cuba Catch Handles Commits atau Rollbacks, dan akhirnya memanggil EndSession untuk melepaskan sumber. 3. Urus niaga ini mempunyai had tamat masa 60 saat, dan overhead prestasi adalah tinggi. Terutama urus niaga silang memerlukan koordinasi mongos, yang harus mengelakkan penggunaan jangka panjang atau frekuensi tinggi; 4. Eval, MapReduce dan arahan lain dilumpuhkan dalam transaksi, dan membaca dan menulis perhatian dan membaca keutamaan mesti ditetapkan pada tahap urus niaga; 5. Adalah disyorkan untuk menggunakan operasi atom tunggal terlebih dahulu, dan menggunakan urus niaga melalui model data tertanam untuk mengurangkan keperluan urus niaga untuk meningkatkan prestasi dan skalabiliti; 6. Ia sesuai untuk senario konsistensi yang kuat seperti pemindahan dan potongan inventori, tetapi masa urus niaga harus dipendekkan sebanyak mungkin untuk mengelakkan penyumbatan. Keupayaan asid MongoDB dapat memenuhi kebanyakan senario, dan kunci adalah memilih kaedah penggunaan mengikut perniagaan yang munasabah.

MongoDB menyokong urus niaga asid, tetapi pelaksanaannya berbeza daripada pangkalan data relasi tradisional, terutamanya dalam persekitaran yang diedarkan dengan batasan penggunaan dan amalan terbaik. Berikut adalah beberapa perkara utama untuk menggambarkan urus niaga asid di MongoDB.

Apa itu Asid?

Asid adalah empat sifat utama urus niaga pangkalan data:

• A TOMICITY: Semua operasi dalam transaksi sama ada berjaya atau gagal.
• C OnSistency: Sebelum dan selepas urus niaga dilaksanakan, pangkalan data berada dalam keadaan yang konsisten.
• I Solation: Urus niaga serentak tidak mengganggu satu sama lain.
• D urability: Setelah transaksi dilakukan, hasilnya kekal.

Di MongoDB, bermula dari versi 4.0, operasi tunggal dokumen adalah asid secara lalai . Bermula dalam versi 4.2, MongoDB menyokong urus niaga asid multi-dokumen , termasuk merentasi pelbagai koleksi, pangkalan data, dan juga kelompok sharded (secara beransur-ansur disokong dari 4.2).

Urus Niaga Multi-Dokumen: Skop Sokongan

Transaksi multi-dokumen MongoDB menyokong senario berikut:

• Set replika : disokong dari 4.0.
• Cluster Sharded : Disokong sejak 4.2, tetapi dengan lebih banyak batasan dan pertimbangan prestasi.

Nota: Urus niaga silang memerlukan penyelaras (mongos) untuk mengambil bahagian, yang mempunyai overhead prestasi yang lebih besar. Adalah disyorkan untuk mengelakkan penggunaan frekuensi tinggi sebanyak mungkin.

Cara Menggunakan Transaksi (Contoh)

Berikut adalah contoh transaksi berbilang dokumen menggunakan pemandu Node.js:

 const session = client.startSession ();
session.startTransaction ();

Cuba {
  const db = client.db ('bank');

  // Mengurangkan baki tiga db.collection ('akaun').
    {name: 'Zhangsan', Baki: {$ gte: 100}},
    {$ inc: {baki: -100}},
    {sesi}
  );

  // Meningkatkan baki li si menanti db.collection ('accounts'). UpdateOne (
    {name: 'lisi'},
    {$ inc: {baki: 100}},
    {sesi}
  );

  menunggu session.CommitTransaction ();
  console.log ('pemindahan berjaya');
} menangkap (ralat) {
  menunggu session.AbortTransaction ();
  Console.error ('Transaksi gagal, dilancarkan kembali', ralat);
} akhirnya {
  menunggu session.endSession ();
}

Mata Utama:

• session mesti digunakan untuk memulakan transaksi.
• Semua operasi mesti diluluskan dalam parameter session .
• Gunakan try-catch untuk mengendalikan pengecualian dan gulung kembali.
• Akhirnya, endSession() dipanggil untuk melepaskan sumber.

Sekatan penggunaan transaksi dan langkah berjaga -jaga

• Overhead prestasi tinggi : Urus niaga akan dikunci, dan urus niaga jangka panjang boleh menyebabkan penyumbatan.
• Had tamat masa : Secara lalai, urus niaga mesti diselesaikan dalam masa 60 saat (boleh diselaraskan melalui transactionLifetimeLimitSeconds , tetapi tidak disyorkan untuk terlalu lama).
• Sesetengah arahan tidak boleh digunakan dalam pelbagai transaksi shard : seperti eval , mapReduce , dll.
• ReadConcern, WriteConCern, dan ReadPreener perlu ditetapkan pada tahap urus niaga dan tidak boleh ditentukan secara berasingan dalam operasi.

Cadangan:

• Memendekkan masa pelaksanaan transaksi sebanyak mungkin.
• Elakkan melakukan permintaan rangkaian atau pengiraan yang memakan masa dalam urus niaga.
• Keutamaan diberikan kepada operasi atom dokumen tunggal, dan tiada urus niaga boleh digunakan.

Dokumen tunggal Atomicity: Pilihan pertama untuk pembangunan harian

Kemas kini dokumen tunggal MongoDB secara semulajadi menyokong atomik. Contohnya:

 db.accounts.updateOne (
  {Nama: "Zhangsan", Baki: {$ gte: 50}},
  {$ inc: {baki: -50}, $ push: {history: "Paid 50"}}
)

Operasi ini adalah atom: sama ada semua berjaya atau gagal, dan tidak akan ada keadaan di mana hanya wang yang ditolak dan sejarah tidak direkodkan.

Cadangan Reka Bentuk : Meletakkan data yang relevan dalam satu dokumen melalui dokumen atau tatasusunan tertanam boleh mengelakkan urus niaga berbilang dokumen, meningkatkan prestasi dan skalabiliti.

Meringkaskan

• MongoDB menyokong urus niaga asid, termasuk transaksi multi-dokumen (set replika dan kluster shard).
• Transaksi sesuai untuk operasi jangka pendek dengan keperluan konsistensi yang kuat , seperti pemindahan kewangan, potongan inventori, dll.
• Dalam perkembangan harian, lebih suka menggunakan pemodelan data dengan operasi atom-dokumen yang munasabah untuk mengelakkan urus niaga.
• Berhati -hati apabila menggunakan urus niaga dalam kelompok sharded, perhatikan prestasi dan had masa tamat.

Pada asasnya, keupayaan asid MongoDB cukup untuk mengatasi kebanyakan senario. Kuncinya ialah memilih kaedah penggunaan mengikut keperluan perniagaan.

Atas ialah kandungan terperinci Urus niaga asid di mongodb. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!