नमस्कार, हेब्र! इस लेख के साथ, मैं PostgreSQL की आंतरिक संरचना के बारे में लूप (या एक लूप ऑफ सीरीज़? सामान्य रूप से, एक भव्य विचार) की एक श्रृंखला शुरू करता हूं।

सामग्री प्रशासन प्रशिक्षण पाठ्यक्रमों पर आधारित होगी जो हम पावेल प्लुज़नोव के साथ करते हैं। हर कोई वीडियो देखना पसंद नहीं करता (मैं निश्चित रूप से इसे पसंद नहीं करता), लेकिन स्लाइड पढ़ने के लिए, यहां तक कि टिप्पणियों के साथ, पूरी तरह से "गलत" है।

बेशक, लेख एक से एक पाठ्यक्रमों की सामग्री को नहीं दोहराएंगे। मैं केवल इस बारे में बात करूंगा कि सब कुछ कैसे काम करता है, प्रशासन को छोड़ देना, लेकिन मैं इसे और अधिक और विस्तार से करने की कोशिश करूंगा। और मेरा मानना है कि इस तरह का ज्ञान एप्लिकेशन डेवलपर के लिए उपयोगी है जो प्रशासक से कम नहीं है।

मैं उन लोगों पर ध्यान केंद्रित करूंगा जिनके पास पहले से ही PostgreSQL का उपयोग करने का कुछ अनुभव है और कम से कम सामान्य शब्दों में कल्पना करें कि क्या हो रहा है। शुरुआती लोगों के लिए, पाठ थोड़ा भारी होगा। उदाहरण के लिए, मैं PostgreSQL को स्थापित करने और psql चलाने के तरीके के बारे में एक शब्द नहीं कहूंगा।

जिन चीजों पर चर्चा की जाएगी, वे संस्करण से संस्करण में बहुत अधिक नहीं बदलते हैं, लेकिन मैं वर्तमान, 11 वें "वेनिला" पोस्टग्रेक्यूएल का उपयोग करूंगा।

पहला चक्र अलगाव और बहुविवाह से संबंधित मुद्दों के लिए समर्पित है, और इसकी योजना इस प्रकार है:

अलगाव, मानक और PostgreSQL (इस लेख) द्वारा समझा गया;
परतें, फाइलें, पृष्ठ - भौतिक स्तर पर क्या हो रहा है;
पंक्ति संस्करण, आभासी और नेस्टेड लेनदेन ;
डेटा स्नैपशॉट और पंक्ति संस्करणों की दृश्यता, घटना क्षितिज ;
इन-पेज सफाई और HOT-अपडेट ;
सामान्य सफाई (वैक्यूम);
स्वचालित सफाई (ऑटोवैक्यूम);
लेन-देन काउंटर अतिप्रवाह और फ्रीज ।

अच्छा, चलिए।

इन्सुलेशन क्या है और यह महत्वपूर्ण क्यों है?

संभवतः हर कोई कम से कम लेनदेन के अस्तित्व के बारे में जानता है, परिचित एसीआईडी से मिला और अलगाव के स्तर के बारे में सुना। लेकिन एक को अभी भी राय को पूरा करना है कि यह एक सिद्धांत है जो व्यवहार में आवश्यक नहीं है। इसलिए, मैं यह समझाने की कोशिश में कुछ समय बिताऊंगा कि यह वास्तव में महत्वपूर्ण क्यों है।

यदि एप्लिकेशन को डेटाबेस से गलत डेटा प्राप्त होता है, या यदि एप्लिकेशन डेटाबेस को गलत डेटा लिखता है, तो यह संभव नहीं है कि आप खुश होंगे।

लेकिन "सही" डेटा क्या है? यह ज्ञात है कि डेटाबेस स्तर पर, आप अखंडता बाधाएँ (जैसे कि NULL या UNIQUE) नहीं बना सकते हैं। यदि डेटा हमेशा अखंडता बाधाओं को संतुष्ट करता है (और ऐसा इसलिए है क्योंकि DBMS इसकी गारंटी देता है), तो वे समग्र हैं।

क्या सही और अभिन्न हैं - एक ही बात? वास्तव में नहीं। सभी प्रतिबंध डेटाबेस स्तर पर तैयार नहीं किए जा सकते हैं। प्रतिबंधों का हिस्सा बहुत जटिल है, उदाहरण के लिए, यह एक ही बार में कई तालिकाओं को कवर करता है। और भले ही प्रतिबंध, सिद्धांत रूप में, डेटाबेस में परिभाषित किया जा सकता है, लेकिन किसी कारण से वे ऐसा नहीं करते थे, इसका मतलब यह नहीं है कि इसका उल्लंघन किया जा सकता है।

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

अब से, हम शुद्धता को स्थिरता शब्द कहेंगे।

हालांकि, मान लें कि आवेदन केवल बयानों के सही अनुक्रम को निष्पादित करता है। यदि आवेदन सही है, तो DBMS की क्या भूमिका है?

सबसे पहले, यह पता चलता है कि बयानों का एक सही क्रम अस्थायी रूप से डेटा स्थिरता को बाधित कर सकता है, और यह - अजीब तरह से पर्याप्त - सामान्य है। एक हैक किए गए लेकिन समझने योग्य उदाहरण एक खाते से दूसरे खाते में धनराशि स्थानांतरित करना है। संगतता नियम इस तरह से लग सकता है: एक हस्तांतरण कभी भी खातों में धन की कुल राशि को नहीं बदलता है (ऐसा नियम SQL में अखंडता बाधा के रूप में लिखना मुश्किल है, इसलिए यह एप्लिकेशन स्तर पर मौजूद है और DBMS के लिए अदृश्य है)। एक हस्तांतरण में दो ऑपरेशन होते हैं: पहला एक खाते में धन को कम करता है, दूसरा - दूसरे में बढ़ता है। पहला ऑपरेशन डेटा की स्थिरता का उल्लंघन करता है, दूसरा - पुनर्स्थापित करता है।

एक अच्छा अभ्यास अखंडता बाधाओं के स्तर पर ऊपर वर्णित नियम को लागू करना है। क्या आप कमजोर हैं? ©

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

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

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

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

