क्या वास्तव में v4 से पहले MongoDB ACID के अनुरूप नहीं था?

Question

मैं एक डेटाबेस विशेषज्ञ नहीं हूं और कोई औपचारिक कंप्यूटर विज्ञान पृष्ठभूमि नहीं है, इसलिए मेरे साथ सहन करें। मैं वास्तविक विश्व नकारात्मक चीजों के प्रकार जानना चाहता हूं जो कि v4 से पहले के एक पुराने MongoDB संस्करण का उपयोग करने पर हो सकता है , जो ACID के अनुरूप नहीं थे । यह किसी भी ACID गैर-योग्य डेटाबेस पर लागू होता है।

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

लेकिन जब मैं MongoDB के बारे में बातचीत में शामिल होता हूं, तो हममें से जो डेटाबेस को वास्तव में कार्यान्वित करने के तकनीकी विवरणों को नहीं जानते हैं, वे इस तरह के बयानों के आसपास फेंकना शुरू करते हैं:

MongoDB, MySQL और Postgres की तुलना में तेज़ है, लेकिन एक लाख में 1 की तरह एक छोटा सा मौका है, कि यह "सही ढंग से काम नहीं करेगा"।

वह "सही ढंग से नहीं बचाएगा" भाग इस समझ का जिक्र है: यदि आप MongoDB को लिख रहे हैं, तो तुरंत एक पावर आउटेज सही है, एक विशेष रिकॉर्ड के लिए एक मौका है (कहते हैं कि आप 10 विशेषताओं वाले दस्तावेज़ों में पृष्ठदृश्य ट्रैक कर रहे हैं प्रत्येक), कि दस्तावेजों में से एक ने केवल 5 विशेषताओं को बचाया ... जिसका अर्थ है कि समय के साथ आपके पेजव्यू काउंटर "थोड़ा" बंद होने जा रहे हैं। आपको कभी पता नहीं चलेगा कि आप कितना जानते हैं, वे 99.999% सही होंगे, लेकिन 100% नहीं। ऐसा इसलिए है, क्योंकि जब तक आप इसे विशेष रूप से एक सामान्य परमाणु संचालन नहीं बनाते हैं , तब तक ऑपरेशन परमाणु होने की गारंटी नहीं है।

तो मेरा सवाल यह है कि MongoDB कब और क्यों "सही ढंग से नहीं बचा सकता है" की सही व्याख्या क्या है? ACID के कौन से भाग संतुष्ट नहीं करते हैं, और किन परिस्थितियों में, और आपको कैसे पता चलेगा कि आपके डेटा का 0.001% बंद है? क्या यह किसी तरह तय नहीं किया जा सकता है? यदि नहीं, तो इसका मतलब यह है कि आपको अपनी usersतालिका जैसी चीज़ों को MongoDB में संग्रहीत नहीं करना चाहिए , क्योंकि कोई रिकॉर्ड सहेज नहीं सकता है। लेकिन फिर, उस 1 / 1,000,000 उपयोगकर्ता को "फिर से साइन अप करने की कोशिश" करने की आवश्यकता हो सकती है, नहीं?

मैं सिर्फ एक सूची की तलाश कर रहा हूं कि कब / क्यों नकारात्मक चीजें एक गैर-कानूनी डेटाबेस जैसे कि MongoDB के साथ होती हैं, और आदर्श रूप से अगर कोई मानक वर्कअराउंड है (जैसे पृष्ठभूमि डेटा को क्लीन करने के लिए नौकरी चलाना, या केवल इसके लिए SQL का उपयोग करना, आदि) ।

Answer 1

MongoDB के साथ एक चीज़ जो आप खोते हैं, वह बहु-संग्रह (तालिका) लेनदेन है। MongoDB में परमाणु संशोधक केवल एक ही दस्तावेज़ के खिलाफ काम कर सकते हैं।

यदि आपको इन्वेंट्री से कोई आइटम निकालने और उसे उसी समय किसी के आदेश में जोड़ने की आवश्यकता है - तो आप नहीं कर सकते। जब तक उन दो चीजों - इन्वेंट्री और ऑर्डर - एक ही दस्तावेज़ में मौजूद हैं (जो वे शायद नहीं करते हैं)।

मैं एक बहुत ही समस्या का सामना कर रहा हूँ एक आवेदन में मैं पर काम कर रहा हूँ और से चुनने के लिए दो संभव समाधान थे:

1) अपने दस्तावेज़ों को सबसे अच्छे रूप में संरचित करें और परमाणु संशोधक का उपयोग कर सकते हैं जितना कि आप सबसे अच्छा कर सकते हैं और शेष बिट के लिए, पृष्ठभूमि प्रक्रिया को साफ करने के लिए रिकॉर्ड्स का उपयोग करें जो सिंक से बाहर हो सकता है। उदाहरण के लिए, मैं सूची से आइटम निकालता हूं और उन्हें परमाणु संशोधक का उपयोग करके उसी दस्तावेज़ के आरक्षित सूची में जोड़ता हूं।

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

यह स्पष्ट रूप से आदर्श से कम है, लेकिन इसके एक बड़े अनुप्रयोग का एकमात्र हिस्सा है जहां मोंगोडब पूरी तरह से आवश्यकता के अनुरूप नहीं है। इसके अलावा, यह अब तक निर्दोष रूप से काम करता है। यह कई परिदृश्यों के लिए संभव नहीं हो सकता है, लेकिन दस्तावेज़ संरचना का उपयोग करने के कारण, यह अच्छी तरह से फिट बैठता है।

2) MongoDB के साथ संयोजन में एक ट्रांसेक्शनल डेटाबेस का उपयोग करें। MongoDB (या कोई अन्य NoSQL) जो सबसे अच्छा काम करता है, उसे करते समय उन चीजों के लिए लेन-देन प्रदान करने के लिए MySQL का उपयोग करना आम है।

यदि # 1 से मेरा समाधान लंबे समय तक काम नहीं करता है, तो मैं आगे की जांच में MySQL के साथ MongoDB के संयोजन में करूंगा, लेकिन अब # 1 मेरी आवश्यकताओं के अनुरूप है।

Comments

" MongoDB में परमाणु संशोधक केवल एक ही संग्रह के खिलाफ काम कर सकते हैं " => मुझे लगता है कि आपका मतलब "एकल दस्तावेज़ के खिलाफ " था।

— अस्वच्छता

उत्कृष्ट जानकारी, आमतौर पर MySQL का उपयोग करने के सुझाव के अपवाद के साथ एक उत्कृष्ट उत्तर।

— डग मोलिनक्स

DB एक चीज जो आप MongoDB के साथ खोते हैं, वह बहु-संग्रह (तालिका) लेनदेन है। MongoDB में परमाणु संशोधक केवल एक दस्तावेज़ के खिलाफ काम कर सकते हैं d mongo doc ( docs.mongodb.com/v3.2/core/write-operations-atomicity ): "MongoDB में, एक एकल के स्तर पर एक लेखन ऑपरेशन परमाणु है दस्तावेज़, भले ही ऑपरेशन एक दस्तावेज़ में कई एम्बेडेड दस्तावेज़ों को संशोधित करता हो। "

— yoav.str

बहु-दस्तावेज़ ACID लेनदेन का अभाव अब ऐसा नहीं है। MongoDB ने घोषणा की कि वे v4.0 में आ रहे हैं। Mongodb.com/blog/post/multi-document-transactions-in-mongodb

— ग्रिगोरी मेलनिक

अभी के लिए, चूंकि MongoDB 4.0 बहु-दस्तावेज़ लेनदेन के साथ ACID कंप्लेंट mongodb.com/transactions है । एक पर नज़र mongodb.com/blog/post/...

— Ratah

Answer 2

यह वास्तव में सही नहीं है कि MongoDB एसीआईडी-अनुपालन नहीं है। इसके विपरीत, दस्तावेज़ स्तर पर MongoDB ACID-compilant है ।

किसी एकल दस्तावेज़ के लिए कोई भी अद्यतन है

• परमाणु: यह या तो पूरी तरह से पूरा हो जाता है या यह नहीं करता है
• संगत: कोई भी पाठक "आंशिक रूप से लागू" अपडेट नहीं देखेगा
• पृथक: फिर से, कोई भी पाठक "गंदा" नहीं पढ़ेगा
• टिकाऊ: (उपयुक्त लेखन चिंता के साथ)

MongoDB के पास क्या लेन - देन नहीं है - यानी, कई-दस्तावेज़ अद्यतन जिन्हें वापस रोल किया जा सकता है और ACID- अनुपालन कर रहे हैं।

ध्यान दें कि आप दो-चरण प्रतिबद्ध का उपयोग करके एकल दस्तावेज़ में ACID के अनुरूप अपडेट के शीर्ष पर लेन-देन का निर्माण कर सकते हैं ।

