💭 👩🏽‍🍳 🌿 MongoDB में लेनदेन ⚜️ 👿 🍨

MongoDB एक शानदार डेटाबेस है जो हाल ही में तेजी से लोकप्रिय हुआ है। SQL अनुभव वाले अधिक से अधिक लोग इसका उपयोग करना शुरू कर रहे हैं, और उनमें से पहला प्रश्न है: MongoDB लेनदेन? ।

यदि आप स्टैकओवरफ्लो के साथ जवाब मानते हैं, तो सब कुछ खराब है।

MongoDB doesn't support complex multi-document transactions. If that is something you absolutely need it probably isn't a great fit for you.

 If transactions are required, perhaps NoSQL is not for you. Time to go back to ACID relational databases.

 MongoDB does a lot of things well, but transactions is not one of those things.

लेकिन हम MVCC पर आधारित लेनदेन (ACID * ) पर विश्वास और कार्यान्वयन नहीं करेंगे। नीचे एक कहानी है कि ये लेन-देन कैसे काम करते हैं, और उन लोगों के लिए जो कोड को देखने के लिए उत्सुक हैं, GitHub (ध्यान से, जावा) में आपका स्वागत है।

पोस्ट MongoDB के बारे में नहीं है, लेकिन लेन-देन बनाने के लिए तुलना-और-सेट का उपयोग कैसे करें, और स्थायित्व उसी हद तक प्रदान किया जाता है जब भंडारण इसे प्रदान करता है।

डेटा मॉडल

कई अन्य NoSQL समाधानों के विपरीत, MongoDB तुलना और सेट का समर्थन करता है। यह कैस समर्थन है जो आपको ACID लेनदेन जोड़ने की अनुमति देता है। यदि आप कैस समर्थन (उदाहरण के लिए, HBase, प्रोजेक्ट वोल्डेमॉर्ट या ज़ूकेटर) के साथ किसी अन्य NoSQL स्टोरेज का उपयोग करते हैं, तो वर्णित दृष्टिकोण वहां लागू किया जा सकता है।

कैस क्या है?
  ,      ,          .    -   ,     ,      . 

दरअसल, लेन-देन में बदलाव के लिए हम सभी वस्तुओं को कैस द्वारा संरक्षित किया जाना चाहिए, इससे डेटा मॉडल प्रभावित होता है। मान लीजिए कि हम एक बैंक के काम का अनुकरण करते हैं, नीचे एक खाता मॉडल है, जिसके साथ और बिना सुरक्षा के, मुझे आशा है कि यह स्पष्ट है कि बाकी को कैसे बदलना है।

निराश्रय बचाव पक्ष

आदर्श

 { _id : ObjectId(".."), name : "gov", balance : 600 }

 { _id : ObjectId(".."), version : 0, value : { name : "gov", balance : 600 } }

डेटा परिवर्तन

 db.accounts.update( { _id:ObjectId("...") }, { name:"gov", balance:550 } );

 db.accounts.update({ _id: ObjectId("..."), version: 0 },{ version : 1, value : { name:"gov", balance:550 } });

इसके अलावा, मैं इस तथ्य पर ध्यान केंद्रित नहीं करूंगा कि ऑब्जेक्ट का एक संस्करण है, और यह कि ऑब्जेक्ट में कोई भी परिवर्तन इसके संस्करण को ध्यान में रखता है, लेकिन यह याद रखना चाहिए और समझा जाना चाहिए कि प्रतिस्पर्धी पहुंच के साथ ऑब्जेक्ट में कोई भी परिवर्तन विफल हो सकता है।

वास्तव में, एक संस्करण जोड़ना उन सभी परिवर्तनों को नहीं है जो मॉडल को बनाने की आवश्यकता है ताकि यह लेनदेन का समर्थन करे, पूरी तरह से परिवर्तित मॉडल जैसे:

 { _id : ObjectId(".."), version : 0, value : { name : "gov", balance : 600 }, updated : null, tx : null }

जोड़े गए फ़ील्ड - अद्यतन और tx। यह ओवरहेड है जो लेनदेन प्रक्रिया में उपयोग किया जाता है। अद्यतन की संरचना मूल्य के समान है, जिसका अर्थ है - यह ऑब्जेक्ट का एक संशोधित संस्करण है, जो लेनदेन के गुजरने पर मूल्य में बदल जाएगा; tx, क्लास ऑब्जेक्ट का एक ऑब्जेक्ट है - एक वस्तु के _id के लिए एक विदेशी कुंजी जो लेनदेन का प्रतिनिधित्व करती है। लेन-देन का प्रतिनिधित्व करने वाली वस्तु भी कैस द्वारा संरक्षित है।

