💯 👊🏿 🚏 MVCC लेन-देन अलगाव सुनिश्चित करने का एक तरीका है 🔥 🦓 🤸🏻

हाय, हैब्र। मेरा नाम व्लादिस्लाव रोडिन है। वर्तमान में, मैं ओटीयूएस में हाई लोड आर्किटेक्ट कोर्स का प्रमुख हूं, और मैं सॉफ्टवेयर आर्किटेक्चर पर पाठ्यक्रम भी पढ़ाता हूं।

विशेष रूप से "उच्च भार के वास्तुकार" पाठ्यक्रम के लिए एक नए सेट की शुरुआत के लिए मैंने एक छोटी सी सामग्री लिखी, जिसे मैं ख़ुशी से आपके साथ साझा करता हूं।

परिचय

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

Versionionists

जैसा कि मैंने कहा, दृष्टिकोणों में से एक संस्करण आधारित है। इसे आशावादी दृष्टिकोण या एमवीसीसी (मल्टीविज़न कंसीवेशन कंट्रोल) भी कहा जाता है । वास्तव में, सक्रिय लेनदेन के लिए संस्करण भंडारण होता है।

संस्करणों को कहाँ संग्रहीत किया जाता है?

तंत्र का कार्यान्वयन डेटाबेस पर निर्भर करता है। मैं उनमें से कुछ का उदाहरण दूंगा।

PostgreSQL

प्रत्येक लेनदेन में कुछ आईडी-शनिक की विशेषता होती है। ईद-शिकोनी लेनदेन नीरस रूप से बढ़ता है। किसी भी पंक्ति में 2 विशेषताएँ होती हैं जो एक तंत्र प्रदान करने के लिए मेटा-सूचना का प्रतिनिधित्व करती हैं: अपडेट किया गया_by_id - लेन-देन की आईडी जो इस रिकॉर्ड को अंतिम रूप से अपडेट करती है और इस रिकॉर्ड को हटाने वाले लेनदेन की आईडी हटा दी गई है। जब कोई नया लेन-देन आता है, तो डेटाबेस इस बात का निर्धारण करता है कि वर्तमान में किए जा रहे लेन-देन की id-nicks, इन लेनदेन द्वारा किए गए परिवर्तनों को आने वाले लेनदेन में नजरअंदाज कर दिया जाएगा। यह पता चलता है कि आने वाला लेनदेन डेटा के अपने संस्करण के साथ काम करता है। डेटा के पुराने संस्करणों को वर्तमान लोगों के समान ही संग्रहीत किया जाता है। यदि अपडेट आता है, तो एक और लाइन जोड़ी जाती है और यह रिकॉर्ड सक्रिय हो जाता है। यह भी स्पष्ट है कि इस योजना के सही संचालन के लिए, "कचरा संग्रहकर्ता" की आवश्यकता है:यदि कुछ रिकॉर्ड ने delete_by_id = 100 को हटा दिया है, और वर्तमान लेनदेन के बीच न्यूनतम आईडी-शनिक 150 है, तो इस रिकॉर्ड को हटा दिया जाना चाहिए।

MySQL (InnoDB इंजन)

केवल वर्तमान संस्करण MySQL डेटाबेस में संग्रहीत है। जब अपडेट आता है, तो टेबल फ़ाइल के अंदर का डेटा सही हो जाता है। डेटा को समायोजित करने के बाद, पिछला संस्करण रोलबैक लॉग में है। MySQL में कई रोलबैक लॉग हैं (वे सम्मिलित करने के लिए अलग हैं और update'ov)। यदि लेन-देन को लाइन के पिछले संस्करण की आवश्यकता होती है, तो सिस्टम पूर्ववत लॉग में जाता है और आवश्यक संस्करण को पुनर्स्थापित करता है। संस्करण भी लेनदेन आईडी द्वारा निर्धारित किया जाता है।

आकाशवाणी

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

MS SQL

MS SQL, दोनों संस्करण और ब्लॉकर मोड को शामिल करने की अनुमति देता है। डेटाबेस सेटिंग्स में संस्करण मोड को सक्षम करने के लिए, आपको स्नैपशॉट को सक्षम करना होगा। MS SQL में एक सिस्टम टेबल (tempdb) है, जिसे अस्थायी टेबल को स्टोर करने के लिए डिज़ाइन किया गया है। यह अस्थायी संस्करण है जिसका उपयोग पुराने संस्करणों को संग्रहीत करने के लिए किया जाता है, जबकि तालिका में वर्तमान संस्करण शामिल हैं। सिस्टम प्रक्रिया मॉनिटर करती है कि टेम्पीडब में ऐसे संस्करण हैं जिन्हें कोई भी संदर्भित नहीं करता है, उन्हें हटाया जा सकता है। यदि लेनदेन लंबे समय से चल रहा है, तो इसके लिए संस्करण सहेजे जाएंगे। Tempdb बढ़ता है, अपने अधिकतम आकार तक पहुँचता है, MS SQL थोड़ा डिस्क स्थान आवंटित करता है। यदि यह समाप्त हो जाता है, तो स्नैपशॉट अलगाव के साथ लेनदेन नहीं किया जा सकता है। यदि इस मोड का उपयोग किया जाता है, तो लंबे लेनदेन की निगरानी करना आवश्यक है,क्योंकि समय में इस तरह के लेन-देन का रोलबैक जितना काम करता है, उतना ही खर्च हो सकता है, और शायद थोड़ा अधिक।

संघर्ष

इस दृष्टिकोण को आशावादी कहा जाता है, क्योंकि हम आशा करते हैं कि समानांतर डेटा-परिवर्तन लेनदेन निष्पादित होने पर कोई संघर्ष नहीं होगा। संघर्ष के मामले में क्या होता है? मान लीजिए कि लेनदेन T1 10,000 रिकॉर्ड बदलता है, और लेनदेन T2 समानांतर में 1 रिकॉर्ड बदलता है। यदि ऐसा हुआ है कि यह 1 रिकॉर्ड उन 10,000 में शामिल है, तो लेनदेन में से एक को वापस ले लिया जाएगा: यदि T1 को पहले निष्पादित किया जाता है, तो T2 वापस ले लिया जाएगा, अन्यथा यह इसके विपरीत होगा।

रोलबैक तंत्र

संस्करण संस्करणों में लेन-देन रोलबैक का तंत्र कार्यान्वयन पर निर्भर करता है। उदाहरण के लिए, PostgreSQL में, एक लेनदेन को खाली स्थान के रूप में चिह्नित किया जाता है और वैक्यूम डिस्क स्थान को खाली कर देता है। ऐसा तंत्र काफी तेज है। ओरेकल में, रोलबैक के लिए, डेटा पूर्ववत लॉग से पुनर्स्थापित किया जाता है। इस मामले में, ऑपरेटिंग समय बढ़ जाता है, हालांकि, यह अभी भी लॉकर्स की तुलना में बहुत तेज है। MySQL Oracle की तरह ही काम करता है।

निष्कर्ष

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

यहाँ पाठ्यक्रम के बारे में अधिक जानें।

MVCC लेन-देन अलगाव सुनिश्चित करने का एक तरीका है