Comments

ध्यान दें कि दो-चरण के लेन-देन का लेनदेन ACID-अनुरूप नहीं है। जब तक मैंने लिंक का अनुसरण नहीं किया किसी कारण से मैं इसके विपरीत था।

— जस्टिन सी

लेखन चिंता विन्यास की परवाह किए बिना दस्तावेज़ स्तर पर वितरित MongoDB के स्थायित्व के बारे में कुछ सवाल है। ओपन-सोर्स टूल जेप्सेन ने पाया कि MAJORITY राइट चिंता के साथ नेटवर्क विभाजन के कारण डेटा खो सकता है। यहां राइट-अप देखें: aphyr.com/posts/284-call-me-maybe-mongodb

— jrullmann

एक एकल दस्तावेज़ के स्तर पर एसीआईडी ​​होना जो किसी तरह से आरडीबीएमएस में एकल रिकॉर्ड के बराबर है, कई मामलों में उपयोगी नहीं है। लेन-देन की अवधि एकल तालिका से संबंधित नहीं है, और आप दो चरण की व्यवस्था भी कर सकते हैं और कई XAResource शामिल कर सकते हैं, इसलिए एकल दस्तावेज़ का संदर्भ देते हुए ACID अनुपालन कुछ समस्याग्रस्त है, IMHO।

— येयर ज़स्लेवस्की

यैर से सहमत हूँ। "दस्तावेज़ स्तर पर एसीआईडी-अनुपालन" एक विक्रय बिंदु नहीं है। यह मूल रूप से सिर्फ "नहीं ACID शिकायत" का मतलब है। ACID का अर्थ कभी भी "सिर्फ एक पंक्ति / दस्तावेज़ / इकाई" के बारे में नहीं था। यह आपके डेटा को पूरे डेटाबेस में लगातार बनाए रखने के बारे में है।

— joshua.paling

Answer 3

एक अच्छी व्याख्या "स्टारबक्स डोंट यूज़ टू फेज कमिट" में निहित है ।

यह NoSQL डेटाबेस के बारे में नहीं है, लेकिन यह इस बिंदु को स्पष्ट करता है कि कभी-कभी आप एक लेन-देन खो सकते हैं या अस्थायी रूप से असंगत स्थिति में अपना डेटाबेस रख सकते हैं।

मैं इसे कुछ ऐसा नहीं मानता जो "निश्चित" होना चाहिए। एक ACID- कंप्लेंट रिलेशनल डेटाबेस का उपयोग करना है। जब आपका व्यवहार आपकी एप्लिकेशन आवश्यकताओं को पूरा करता है तो आप एक NoSQL विकल्प चुनते हैं।

Comments

किसी भी सादृश्य की तरह इसकी सीमाएँ हैं। सॉफ्टवेयर में, नए ऐरे [कैशियर] को बनाना आसान है और उन्हें प्रत्येक में सिंक्रोनस लेनदेन की प्रक्रिया करना है, जबकि वास्तविक दुनिया की लागत हास्यास्पद रूप से महंगी होगी।

— HRJ

Answer 4