जब सही लेन-देन सही ढंग से एक साथ काम नहीं करते हैं तो स्थिति को एक साथ निष्पादन विसंगतियां कहा जाता है।

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

यदि अन्य, अधिक जटिल विसंगतियाँ हैं, जिन्हें हम थोड़ी देर बाद समझेंगे।

बेशक, एक साथ निष्पादन से इनकार करना असंभव है: अन्यथा, किस तरह के प्रदर्शन पर चर्चा की जा सकती है? लेकिन आप गलत डेटा के साथ काम नहीं कर सकते।

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

तो, हम परिभाषा पर आते हैं:

लेन-देन एक अनुप्रयोग द्वारा किए गए संचालन का सेट है जो डेटाबेस को एक सही स्थिति से दूसरे सही राज्य (संगतता) में स्थानांतरित करता है, बशर्ते कि लेन-देन पूर्ण (परमाणुता) और अन्य लेनदेन (अलगाव) के हस्तक्षेप के बिना हो।

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

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

SQL अलगाव स्तर और विसंगतियाँ

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

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

अद्यतन खो दिया है

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

उदाहरण के लिए, दो लेनदेन एक ही खाते में राशि को 100 are तक बढ़ाने जा रहे हैं। पहला लेन-देन वर्तमान मूल्य (1000 the) पढ़ता है, फिर दूसरा लेनदेन उसी मूल्य को पढ़ता है। पहला लेनदेन राशि बढ़ाता है (यह 1100 amount निकला) और यह मान लिखता है। दूसरा लेन-देन वही करता है - वही 1,100 same प्राप्त करता है और उन्हें लिखता है। नतीजतन, ग्राहक 100 client खो दिया।

किसी भी अलगाव स्तर पर मानक द्वारा खोए गए अपडेट की अनुमति नहीं है।

डर्टी रीडिंग और अनकम्ड रीड

गंदे पढ़ने के साथ हम पहले ही ऊपर मिल चुके हैं। यह विसंगति तब होती है जब कोई लेनदेन किसी अन्य लेनदेन द्वारा किए गए लंबित परिवर्तनों को पढ़ता है।

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

गंदे पढ़ने की अनुमति मानक द्वारा पढ़े स्तर पर है।

नॉन-रिपीट रीड एंड रीड कमिटेड

गैर-दोहराव पढ़ने वाला विसंगति तब होता है जब एक लेन-देन एक ही पंक्ति को दो बार पढ़ता है, और अंतराल के बीच में, दूसरा लेन-देन इस लाइन को बदलता है (या हटाता है) और परिवर्तन को प्रारंभ करता है। तब पहले लेन-देन के अलग-अलग परिणाम मिलेंगे।

उदाहरण के लिए, संगतता नियम ग्राहक खातों में नकारात्मक मात्रा को प्रतिबंधित करते हैं । पहला लेन-देन खाते में राशि to 100 से कम करने जा रहा है। वह वर्तमान मूल्य की जांच करती है, 1000, प्राप्त करती है और निर्णय लेती है कि कमी संभव है। इस समय, दूसरा लेनदेन खाते में राशि को शून्य में कम कर देता है और परिवर्तनों को रिकॉर्ड करता है। यदि अब पहले लेनदेन ने राशि की फिर से जाँच की, तो उसे 0 re प्राप्त होगा (लेकिन उसने पहले ही मूल्य को कम करने का फैसला किया था, और खाता "माइनस में जाता है")।

गैर-दोहराए गए पढ़ने की अनुमति मानक द्वारा पढ़े गए अनधिकृत और पढ़े गए स्तरों पर है। लेकिन गंदा पढना कमिटेड अनुमति नहीं देता है।

प्रेत पढ़ें और बार-बार पढ़ें

फैंटम रीडिंग तब होती है जब कोई लेन-देन एक ही स्थिति के तहत दो बार लाइनों का एक सेट पढ़ता है, और रीड्स के बीच के अंतराल में, दूसरा लेन-देन उन लाइनों को जोड़ता है जो इस स्थिति को संतुष्ट करते हैं (और परिवर्तनों को मानते हैं)। फिर पहले लेन-देन में अलग-अलग पंक्तियों के सेट प्राप्त होंगे।

उदाहरण के लिए, मान लीजिए कि एक संगतता नियम एक ग्राहक को 3 से अधिक खाते रखने से रोकता है । पहला लेनदेन एक नया खाता खोलने जा रहा है, उनकी वर्तमान संख्या (कहते हैं, 2) की जाँच करता है और निर्णय लेता है कि उद्घाटन संभव है। इस समय, दूसरा लेनदेन क्लाइंट के लिए एक नया खाता भी खोलता है और परिवर्तनों को रिकॉर्ड करता है। यदि अब पहला लेन-देन मात्रा को दोगुना करता है, तो उसे 3 प्राप्त होंगे (लेकिन यह पहले से ही एक और खाता खोल रहा है और ग्राहक के पास उनमें से 4 हैं)।

प्रेत पढ़ने की अनुमति दी जाती है मानक पर पढ़ें अनकम्युनिटेड, रीड कमिटेड और रिपीटेबल रीड स्तरों पर। लेकिन रिपीटेबल रीड स्तर पर, गैर-दोहराए गए पढ़ने की अनुमति नहीं है।

विसंगतियों और सीरियल के अभाव

मानक एक और स्तर को परिभाषित करता है - सीरियल करने योग्य - जिस पर कोई भी विसंगतियों की अनुमति नहीं है। और यह सब एक खोया अद्यतन पर प्रतिबंध और एक गंदा, गैर-दोहराव और प्रेत पढ़ने के समान नहीं है।

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

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

सारांश प्लेट

अब आप सभी के लिए एक प्रसिद्ध तालिका ला सकते हैं। लेकिन यहां, स्पष्टता के लिए, अंतिम कॉलम इसमें जोड़ा जाता है, जो मानक में नहीं है।

	खोए हुए बदलाव	गंदा पढ़ना	बार-बार पढ़ना	प्रेत पढ़ना	अन्य विसंगतियाँ