एल्गोरिथ्म

एल्गोरिथ्म की व्याख्या करने के लिए सरल है, इस तरह से समझाने के लिए कि इसकी शुद्धता स्पष्ट थी, अधिक जटिल; इसलिए यह आवश्यक होगा कि मैं उन्हें परिभाषित करने से पहले कुछ संस्थाओं के साथ काम करूंगा।

निम्नलिखित सत्य कथन, परिभाषाएँ और गुण हैं जिनसे एल्गोरिथ्म की रचना बाद में की जाएगी।

मान में हमेशा एक स्थिति होती है जो अतीत में किसी बिंदु पर सच थी
रीड ऑपरेशन डेटाबेस में डेटा को संशोधित कर सकता है
रीड ऑपरेशन इम्पोटेंट है
एक वस्तु तीन अवस्थाओं में हो सकती है: स्वच्छ - ग, गन्दा अप्राप्त - द, गन्दा अप्राप्त - द्
एक लेन-देन में, केवल राज्य में वस्तुओं को बदला जाता है: सी
राज्यों के बीच संभावित संक्रमण: सी → डी, डी → सी, डी → डीसी, डीसी → सी
लेन-देन-आरंभ किए गए परिवर्तन: c → d, d → dc, dc → c
पढ़ते समय संभव संक्रमण: डी → सी
यदि कोई संक्रमण d → c था, तो जिस लेनदेन के अंदर संक्रमण c → d था, वह कमिट होने पर गिर जाएगा
डेटाबेस के साथ काम करने पर कोई भी ऑपरेशन गिर सकता है
गिरे हुए रीडिंग ऑपरेशन को दोहराया जाना चाहिए
गिरे हुए रिकॉर्ड के साथ, आपको एक नया लेनदेन शुरू करना होगा
यदि कमिट विफल हो जाती है, तो आपको यह जांचने की आवश्यकता है कि क्या यह पारित हुआ है, यदि नहीं, तो फिर से लेनदेन दोहराएं
यदि लेन-देन का प्रतिनिधित्व करने वाली वस्तु (_id = tx) हटा दी गई थी, तो लेनदेन पारित हो गया

राज्यों

एक सफल स्थिति एक सफल लेनदेन के बाद एक वस्तु का वर्णन करता है: मूल्य में डेटा होता है, और ऊपर और tx शून्य होते हैं।

एक गंदा गैर-सुरक्षित राज्य लेनदेन के समय वस्तु का वर्णन करता है, अद्यतन में नया संस्करण होता है, और tx लेन-देन का प्रतिनिधित्व करने वाली वस्तु का _id होता है, यह वस्तु मौजूद होती है।

एक गंदे प्रतिबद्ध राज्य एक सफल लेनदेन के बाद एक वस्तु का वर्णन करता है, लेकिन जो खुद को साफ करने में कामयाब होने से पहले गिर गया, अपडेट में लेनदेन का प्रतिनिधित्व करने वाली वस्तु का एक नया संस्करण, tx - _id शामिल है, लेकिन वह वस्तु पहले ही हटा दी गई है।

लेन-देन

हम उन वस्तुओं को पढ़ते हैं जो लेनदेन में भाग लेते हैं
लेनदेन का प्रतिनिधित्व करने वाली एक वस्तु बनाएं (tx)
हम प्रत्येक वस्तु को एक नए मूल्य में अद्यतन करते हैं, और tx - tx._id में लिखते हैं
Tx ऑब्जेक्ट हटाएं
हम अद्यतन, और tx और अद्यतन nullify से प्रत्येक वस्तु के मूल्य में लिखते हैं

पढ़ना

वस्तु पढ़ें
यदि यह साफ है - इसे वापस करें।
यदि गंदा है, तो हम मूल्य को अद्यतन, और tx और अद्यतित शून्य से लिखते हैं
यदि गंदा एक नहीं है - tx के संस्करण को बदलें, अद्यतन और tx को nullify करें
चरण # 1 पर जाएं