मुझे लगता है कि अन्य लोगों ने पहले से ही अच्छे जवाब दिए। हालाँकि मैं यह जोड़ना चाहूंगा कि ACID NOSQL DBs (जैसे http://ravendb.net/ ) हैं। तो यह केवल निर्णय NOSQL नहीं है - कोई ACID बनाम ACID के साथ संबंध ...।

Comments

धन्यवाद @subGate किसी को भी वहाँ जो ravenDB के साथ अपने अनुभव को साझा कर सकते हैं और अगर यह वास्तव में आवश्यकता को पूरा करता है?

— नीर पेंगस

Answer 5

"सही ढंग से नहीं बचाएगा" का मतलब हो सकता है:

1. डिफ़ॉल्ट रूप से MongoDB ड्राइव में आपके परिवर्तनों को तुरंत नहीं बचाता है। इसलिए एक संभावना है कि आप किसी उपयोगकर्ता को "अपडेट सफल है" बताते हैं, पावर आउटेज होता है और अपडेट खो जाता है। MongoDB अद्यतन "स्थायित्व" के स्तर को नियंत्रित करने के लिए विकल्प प्रदान करता है। यह अन्य प्रतिकृति (ओं) के लिए इस अद्यतन (स्मृति में) को प्राप्त करने के लिए प्रतीक्षा कर सकता है, स्थानीय फ़ाइल फ़ाइल के लिए लिखने के लिए प्रतीक्षा करें, आदि।

2. एक ही संग्रह में कई संग्रह और यहां तक ​​कि कई दस्तावेज़ों के लिए "परमाणु" अपडेट आसान नहीं है। यह ज्यादातर मामलों में एक समस्या नहीं है क्योंकि इसे दो चरण की प्रतिबद्धताओं के साथ दरकिनार किया जा सकता है , या अपने स्कीमा को पुनर्गठन कर सकता है ताकि एक ही दस्तावेज़ में अपडेट किए जा सकें। यह प्रश्न देखें: दस्तावेज़ डेटाबेस: निरर्थक डेटा, संदर्भ, आदि (विशेषकर MongoDB)

Answer 6

MongoDB v4.0 के अनुसार, बहु-दस्तावेज़ ACID लेनदेन का समर्थन किया जाना है। स्नैपशॉट अलगाव के माध्यम से, लेन-देन डेटा के वैश्विक रूप से सुसंगत दृश्य प्रदान करेगा, और डेटा अखंडता बनाए रखने के लिए सभी-या-कुछ भी निष्पादन को लागू करेगा।

वे संबंधित दुनिया से लेनदेन की तरह महसूस करते हैं, जैसे:

with client.start_session() as s:
    s.start_transaction()
    try:
        collection.insert_one(doc1, session=s)
        collection.insert_one(doc2, session=s)
        s.commit_transaction()
    except Exception:
        s.abort_transaction()

Https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb देखें

Comments

MongoDB4.0 का पहला रिलीज़ उम्मीदवार बाहर है - लिंक्डइन

— ग्रिगोरि मेलनिक

Answer 7

कृपया के बारे में पढ़ें बेहतर समझने के लिए ACID गुणों के ।

इसके अलावा MongoDB प्रलेखन में आप एक प्रश्न और उत्तर पा सकते हैं ।

MongoDB ACID का अनुपालन नहीं है। एसीआईडी ​​अनुपालन की चर्चा के लिए नीचे पढ़ें।

1. MongoDB है A डॉक्यूमेंट लेवल पर ही टॉनिक है। यह परमाणु की परिभाषा का अनुपालन नहीं करता है जिसे हम संबंधपरक डेटाबेस सिस्टम से जानते हैं, विशेष रूप से ऊपर दिए गए लिंक पर। इस अर्थ में MongoDB ACID से A का अनुपालन नहीं करता है।
2. MongoDB Cडिफ़ॉल्ट रूप से ऑनसाइट है। हालाँकि, आप प्रतिकृति सेट में द्वितीयक सर्वर से पढ़ सकते हैं। सिर्फ तुम कर सकते हो इस मामले में अंतिम स्थिरता । यह उपयोगी है अगर आपको थोड़ा पुराना डेटा पढ़ने में कोई आपत्ति नहीं है।
3. MongoDB Iअलगाव की गारंटी नहीं देता (फिर से उपरोक्त परिभाषा के अनुसार):

1. कई समवर्ती पाठकों और लेखकों के साथ सिस्टम के लिए, MongoDB क्लाइंट को राइट ऑपरेशन रिटर्न से पहले एक लेखन ऑपरेशन के परिणाम पढ़ने की अनुमति देगा।
2. यदि जर्नल के शुरू होने से पहले ही मोंगॉड समाप्त हो जाता है, भले ही कोई लेखन सफलतापूर्वक लौट आए, तो प्रश्नों में डेटा पढ़ा जा सकता है जो मोंगोड के पुनरारंभ होने के बाद मौजूद नहीं होगा।

हालाँकि , MongoDB अलगाव में प्रत्येक दस्तावेज़ को सम्मिलित करता है (आवेषण और अद्यतन के लिए); केवल दस्तावेज़ स्तर पर, बहु-दस्तावेज़ लेनदेन पर नहीं।

4. Dपेशाब करने के संबंध में - आप इस व्यवहार को write concernविकल्प के साथ कॉन्फ़िगर कर सकते हैं , हालांकि यह सुनिश्चित नहीं है। शायद कोई बेहतर जानता हो।

मेरा मानना ​​है कि एसीआईडी ​​बाधाओं या इसी तरह NoSQL को स्थानांतरित करने के लिए कुछ शोध जारी है। यह एक चुनौती है क्योंकि NoSQL डेटाबेस आमतौर पर तेज़ (एर) हैं और ACID बाधाएं प्रदर्शन को काफी धीमा कर सकती हैं।

Answer 8

एकमात्र कारण परमाणु एकल-संग्रह के खिलाफ काम को संशोधित करता है क्योंकि मूंगबोड डेवलपर्स ने हाल ही में संग्रह चौड़ी राइट-लॉक के साथ एक डेटाबेस लॉक का आदान-प्रदान किया। यह निर्णय लेना कि यहाँ बढ़ी हुई संगति व्यापार-बंद के लायक थी। इसके मूल में, मोंगोडब एक मेमोरी-मैप्ड फ़ाइल है: उन्होंने बफर-पूल प्रबंधन को मशीन के वीवीएस सबसिस्टम में सौंप दिया है। क्योंकि यह हमेशा स्मृति में होता है, वे बहुत ही दानेदार तालों से दूर होने में सक्षम होते हैं: आप इसे धारण करते समय केवल मेमोरी में ही कार्य कर रहे होंगे, जो कि बहुत तेज़ होगा। यह एक पारंपरिक डेटाबेस सिस्टम से काफी भिन्न होता है जो कभी-कभी एक पैग्लॉक या एक रॉन्लॉक धारण करने के लिए I / O प्रदर्शन करने के लिए मजबूर किया जाता है।

Comments

क्या आप बता सकते हैं कि यह क्यों बढ़ जाती है? क्षमा करें, अगर मुझे यहाँ स्पष्ट याद आ रही है।

— बल्लेबाजी

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

— jrullmann

Answer 9

"MongoDB में, एक एकल दस्तावेज़ पर एक ऑपरेशन परमाणु है" - यह अतीत की बात है

MongoDB 4.0 के नए संस्करण में आप कर सकते हैं:

हालाँकि, ऐसी स्थितियों के लिए जिन्हें कई दस्तावेज़ों के अपडेट के लिए परमाणुता की आवश्यकता होती है या कई दस्तावेज़ों के बीच स्थिरता होती है, MongoDB प्रतिकृति सेटों के विरुद्ध बहु-दस्तावेज़ लेनदेन करने की क्षमता प्रदान करता है। मल्टी-डॉक्यूमेंट ट्रांजैक्शंस का इस्तेमाल कई ऑपरेशंस, कलेक्शन, डेटाबेस और डॉक्यूमेंट्स में किया जा सकता है। बहु-दस्तावेज़ लेनदेन एक "ऑल-एंड-नथिंग" प्रस्ताव प्रदान करते हैं। जब कोई लेन-देन शुरू होता है, तो लेनदेन में किए गए सभी डेटा परिवर्तन सहेजे जाते हैं। यदि लेन-देन में कोई भी संचालन विफल हो जाता है, तो लेन-देन निरस्त हो जाता है और लेन-देन में किए गए सभी डेटा परिवर्तन कभी भी दिखाई नहीं देने के बिना छोड़ दिए जाते हैं। जब तक कोई लेन-देन शुरू नहीं हो जाता, तब तक लेन-देन का कोई भी संचालन लेनदेन के बाहर दिखाई नहीं देता है।

हालांकि कैसे और क्या के लिए कुछ सीमाएं हैं संचालन के हो सकती हैं।

मानगो डॉक की जाँच करें। https://docs.mongodb.com/master/core/transactions/

Answer 10

यदि आपका स्टोरेज मुख्य रैखिककरणीयता का समर्थन करता है और तुलना और सेट (जो MongoDB के लिए सही है) कर रहा है, तो आप क्लाइंट की ओर से परमाणु बहु-कुंजी अपडेट (क्रमबद्ध लेनदेन) को लागू कर सकते हैं। इस दृष्टिकोण का उपयोग Google के Percolator और CockroachDB में किया जाता है लेकिन कुछ भी आपको MongoDB के साथ इसका उपयोग करने से रोकता है।

मैंने इस तरह के लेन-देन का चरण-दर-चरण विज़ुअलाइज़ेशन बनाया है । मुझे उम्मीद है कि यह आपको उन्हें समझने में मदद करेगा।

यदि आप पढ़े हुए आइसोलेशन स्तर के साथ ठीक हैं, तो पीटर बेलीस द्वारा रैमपी लेनदेन पर एक नज़र डालना समझ में आता है । वे क्लाइंट साइड पर MongoDB के लिए भी कार्यान्वित किए जा सकते हैं।