बिना पढ़े लिखे	-	हां	हां	हां	हां
प्रतिबद्ध पढ़ो	-	-	हां	हां	हां
बार-बार पढ़ने योग्य	-	-	-	हां	हां
serializable	-	-	-	-	-

आखिर ये विसंगतियाँ क्यों?

सूचीबद्ध मानक में कई संभावित विसंगतियों में से कुछ ही क्यों हैं, और ये क्यों हैं?

जाहिर है, किसी को भी यह निश्चित रूप से पता नहीं लगता है। लेकिन यहां अभ्यास निश्चित रूप से सिद्धांत से आगे निकल गया, इसलिए यह संभव है कि तब हमने अन्य विसंगतियों के बारे में नहीं सोचा था (एसक्यूएल मानक के बारे में भाषण: 92)।

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

यह मुझे लगता है कि मानक के अलगाव के स्तर के बीच अंतर को आवश्यक तालों की संख्या द्वारा सटीक रूप से समझाया गया है।

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

यदि लेन-देन पढ़ने से और बदलने से परिवर्तनशील लाइनों को अवरुद्ध करता है, तो हमें रीड कमिटेड स्तर मिलता है: आप बिना पढ़े डेटा नहीं पढ़ सकते हैं, लेकिन जब आप लाइन को फिर से एक्सेस करते हैं, तो आप एक अलग मान प्राप्त कर सकते हैं (गैर-दोहराई गई रीडिंग)।

यदि कोई लेन-देन पढ़ने और बदलने दोनों से पठनीय और परिवर्तनशील रेखाओं को अवरुद्ध करता है, तो हमें बार-बार पढ़ने योग्य स्तर मिलता है: बार-बार पढ़ने पर समान मूल्य का उत्पादन होगा।

लेकिन Serializable के साथ एक समस्या है: एक पंक्ति को लॉक करना संभव नहीं है जो अभी तक मौजूद नहीं है। इस वजह से, प्रेत पढ़ने की संभावना बनी रहती है: एक अन्य लेनदेन एक पंक्ति जोड़ सकता है (लेकिन हटा नहीं सकता) जो पहले से निष्पादित क्वेरी की शर्तों के तहत आती है, और यह पंक्ति फिर से प्राप्त की जाएगी।

इसलिए, सीरियल के स्तर को लागू करने के लिए, साधारण ताले पर्याप्त नहीं हैं - आपको पंक्तियों को ब्लॉक करने की आवश्यकता नहीं है, लेकिन स्थितियां (विधेय)। ऐसे ताले को विधेय कहा जाता था। उन्हें 1976 में वापस प्रस्तावित किया गया था, लेकिन उनकी व्यावहारिक प्रयोज्यता साधारण परिस्थितियों के बजाय सीमित है, जिसके लिए यह स्पष्ट है कि दो अलग-अलग विधेयकों को कैसे संयोजित किया जाए। जहां तक मुझे पता है, यह किसी भी प्रणाली में ऐसे ताले के कार्यान्वयन के लिए नहीं आया है।

PostgreSQL अलगाव स्तर

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

इस तरह के अलगाव स्वचालित रूप से गंदे पढ़ने की अनुमति नहीं देते हैं। औपचारिक रूप से, PostgreSQL में, आप रीड अनक्वायर्ड स्तर निर्दिष्ट कर सकते हैं, लेकिन यह रीड कमिटेड की तरह ही काम करेगा। इसलिए, हम आगे पढ़े अनकम्फर्ड स्तर के बारे में बात नहीं करेंगे।

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

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

	खोए हुए बदलाव	गंदा पढ़ना	बार-बार पढ़ना	प्रेत पढ़ना	अन्य विसंगतियाँ
बिना पढ़े लिखे	-	-	हां	हां	हां
प्रतिबद्ध पढ़ो	-	-	हां	हां	हां
बार-बार पढ़ने योग्य	-	-	-	-	हां
serializable	-	-	-	-	-

मल्टी-वर्जनिंग को "हुड के तहत" कैसे लागू किया जाता है, हम निम्नलिखित लेखों में बात करेंगे, और अब हम उपयोगकर्ता की आँखों के माध्यम से तीन स्तरों में से प्रत्येक पर विस्तार से देखेंगे (जैसा कि आप जानते हैं, सबसे दिलचस्प "अन्य विसंगतियों" के पीछे छिपा है)। ऐसा करने के लिए, खातों की एक तालिका बनाएं। एलिस और बॉब के पास प्रत्येक $ 1,000 हैं, लेकिन बॉब के दो खाते खुले हैं:

=> CREATE TABLE accounts( id integer PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY, number text UNIQUE, client text, amount numeric ); => INSERT INTO accounts VALUES (1, '1001', 'alice', 1000.00), (2, '2001', 'bob', 100.00), (3, '2002', 'bob', 900.00);

प्रतिबद्ध पढ़ो

गंदे पढ़ने का अभाव

यह सत्यापित करना आसान है कि गंदा डेटा नहीं पढ़ा जा सकता है। लेन-देन शुरू करते हैं। डिफ़ॉल्ट रूप से, यह पढ़ने के लिए पृथक अलगाव स्तर का उपयोग करेगा:

 => BEGIN; => SHOW transaction_isolation;

  transaction_isolation ----------------------- read committed (1 row)

अधिक सटीक रूप से, डिफ़ॉल्ट स्तर पैरामीटर द्वारा निर्धारित किया जाता है, यदि आवश्यक हो तो इसे बदला जा सकता है:

 => SHOW default_transaction_isolation;

  default_transaction_isolation ------------------------------- read committed (1 row)

इसलिए, एक खुले लेनदेन में, हम खाते से धन निकालते हैं, लेकिन परिवर्तनों को रिकॉर्ड नहीं करते हैं। लेन-देन अपने स्वयं के परिवर्तन देखता है:

 => UPDATE accounts SET amount = amount - 200 WHERE id = 1; => SELECT * FROM accounts WHERE client = 'alice';

  id | number | client | amount ----+--------+--------+-------- 1 | 1001 | alice | 800.00 (1 row)

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