उन लोगों के लिए जो अब शुद्धता के बारे में आश्वस्त नहीं हैं, होमवर्क यह सत्यापित करना है कि सभी गुण और कथन संतुष्ट हैं, और फिर उन्हें ACID साबित करने के लिए उपयोग करें

निष्कर्ष

हमने MongoDB में लेनदेन जोड़ा है। लेकिन वास्तव में, यह एक रामबाण नहीं है और उनकी सीमाएँ हैं, कुछ नीचे सूचीबद्ध हैं, और कुछ टिप्पणी में

सब कुछ अच्छी तरह से काम करता है (डेटाबेस सुसंगत है, लेन-देन खो नहीं जाता है) इस धारणा के तहत कि अगर हमें उस रिपॉजिटरी से पुष्टि मिली कि रिकॉर्ड पारित हो गया, तो यह वास्तव में पारित हो गया और यह डेटा खो नहीं जाएगा (लॉगिंग सक्षम होने पर मोंगा यह प्रदान करता है)
लेन-देन आशावादी है, इसलिए, जब किसी वस्तु को विभिन्न प्रवाह से उच्च आवृत्ति के साथ बदलते हैं, तो उनका उपयोग न करना बेहतर होता है
2n + 2 प्रश्नों का उपयोग एक वस्तु में n वस्तुओं को बदलने के लिए किया जाता है
समय के साथ, हम गिराए गए लेनदेन से tx वस्तुओं को जमा करेंगे - समय-समय पर हमें पुराने को हटाना होगा

।

पूछे जाने वाले प्रश्न

इस तरह के लेनदेन को तेज और अक्षम लॉगिंग के साथ कैसे मदद मिल सकती है?

सर्वर त्रुटि की स्थिति में, हम वास्तव में डेटाबेस का एक असंगत स्थिति प्राप्त कर सकते हैं, लेकिन हम रिकॉर्डिंग के समय क्लाइंट क्रैश के कारण असंगत स्थिति से खुद को बचाते हैं। यदि दूसरे का जोखिम पहले से अधिक है, तो लेनदेन का उपयोग करके हम सभी सिस्टम की विश्वसनीयता बढ़ाते हैं।

मैं एकल-नोड कॉन्फ़िगरेशन में मोंगा का उपयोग करता हूं, क्या लेनदेन मेरी मदद करेंगे?

हां, यदि आप जर्नलिंग का उपयोग करते हैं, तो आपको ईमानदार एसीआईडी लेनदेन मिलता है। यदि आप इसका उपयोग नहीं करते हैं, तो आप पहले से ही संभावित डेटा हानि से सहमत हैं, क्योंकि आप विश्वसनीयता बढ़ाने के लिए दूसरे तरीके का उपयोग नहीं कर रहे हैं - प्रतिकृति। और अगर आप सहमत हैं, तो सामान्य मोड में लेनदेन प्रतिस्पर्धी पहुंच और ग्राहक त्रुटियों के साथ स्थिरता बनाए रखते हैं, लेकिन यदि सर्वर क्रैश हो जाता है, तो इसे खोने का मौका है। लेकिन यह इतना डरावना नहीं है, क्योंकि अगर एक नोड गिरता है, तो सिस्टम अनुपलब्ध होगा, इसलिए आप पुनर्प्राप्ति प्रक्रिया को अधिक कठिन बना सकते हैं और नोड को पुनरारंभ करने से पहले स्थिरता को पुनर्स्थापित कर सकते हैं।

आधिकारिक प्रलेखन से दो-चरण लेनदेन का उपयोग क्यों नहीं किया जाता है?

क्योंकि वे एक से अधिक क्लाइंट के साथ काम नहीं करते हैं। वे अधिक सटीक रूप से काम करते हैं, लेकिन जंगली प्रतिबंधों के साथ:

एक तत्व पर सभी परिवर्तन सराहनीय होने चाहिए (समानता अब लागू नहीं होती है)
प्रत्येक थ्रेड में एक आईडी होनी चाहिए, इन थ्रेड्स को कभी भी मरना नहीं चाहिए और एक दूसरे के साथ संवाद करने में सक्षम होना चाहिए

अन्यथा, संगतता और उपलब्धता खो जाती है (जमे हुए लेनदेन संभव हैं - एकमात्र उचित कदम उन वस्तुओं को पढ़ने / लिखने से इनकार करना है जो इन लेनदेन में भाग लेते हैं)।

MongoDB में लेनदेन