डीबीएमएस के सिद्धांत। MVCC

हम में से कई लोग हमारे काम में DBMS का सामना कर चुके हैं। वर्तमान में, एक रूप में या किसी अन्य में डेटाबेस हमें हर जगह घेरते हैं, मोबाइल फोन से लेकर सोशल नेटवर्क तक, जिसमें हमारा पसंदीदा हब शामिल है। संबंधपरक DBMS, DBMS परिवार के सबसे आम सदस्य हैं, और उनमें से अधिकांश लेन-देन वाले हैं।
संस्थान में, हमें ACID की परिभाषा और इसके पीछे की संपत्तियों को याद करने के लिए मजबूर किया गया था, लेकिन किसी कारण से इस प्रतिमान के कार्यान्वयन के विवरण को नजरअंदाज कर दिया गया था। इस लेख में, मैं MVCC के बारे में बात करके इस अंतर को आंशिक रूप से भरने की कोशिश करूंगा, जिसका उपयोग DBMSs में किया जाता है जैसे Oracle, Postgres, MySQL इत्यादि। और बहुत सरल और सहज है।

तो, यह ACID परिभाषा के साथ शुरू होने लायक है:

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

इनमें से प्रत्येक आवश्यकता तर्कसंगत से अधिक होगी, खासकर अगर यह बैंकिंग और अन्य मुद्रा लेनदेन जैसे महत्वपूर्ण क्षेत्रों को प्रभावित करता है: आप इस बात से सहमत होंगे कि यदि आपके खाते से पैसा डेबिट किया जाता है तो यह बहुत अप्रिय होगा और वे दुकान के खाते में नहीं आते हैं ("परमाणु" का उल्लंघन) »), या एबीएस विफलता के परिणामस्वरूप, जानकारी खो जाएगी कि आपको अपने खाते में जमा किया गया है (" स्थायित्व "का उल्लंघन)।

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

• चयन करें - मान्य तालिका प्रविष्टियाँ पढ़ी जाती हैं। एक रिकॉर्ड वैध माना जाता है यदि यह एक लेनदेन द्वारा बनाया गया था जो वर्तमान लेनदेन की शुरुआत से पहले प्रतिबद्ध था;
• सम्मिलित करें - एक नया रिकॉर्ड बस तालिका के खाली स्थान में जोड़ा जाता है;
• हटाएं - तालिका में रिकॉर्ड को अमान्य के रूप में चिह्नित किया गया है, जबकि रिकॉर्ड खुद को हटाया नहीं गया है;
• अद्यतन हटाने और सम्मिलित करने का एक संयोजन है। सबसे पहले, रिकॉर्ड के पुराने संस्करण को अमान्य के रूप में चिह्नित किया जाता है, फिर अद्यतन डेटा के साथ एक नया रिकॉर्ड जोड़ा जाता है।

सामान्य तौर पर, इस दृष्टिकोण को वैध प्रविष्टियों के लिए ध्वज is_valid = 1 के साथ सिर्फ एक अतिरिक्त बिट के साथ लागू किया जा सकता है और अमान्य प्रविष्टियों के लिए 0। लेकिन मल्टीथ्रेडिंग के साथ एक समस्या है: इस दृष्टिकोण के साथ, केवल डेटा तक अनुक्रमिक पहुंच संभव होगी (लेखक पाठकों और अन्य लेखकों दोनों को अवरुद्ध करेगा)।

मान लें कि हमारे पास निम्न डेटा के साथ "तालिका ए" है:


और दो लेनदेन जो डेटा को इस प्रकार अद्यतन करने का प्रयास करते हैं:

• लेन-देन 1: अद्यतन ए सेट मान = मान || "लेनदेन 1" जहां आईडी = 1;
• लेनदेन 2: अपडेट ए सेट वैल्यू = मान || "लेनदेन 2" जहां आईडी = 1;

यदि हम समान डेटा पर उनके समानांतर संचालन की अनुमति देते हैं, तो निम्न परिणाम प्राप्त किया जा सकता है:

• लेनदेन 1 ने ID = 1 के साथ लाइन के लिए वैध मान पढ़ा: "हैलो";
• लेनदेन 2 ने ID = 1 के साथ पंक्ति के लिए मान्य मान पढ़ा: "हैलो";
• लेनदेन 1 ने मूल्य क्षेत्र के लिए नए मूल्य की गणना की: "हैलो लेनदेन 1";
• लेनदेन 2 ने मूल्य क्षेत्र के लिए नए मूल्य की गणना की: "हैलो लेनदेन 2";
• लेनदेन 1 ने तालिका डेटा को अपडेट किया;
• लेनदेन 2 ने तालिका डेटा को अपडेट किया।

इस तरह के एक परिणाम का परिणाम है:


और यहाँ उनके अनुक्रमिक निष्पादन का परिणाम है:


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

• अकेले वैधता ध्वज पर्याप्त नहीं है, एक अधिक जटिल तंत्र की आवश्यकता है;
• कुछ प्रकार के संचालन के लिए ताले की आवश्यकता होती है। यदि दो लेन-देन एक ही तालिका रिकॉर्ड को अपडेट करने का प्रयास करते हैं, तो यह स्पष्ट है कि वे केवल क्रमिक रूप से ऐसा कर सकते हैं।

आइए देखें कि यह Postgres में कैसे काम करता है:

1. सिस्टम में सभी लेनदेन अनुक्रमिक संख्याएं हैं (सशर्त रूप से, प्रत्येक तालिका के लिए लेनदेन संख्या अलग है और, वैक्यूम के भीतर, यह 4-बाइट पूर्णांक के अतिप्रवाह से बचने के लिए रीसेट है, जिसका उपयोग लेनदेन आईडी को स्टोर करने के लिए किया जाता है);
2. एक वैश्विक लेनदेन रजिस्ट्री है, जिसके बारे में जानकारी है कि कौन से लेनदेन प्रगति पर हैं और जिन्हें वापस ले लिया गया है;
3. तालिका में प्रत्येक रिकॉर्ड के लिए, तकनीकी क्षेत्र एक्समिन और एक्समैक्स हैं जो इस रिकॉर्ड को संशोधित करने वाले लेनदेन के बारे में जानकारी संग्रहीत करते हैं। एक्समिन लेनदेन का पहचानकर्ता है जिसने रिकॉर्ड को तालिका में जोड़ा। एक्समैक्स - लेनदेन का पहचानकर्ता जिसने तालिका से रिकॉर्ड को हटा दिया;
4. प्रत्येक तालिका प्रविष्टि के लिए, तकनीकी क्षेत्र Cmin और Cmax हैं, जिनका उपयोग कई आदेशों में लेनदेन के संचालन को सुनिश्चित करने के लिए किया जाता है।

मान लीजिए कि एक लेन-देन पहले तालिका में एक पंक्ति जोड़ता है, फिर उसे अपडेट करता है, फिर उसे हटाता है। Xmin और Xmax के लिए धन्यवाद, जब तक लेनदेन प्रतिबद्ध नहीं है, तब तक ये सभी ऑपरेशन बाहरी लेनदेन के लिए अदृश्य होंगे। लेकिन उस लेन-देन के बारे में क्या, जो अपने परिवर्तनों को देखना चाहिए, भले ही वे एक-दूसरे के विपरीत हों (पहले उन्होंने रिकॉर्ड जोड़ा, फिर हटा दिया)? इसके लिए, Cmin और Cmax बनाए गए, Xmin और Xmax के समान ही काम करते हुए, लेकिन एक विशिष्ट लेनदेन के ढांचे के भीतर।

मेटाडेटा के इस सेट के साथ, हम एसीआईडी ​​को एक वैधता ध्वज के साथ लागू करने के बहुत करीब हैं। अब MVCC के संदर्भ में उपरोक्त कार्यों पर विचार करें:

• चयन करें - मान्य तालिका प्रविष्टियाँ पढ़ी जाती हैं। प्रत्येक प्रविष्टियों के लिए, हमारे पास Xmin, Xmax, Cmin, Cmax है। यदि Xmin वर्तमान लेनदेन आईडी से अधिक है या चल रहे या रद्द किए गए लेनदेन की सूची में है, तो रिकॉर्ड मान्य नहीं है। यदि Xmax सेट किया गया है और वर्तमान लेनदेन आईडी से कम है और इस आईडी के साथ लेनदेन कार्य करने या रद्द किए गए लेनदेन की सूची में नहीं है, तो रिकॉर्ड मान्य नहीं है। यदि Xmin वर्तमान लेनदेन की आईडी के बराबर है, तो रिकॉर्ड की वैधता की जांच करने के लिए, Cmin और Cmax को देखें (Cmax को सेट किया जाना चाहिए ताकि रिकॉर्ड मान्य न हो)। यदि Xmax वर्तमान लेनदेन की आईडी के बराबर है, तो सब कुछ बिल्कुल विपरीत है। यदि उपरोक्त चेक काम नहीं करते हैं, तो प्रवेश वैध है। इस विषय पर लेखक / लेखक के साथ src / backend / utils / time / tqual.c से एक बहुत अच्छा कोड है:
  
  
• सम्मिलित करें - एक नया रिकॉर्ड बस तालिका के खाली स्थान में जोड़ा जाता है, इसे वर्तमान लेनदेन की आईडी में एक्समिन के साथ चिपका दिया जाता है और लेनदेन के भीतर मौजूदा संचालन की आईडी में सीमिन;
• हटाएं - तालिका में रिकॉर्ड को अमान्य के रूप में चिह्नित किया गया है, जबकि रिकॉर्ड स्वयं हटाया नहीं गया है। यह निम्नानुसार किया जाता है: Xmax को वर्तमान लेनदेन की आईडी में रखा गया है, Cmax वर्तमान ऑपरेशन की आईडी में है;
• अद्यतन हटाने और सम्मिलित करने का एक संयोजन है। सबसे पहले, रिकॉर्ड के पुराने संस्करण को अमान्य के रूप में चिह्नित किया जाता है, फिर अद्यतन डेटा के साथ एक नया रिकॉर्ड जोड़ा जाता है;
• श्रमिकों की सूची से लेनदेन पहचानकर्ता को हटाकर प्रतिबद्ध लेनदेन किया जाता है;
• रोलबैक लेनदेन को रोलबैक लेनदेन के रूप में लेनदेन पहचानकर्ता को चिह्नित करके किया जाता है।

लेन-देन के साथ काम करने का यह मॉडल सरल है, क्योंकि इसमें लॉकिंग तंत्र शामिल नहीं है, साथ ही वितरित लेनदेन के मामले भी हैं। फिर भी, यह दृष्टिकोण कई आधुनिक डीबीएमएस के लिए आम है और इसकी समझ से डीबीएमएस इंजन के अंदर क्या हो रहा है, इसे बेहतर ढंग से समझने में मदद मिलेगी।

Postgres के लिए उदाहरणों का अधिक विस्तृत विश्लेषण यहां पाया जा सकता है।