उपरोक्त आदेशों को दोहराने के लिए (जो उपयोगी है), आपको दो टर्मिनलों को खोलने और प्रत्येक में psql चलाने की आवश्यकता है। पहले में, आप एक लेन-देन की आज्ञाओं को दर्ज कर सकते हैं, और दूसरे में - दूसरे की आज्ञाओं को।

 | => BEGIN; | => SELECT * FROM accounts WHERE client = 'alice';

 | id | number | client | amount | ----+--------+--------+--------- | 1 | 1001 | alice | 1000.00 | (1 row)

जैसा कि अपेक्षित था, एक और लेन-देन में बिना परिवर्तन के परिवर्तन नहीं देखे जाते - गंदे पढ़ने की अनुमति नहीं है

नॉन-रिपीट रीडिंग

अब पहले लेन-देन में परिवर्तन करें, और दूसरा उसी अनुरोध को फिर से निष्पादित करें।

 => COMMIT;

 | => SELECT * FROM accounts WHERE client = 'alice';

 | id | number | client | amount | ----+--------+--------+-------- | 1 | 1001 | alice | 800.00 | (1 row)

 | => COMMIT;

अनुरोध पहले से ही नया डेटा प्राप्त कर रहा है - यह गैर-दोहराए जाने वाले पढ़ने की विसंगति है, जिसे पढ़ने के लिए प्रतिबद्ध स्तर पर अनुमति दी जाती है।

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

  IF (SELECT amount FROM accounts WHERE id = 1) >= 1000 THEN UPDATE accounts SET amount = amount - 1000 WHERE id = 1; END IF;

उस समय के दौरान जब सत्यापन और अद्यतन के बीच विस्तार हो जाता है, अन्य लेनदेन खाते की स्थिति को इच्छानुसार बदल सकते हैं, ताकि इस तरह के "चेक" से कुछ भी न बचाया जा सके। यह कल्पना करना सुविधाजनक है कि एक लेन-देन के संचालकों के बीच अन्य लेनदेन के किसी भी अन्य ऑपरेटर "वेज" कर सकते हैं, उदाहरण के लिए, जैसे:

  IF (SELECT amount FROM accounts WHERE id = 1) >= 1000 THEN ----- | UPDATE accounts SET amount = amount - 200 WHERE id = 1; | COMMIT; ----- UPDATE accounts SET amount = amount - 1000 WHERE id = 1; END IF;

यदि, ऑपरेटरों को पुनर्व्यवस्थित करते हुए, आप सब कुछ बर्बाद कर सकते हैं, तो कोड गलत तरीके से लिखा गया है। और अपने आप को धोखा न दें कि परिस्थितियों का ऐसा संयोजन नहीं होगा - ऐसा होगा।

कोड को सही तरीके से कैसे लिखें? एक नियम के रूप में, अवसर निम्नलिखित के लिए उबालते हैं:

कोड न लिखें।
यह कोई मजाक नहीं है। उदाहरण के लिए, इस मामले में, चेक आसानी से एक अखंडता बाधा में बदल जाता है:
ALTER TABLE accounts ADD CHECK amount >= 0;
अब, कोई जांच की आवश्यकता नहीं है: यह केवल कार्रवाई करने के लिए पर्याप्त है और यदि आवश्यक हो, तो अखंडता का उल्लंघन करने के प्रयास की स्थिति में उत्पन्न होने वाले अपवाद को संभाल लें।
एकल SQL कथन का उपयोग करें।
इस तथ्य के कारण संगतता समस्याएं उत्पन्न होती हैं कि ऑपरेटरों के बीच अंतराल में एक और लेनदेन समाप्त हो सकता है और दृश्यमान डेटा बदल जाएगा। और अगर केवल एक ऑपरेटर है, तो कोई अंतराल नहीं हैं।
PostgreSQL में एक एकल SQL स्टेटमेंट के साथ जटिल समस्याओं को हल करने के लिए पर्याप्त उपकरण हैं। हम सामान्य टेबल एक्सप्रेशन (CTE) पर ध्यान देते हैं, जिसमें अन्य बातों के अलावा, आप INSERT / UPDATE / DELETE स्टेटमेंट्स का उपयोग कर सकते हैं, साथ ही INSERT ON CONFLICT स्टेटमेंट का भी उपयोग कर सकते हैं, जो "इंसर्ट" लागू करता है, और यदि पहले से ही एक पंक्ति है, तो एक स्टेटमेंट में "लॉजिक अपडेट करें"।
उपयोगकर्ता ताले।
अंतिम उपाय मैन्युअल रूप से सभी आवश्यक पंक्तियों (SELECT FOR UPDATE), या संपूर्ण तालिका (LOCK TABLE) पर एक विशेष लॉक सेट करना है। यह हमेशा काम करता है, लेकिन बहु-संस्करण के लाभों को नकारता है: एक साथ निष्पादित करने के बजाय, परिचालन के हिस्से को क्रमिक रूप से निष्पादित किया जाएगा।

असंगत पढ़ना

अलगाव के अगले स्तर पर शुरू करने से पहले, किसी को यह स्वीकार करना होगा कि सब कुछ इतना सरल नहीं है। PostgreSQL का कार्यान्वयन ऐसा है कि यह अन्य, कम प्रसिद्ध विसंगतियों के लिए अनुमति देता है जो मानक द्वारा विनियमित नहीं हैं।

मान लीजिए कि पहले लेन-देन ने एक बॉब खाते से दूसरे खाते में धनराशि स्थानांतरित करना शुरू किया:

 => BEGIN; => UPDATE accounts SET amount = amount - 100 WHERE id = 2;

इस समय, एक अन्य लेन-देन बॉब के संतुलन की गणना करता है, गणना के साथ सभी बॉब के खातों पर एक चक्र में प्रदर्शन किया जाता है। वास्तव में, लेनदेन पहले खाते से शुरू होता है (और, जाहिर है, पिछली स्थिति को देखता है):

 | => BEGIN; | => SELECT amount FROM accounts WHERE id = 2;

 | amount | -------- | 100.00 | (1 row)

इस बिंदु पर, पहला लेनदेन सफलतापूर्वक पूरा होता है:

 => UPDATE accounts SET amount = amount + 100 WHERE id = 3; => COMMIT;

और दूसरा दूसरे खाते की स्थिति पढ़ता है (और पहले से ही एक नया मूल्य देखता है):

 | => SELECT amount FROM accounts WHERE id = 3;

 | amount | --------- | 1000.00 | (1 row)

 | => COMMIT;

इस प्रकार, दूसरे लेनदेन में कुल 1100 received प्राप्त हुए, अर्थात गलत डेटा। यह असंगत पढ़ने की विसंगति है ।

Read Committed पर रहकर ऐसी विसंगति से कैसे बचें? बेशक, एक ऑपरेटर का उपयोग करें। उदाहरण के लिए, इस तरह:

  SELECT sum(amount) FROM accounts WHERE client = 'bob';

अब तक, मैंने तर्क दिया है कि डेटा दृश्यता केवल ऑपरेटरों के बीच बदल सकती है, लेकिन क्या यह इतना स्पष्ट है? और अगर अनुरोध को लंबे समय तक निष्पादित किया जाता है, तो क्या यह एक राज्य में डेटा का हिस्सा, और दूसरे भाग में देख सकता है?

इसे देखें। ऐसा करने का एक सुविधाजनक तरीका यह है कि आप pg_sleep फ़ंक्शन को कॉल करके ऑपरेटर में एक कृत्रिम विलंब सम्मिलित करें। इसका पैरामीटर सेकंड में देरी का समय निर्धारित करता है।

 => SELECT amount, pg_sleep(2) FROM accounts WHERE client = 'bob';

जब यह निर्माण प्रगति पर है, एक अन्य लेन-देन में, हम धनराशि वापस लेते हैं:

 | => BEGIN; | => UPDATE accounts SET amount = amount + 100 WHERE id = 2; | => UPDATE accounts SET amount = amount - 100 WHERE id = 3; | => COMMIT;

परिणाम से पता चलता है कि ऑपरेटर उस स्थिति में डेटा को देखता है जिसमें वह उस समय था जब यह शुरू हुआ था। यह निश्चित रूप से सही है।

  amount | pg_sleep ---------+---------- 0.00 | 1000.00 | (2 rows)

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

 => CREATE FUNCTION get_amount(id integer) RETURNS numeric AS $$ SELECT amount FROM accounts a WHERE a.id = get_amount.id; $$ VOLATILE LANGUAGE sql;

 => SELECT get_amount(id), pg_sleep(2) FROM accounts WHERE client = 'bob';

 | => BEGIN; | => UPDATE accounts SET amount = amount + 100 WHERE id = 2; | => UPDATE accounts SET amount = amount - 100 WHERE id = 3; | => COMMIT;

इस स्थिति में, हमें गलत डेटा मिलता है - 100 get खो जाते हैं:

  get_amount | pg_sleep ------------+---------- 100.00 | 800.00 | (2 rows)

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

खोए हुए परिवर्तनों के बदले में लगातार पढ़ना

एक ऑपरेटर के ढांचे के भीतर एक असंगत पढ़ना - कुछ हद तक अप्रत्याशित तरीके से - एक अद्यतन के दौरान प्राप्त किया जा सकता है।

आइए देखें कि जब आप दो लेन-देन के साथ एक ही पंक्ति को बदलने का प्रयास करते हैं तो क्या होता है। बॉब के अब दो खातों में 1000 ₽ हैं:

 => SELECT * FROM accounts WHERE client = 'bob';

  id | number | client | amount ----+--------+--------+-------- 2 | 2001 | bob | 200.00 3 | 2002 | bob | 800.00 (2 rows)

हम एक लेन-देन शुरू करते हैं जो बॉब के संतुलन को कम करता है:

 => BEGIN; => UPDATE accounts SET amount = amount - 100 WHERE id = 3;

एक ही समय में, एक और लेनदेन 1000 या उससे अधिक के बराबर कुल शेष के साथ सभी ग्राहक खातों पर ब्याज अर्जित करता है:

 | => UPDATE accounts SET amount = amount * 1.01 | WHERE client IN ( | SELECT client | FROM accounts | GROUP BY client | HAVING sum(amount) >= 1000 | );

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

निष्पादन का दूसरा चरण - चयनित पंक्तियों को एक के बाद एक अपडेट किया जाता है। यहां दूसरा लेन-देन "फ्रीज" करने के लिए मजबूर किया जाता है, क्योंकि लाइन आईडी = 3 पहले से ही पहले लेनदेन से लॉक है।

इस बीच, पहला लेनदेन परिवर्तन करता है:

 => COMMIT;

इसका परिणाम क्या होगा?

 => SELECT * FROM accounts WHERE client = 'bob';

  id | number | client | amount ----+--------+--------+---------- 2 | 2001 | bob | 202.0000 3 | 2002 | bob | 707.0000 (2 rows)

हां, एक तरफ, UPDATE कमांड को दूसरे ट्रांजेक्शन में बदलाव नहीं देखना चाहिए। लेकिन दूसरी ओर, इसे दूसरे लेनदेन में दर्ज परिवर्तनों को नहीं खोना चाहिए।

लॉक रिलीज़ होने के बाद, UPDATE उस पंक्ति को फिर से पढ़ता है जिसे वह अपडेट करना चाह रहा है (लेकिन केवल एक!)। परिणाम यह है कि बॉब ने 9 ₽ अर्जित किया, जो 900 acc की राशि के आधार पर है। लेकिन अगर बॉब के पास 900 ₽ थे, तो उसके खातों को नमूने में शामिल नहीं किया जाना चाहिए था।

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

चौकस पाठक ध्यान दें कि पढ़े हुए स्तर पर एप्लिकेशन की कुछ मदद से, आप एक खोया हुआ अपडेट प्राप्त कर सकते हैं। उदाहरण के लिए, इस तरह:
  x := (SELECT amount FROM accounts WHERE id = 1); UPDATE accounts SET amount = x + 100 WHERE id = 1; 
डेटाबेस को दोष देने के लिए नहीं है: यह दो एसक्यूएल स्टेटमेंट प्राप्त करता है और कुछ भी नहीं जानता है कि x + 100 का मूल्य किसी तरह खातों से संबंधित है। इस तरह से कोड न लिखें।

बार-बार पढ़ने योग्य

गैर-दोहराव और प्रेत रीडिंग का अभाव

आइसोलेशन स्तर का नाम ही इंगित करता है कि रीडिंग दोहराने योग्य है। हम इसे सत्यापित करेंगे, और साथ ही हम प्रेत रीडिंग की अनुपस्थिति के बारे में आश्वस्त होंगे। ऐसा करने के लिए, पहले लेनदेन में, बॉब के खातों को उनकी पिछली स्थिति में लौटाएं और चार्ली के लिए एक नया खाता बनाएं:

 => BEGIN; => UPDATE accounts SET amount = 200.00 WHERE id = 2; => UPDATE accounts SET amount = 800.00 WHERE id = 3; => INSERT INTO accounts VALUES (4, '3001', 'charlie', 100.00); => SELECT * FROM accounts ORDER BY id;

  id | number | client | amount ----+--------+---------+-------- 1 | 1001 | alice | 800.00 2 | 2001 | bob | 200.00 3 | 2002 | bob | 800.00 4 | 3001 | charlie | 100.00 (4 rows)

दूसरे सत्र में, हम बार-बार पढ़ने योग्य स्तर के साथ लेन-देन शुरू करते हैं, इसे BEGIN कमांड में दर्शाते हैं (पहला लेन-देन का स्तर महत्वपूर्ण नहीं है)।

 | => BEGIN ISOLATION LEVEL REPEATABLE READ; | => SELECT * FROM accounts ORDER BY id;

 | id | number | client | amount | ----+--------+--------+---------- | 1 | 1001 | alice | 800.00 | 2 | 2001 | bob | 202.0000 | 3 | 2002 | bob | 707.0000 | (3 rows)

अब पहला लेनदेन परिवर्तनों को करता है, और दूसरा उसी अनुरोध को फिर से निष्पादित करता है।

 => COMMIT;

 | => SELECT * FROM accounts ORDER BY id;

 | id | number | client | amount | ----+--------+--------+---------- | 1 | 1001 | alice | 800.00 | 2 | 2001 | bob | 202.0000 | 3 | 2002 | bob | 707.0000 | (3 rows)

 | => COMMIT;

दूसरा लेन-देन शुरू में ठीक उसी डेटा को देखता रहता है: न तो मौजूदा लाइनों में बदलाव होता है और न ही नई लाइनें दिखाई देती हैं।

इस स्तर पर, आपको दोनों ऑपरेटरों के बीच कुछ बदलने की चिंता नहीं करनी होगी।

खोए हुए परिवर्तनों के बदले में सीरियलाइज़ेशन त्रुटि

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

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

 => SELECT * FROM accounts WHERE client = 'bob';

  id | number | client | amount ----+--------+--------+-------- 2 | 2001 | bob | 200.00 3 | 2002 | bob | 800.00 (2 rows)

 => BEGIN; => UPDATE accounts SET amount = amount - 100.00 WHERE id = 3;

 | => BEGIN ISOLATION LEVEL REPEATABLE READ; | => UPDATE accounts SET amount = amount * 1.01 | WHERE client IN ( | SELECT client | FROM accounts | GROUP BY client | HAVING sum(amount) >= 1000 | );

 => COMMIT;

 | ERROR: could not serialize access due to concurrent update

 | => ROLLBACK;

डेटा संगत रहे:

 => SELECT * FROM accounts WHERE client = 'bob';

  id | number | client | amount ----+--------+--------+-------- 2 | 2001 | bob | 200.00 3 | 2002 | bob | 700.00 (2 rows)

किसी अन्य प्रतिस्पर्धी पंक्ति परिवर्तन के मामले में भी यही त्रुटि होगी, भले ही हमारे लिए ब्याज के कॉलम वास्तव में नहीं बदले हों।

व्यावहारिक निष्कर्ष : यदि लेन-देन लिखने के लिए एप्लिकेशन रिपीटेबल रीड आइसोलेशन स्तर का उपयोग करता है, तो यह उन लेनदेन को दोहराने के लिए तैयार होना चाहिए जो क्रमिक त्रुटि में समाप्त हो गए। केवल-पढ़ने के लिए लेन-देन के लिए, ऐसा परिणाम संभव नहीं है।

असंगत प्रविष्टि

तो, PostgreSQL में, रिपीटेबल रीड के अलगाव स्तर पर, मानक में वर्णित सभी विसंगतियों को रोका जाता है। लेकिन बिल्कुल नहीं। यह पता चला है कि वास्तव में दो विसंगतियाँ हैं जो संभव हैं। (यह न केवल PostgreSQL के लिए, बल्कि अन्य स्नैपशॉट-आधारित अलगाव कार्यान्वयनों के लिए भी सही है।)

इन विसंगतियों में से पहला एक असंगत रिकॉर्ड है ।

इस संगतता नियम को लागू होने दें: यदि इस ग्राहक के सभी खातों पर कुल राशि गैर-नकारात्मक रहती है, तो ग्राहक के खातों पर नकारात्मक राशि की अनुमति दी जाती है ।

पहला लेनदेन बॉब के खातों में राशि प्राप्त करता है: 900 amount।

 => BEGIN ISOLATION LEVEL REPEATABLE READ; => SELECT sum(amount) FROM accounts WHERE client = 'bob';

  sum -------- 900.00 (1 row)

दूसरा लेन-देन समान राशि प्राप्त करता है।

 | => BEGIN ISOLATION LEVEL REPEATABLE READ; | => SELECT sum(amount) FROM accounts WHERE client = 'bob';

 | sum | -------- | 900.00 | (1 row)

पहला लेन-देन सही मानता है कि किसी एक खाते की राशि में 600 believes की कमी की जा सकती है।

 => UPDATE accounts SET amount = amount - 600.00 WHERE id = 2;

और दूसरा लेनदेन उसी निष्कर्ष पर आता है। लेकिन एक और स्कोर कम कर देता है:

 | => UPDATE accounts SET amount = amount - 600.00 WHERE id = 3; | => COMMIT;

 => COMMIT; => SELECT * FROM accounts WHERE client = 'bob';

  id | number | client | amount ----+--------+--------+--------- 2 | 2001 | bob | -400.00 3 | 2002 | bob | 100.00 (2 rows)

हम बॉब के संतुलन को माइनस में लाने में कामयाब रहे, हालांकि प्रत्येक लेनदेन व्यक्तिगत रूप से सही ढंग से काम करता है।

पढ़ें- केवल अनोमली

यह दोहराने योग्य पढ़ें स्तर पर संभव विसंगतियों का दूसरा और अंतिम है। इसे प्रदर्शित करने के लिए, आपको तीन लेनदेन की आवश्यकता होगी, जिनमें से दो डेटा को संशोधित करेंगे, और तीसरा - केवल पढ़ें।

लेकिन पहले, बॉब के खाते की स्थिति को पुनर्स्थापित करें:

 => UPDATE accounts SET amount = 900.00 WHERE id = 2; => SELECT * FROM accounts WHERE client = 'bob';

  id | number | client | amount ----+--------+--------+-------- 3 | 2002 | bob | 100.00 2 | 2001 | bob | 900.00 (2 rows)

पहला लेन-देन सभी खातों में धन की राशि पर बॉब के ब्याज का भुगतान करता है। ब्याज उनके खातों में से एक में जमा होता है:

 => BEGIN ISOLATION LEVEL REPEATABLE READ; -- 1 => UPDATE accounts SET amount = amount + ( SELECT sum(amount) FROM accounts WHERE client = 'bob' ) * 0.01 WHERE id = 2;

फिर एक अन्य लेन-देन बॉब के दूसरे खाते से पैसे निकालता है और उसके परिवर्तनों को पकड़ता है:

 | => BEGIN ISOLATION LEVEL REPEATABLE READ; -- 2 | => UPDATE accounts SET amount = amount - 100.00 WHERE id = 3; | => COMMIT;

यदि इस समय पहला लेन-देन प्रतिबद्ध है, तो कोई विसंगति नहीं होगी: हम मान सकते हैं कि पहला लेनदेन पहले पूरा हो गया था, और फिर दूसरा (लेकिन इसके विपरीत नहीं, क्योंकि पहले लेनदेन ने इस खाते से पहले आईडी आईडी = 3 की स्थिति देखी थी। दूसरी लेन-देन द्वारा परिवर्तित)।

लेकिन मान लीजिए कि इस समय तीसरा (केवल पढ़ने के लिए) लेनदेन शुरू होता है, जो पहले दो लेनदेन से प्रभावित नहीं होने वाले कुछ खाते की स्थिति को पढ़ता है:

 | => BEGIN ISOLATION LEVEL REPEATABLE READ; -- 3 | => SELECT * FROM accounts WHERE client = 'alice';

 | id | number | client | amount | ----+--------+--------+-------- | 1 | 1001 | alice | 800.00 | (1 row)

और उसके बाद ही पहला लेनदेन पूरा होता है:

 => COMMIT;

तीसरा लेन-देन अब किस राज्य को देखना चाहिए?

 | SELECT * FROM accounts WHERE client = 'bob';

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

 | id | number | client | amount | ----+--------+--------+-------- | 2 | 2001 | bob | 900.00 | 3 | 2002 | bob | 0.00 | (2 rows)

 | => COMMIT;

serializable

Serializable स्तर पर, सभी संभावित विसंगतियों को रोका जाता है। वास्तव में, डेटा स्नैपशॉट के आधार पर अलगाव को एक ऐड-ऑन के रूप में लागू किया जाता है। वे विसंगतियाँ जो रिपीटेबल रीडिंग के दौरान नहीं होती हैं (जैसे कि गंदी, गैर-दोहराने योग्य, प्रेत पढ़ी जाती हैं) सीरियल के स्तर पर नहीं होती हैं। और जो विसंगतियाँ उत्पन्न होती हैं (असंगत रिकॉर्डिंग और केवल पढ़ने के लेन-देन की विसंगति) का पता लगाया जाता है और लेन-देन निरस्त कर दिया जाता है - एक परिचित क्रमबद्धता त्रुटि पहुँच को क्रमबद्ध नहीं कर सकती है।

असंगत प्रविष्टि

वर्णन करने के लिए, हम असंगत रिकॉर्डिंग की विसंगति के साथ परिदृश्य को दोहराते हैं:

 => BEGIN ISOLATION LEVEL SERIALIZABLE; => SELECT sum(amount) FROM accounts WHERE client = 'bob';

  sum ---------- 910.0000 (1 row)

 | => BEGIN ISOLATION LEVEL SERIALIZABLE; | => SELECT sum(amount) FROM accounts WHERE client = 'bob';

 | sum | ---------- | 910.0000 | (1 row)

 => UPDATE accounts SET amount = amount - 600.00 WHERE id = 2;

 | => UPDATE accounts SET amount = amount - 600.00 WHERE id = 3; | => COMMIT;

 => COMMIT;

 ERROR: could not serialize access due to read/write dependencies among transactions DETAIL: Reason code: Canceled on identification as a pivot, during commit attempt. HINT: The transaction might succeed if retried.

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

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

वास्तव में, PostgreSQL का कार्यान्वयन ऐसा है कि यह झूठे नकारात्मक ट्रिगर की अनुमति देता है: कुछ पूरी तरह से सामान्य लेनदेन जो "बस भाग्य नहीं है" टूट जाएगा। जैसा कि हम बाद में देखेंगे, यह कई कारणों पर निर्भर करता है, उदाहरण के लिए, उपयुक्त इंडेक्स की उपलब्धता या रैम की उपलब्ध मात्रा। इसके अलावा, कुछ अन्य (बल्कि गंभीर) कार्यान्वयन प्रतिबंध हैं, उदाहरण के लिए, Serializable स्तर पर अनुरोध प्रतिकृतियों पर काम नहीं करेंगे, उनके लिए समानांतर निष्पादन योजनाओं का उपयोग नहीं किया जाएगा। और यद्यपि कार्यान्वयन में सुधार पर काम बंद नहीं होता है, लेकिन मौजूदा प्रतिबंध अलगाव के इस स्तर के आकर्षण को कम करते हैं।

समानांतर योजना PostgreSQL 12 ( पैच ) में दिखाई देगी। और प्रतिकृतियों पर क्वेरीज़ PostgreSQL 13 ( एक और पैच ) में कमा सकते हैं।

पढ़ें- केवल अनोमली

ताकि केवल एक रीडिंग ट्रांजेक्शन से कोई विसंगति पैदा न हो और इससे नुकसान न हो, PostgreSQL एक दिलचस्प तंत्र प्रदान करता है: इस तरह के लेनदेन को तब तक अवरुद्ध किया जा सकता है जब तक कि इसका निष्पादन सुरक्षित न हो। यह एकमात्र ऐसा मामला है जहां पंक्ति अपडेट द्वारा एक SELECT स्टेटमेंट को ब्लॉक किया जा सकता है। यहाँ यह कैसा दिखता है:

 => UPDATE accounts SET amount = 900.00 WHERE id = 2; => UPDATE accounts SET amount = 100.00 WHERE id = 3; => SELECT * FROM accounts WHERE client = 'bob' ORDER BY id;

  id | number | client | amount ----+--------+--------+-------- 2 | 2001 | bob | 900.00 3 | 2002 | bob | 100.00 (2 rows)

 => BEGIN ISOLATION LEVEL SERIALIZABLE; -- 1 => UPDATE accounts SET amount = amount + ( SELECT sum(amount) FROM accounts WHERE client = 'bob' ) * 0.01 WHERE id = 2;

 | => BEGIN ISOLATION LEVEL SERIALIZABLE; -- 2 | => UPDATE accounts SET amount = amount - 100.00 WHERE id = 3; | => COMMIT;

तीसरा लेन-देन स्पष्ट रूप से केवल पाठक (केवल पढ़ें) और आस्थगित (DEFERRABLE) द्वारा घोषित किया गया है:

 | => BEGIN ISOLATION LEVEL SERIALIZABLE READ ONLY DEFERRABLE; -- 3 | => SELECT * FROM accounts WHERE client = 'alice';

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

 => COMMIT;

और केवल पहला लेनदेन करने के बाद, तीसरा निष्पादित करना जारी रखता है:

 | id | number | client | amount | ----+--------+--------+-------- | 1 | 1001 | alice | 800.00 | (1 row)

 | => SELECT * FROM accounts WHERE client = 'bob';

 | id | number | client | amount | ----+--------+--------+---------- | 2 | 2001 | bob | 910.0000 | 3 | 2002 | bob | 0.00 | (2 rows)

 | => COMMIT;

एक और महत्वपूर्ण नोट: यदि सीरियल योग्य अलगाव का उपयोग किया जाता है, तो आवेदन में सभी लेनदेन इस स्तर का उपयोग करना चाहिए। आप Serializable के साथ Read Committed (या repeatable Read) को मिक्स नहीं कर सकते। यही है, आप कुछ मिश्रण कर सकते हैं, लेकिन तब सीरियल से चेतावनी के बिना एक दोहराने योग्य पढ़ें की तरह व्यवहार करेंगे।ऐसा क्यों होता है, हम बाद में विचार करेंगे जब हम कार्यान्वयन के बारे में बात करेंगे।

इसलिए यदि आप Serializble का उपयोग करने का निर्णय लेते हैं, तो यह विश्व स्तर पर डिफ़ॉल्ट स्तर निर्धारित करने के लिए सबसे अच्छा है (हालाँकि यह, ज़ाहिर है, गलत स्तर को स्पष्ट रूप से निर्दिष्ट करने से मना नहीं करता है):

  ALTER SYSTEM SET default_transaction_isolation = 'serializable';

लेन-देन, स्थिरता, और विसंगतियों से संबंधित मुद्दों की एक अधिक कठोर प्रस्तुति बोरिस एसेनोविच नोविकोव की पुस्तक और व्याख्यान पाठ्यक्रम में पाई जा सकती है , "फंडामेंटल ऑफ डेटाबेस टेक्नोलॉजीज।"

मुझे किस स्तर के इन्सुलेशन का उपयोग करना चाहिए?

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

सिक्के के फ्लिप पक्ष में बड़ी संख्या में संभावित विसंगतियाँ हैं जिनके बारे में ऊपर विस्तार से चर्चा की गई है। डेवलपर को उन्हें लगातार ध्यान में रखना होगा और कोड को इस तरह से लिखना होगा ताकि उनकी घटना को रोका जा सके। यदि किसी एकल SQL कथन में आवश्यक क्रियाओं को तैयार करना संभव नहीं है, तो आपको स्पष्ट रूप से ताले सेट करने का सहारा लेना होगा। सबसे अप्रिय बात यह है कि असंगत डेटा प्राप्त करने से जुड़ी त्रुटियों के लिए कोड का परीक्षण करना मुश्किल है, और त्रुटियां स्वयं अप्रत्याशित और अपरिवर्तनीय तरीके से हो सकती हैं और इसलिए उन्हें ठीक करना मुश्किल है।

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

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

जारी रखा जाए ।

MVCC -1। इन्सुलेशन

इन्सुलेशन क्या है और यह महत्वपूर्ण क्यों है?

SQL अलगाव स्तर और विसंगतियाँ

अद्यतन खो दिया है

डर्टी रीडिंग और अनकम्ड रीड

नॉन-रिपीट रीड एंड रीड कमिटेड

प्रेत पढ़ें और बार-बार पढ़ें

विसंगतियों और सीरियल के अभाव

सारांश प्लेट

आखिर ये विसंगतियाँ क्यों?

PostgreSQL अलगाव स्तर

प्रतिबद्ध पढ़ो

गंदे पढ़ने का अभाव

नॉन-रिपीट रीडिंग

असंगत पढ़ना

खोए हुए परिवर्तनों के बदले में लगातार पढ़ना

बार-बार पढ़ने योग्य

गैर-दोहराव और प्रेत रीडिंग का अभाव

खोए हुए परिवर्तनों के बदले में सीरियलाइज़ेशन त्रुटि

असंगत प्रविष्टि

पढ़ें- केवल अनोमली

serializable

असंगत प्रविष्टि

पढ़ें- केवल अनोमली

मुझे किस स्तर के इन्सुलेशन का उपयोग करना चाहिए?

More articles: