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

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

दुर्भाग्य से, इस समय अंग्रेजी में उपलब्ध एकमात्र कोर्स 2-डे इंट्रोडक्शन टू पोस्टग्रेसीक्यू 11 है ।

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

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

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

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

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

हम चले!

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

अलगाव क्या है और यह क्यों महत्वपूर्ण है?

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

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

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

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

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

इसके अलावा हम शुद्धता के संदर्भ के लिए शब्द संगति का उपयोग करेंगे।

हालांकि, हमें लगता है कि एक एप्लिकेशन केवल ऑपरेटरों के सही क्रम को निष्पादित करता है। यदि आवेदन सही है तो DBMS की क्या भूमिका है?

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

एक अच्छा व्यायाम अखंडता बाधाओं के स्तर पर उपरोक्त नियम को लागू करना है।

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

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

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

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

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

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

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

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

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

इसलिए हम परिभाषा पर पहुंचे:

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

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

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

एसक्यूएल मानक में अलगाव के स्तर और विसंगतियों

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

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

हानि अद्यतन

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

उदाहरण के लिए, दो लेनदेन ₽100 (। रूसी रूबल के लिए मुद्रा चिह्न) द्वारा एक ही खाते पर राशि बढ़ाने जा रहे हैं। पहला लेन-देन वर्तमान मूल्य (transaction1000) पढ़ता है और फिर दूसरा लेनदेन उसी मूल्य को पढ़ता है। पहला लेनदेन राशि बढ़ाता है (यह transaction1100 देता है) और इस मूल्य को लिखता है। दूसरा लेन-देन उसी तरह से कार्य करता है: यह समान and1100 प्राप्त करता है और यह मान लिखता है। परिणामस्वरूप, ग्राहक को .100 का नुकसान हुआ।

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

गंदे पढ़े और पढ़े बिना पढ़े

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

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

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

नॉन-रिपीटेबल रीड और रीड कमिटेड

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

उदाहरण के लिए, ग्राहक खातों पर नकारात्मक मात्रा को रोकने के लिए एक संगति नियम दें। पहला लेनदेन .100 द्वारा खाते पर राशि को कम करने वाला है। यह वर्तमान मूल्य की जांच करता है, and1000 प्राप्त करता है और निर्णय लेता है कि कमी संभव है। उसी समय दूसरा लेन-देन खाते में राशि को शून्य तक कम कर देता है और परिवर्तनों को शुरू करता है। यदि पहले लेन-देन में अब राशि की पुनरावृत्ति होती है, तो उसे but0 मिलेगा (लेकिन यह पहले से ही मूल्य कम करने का निर्णय ले चुका है, और खाता "लाल में चला जाता है")।

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

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

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

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

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

विसंगतियों और क्रमिक अनुपस्थिति

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

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

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

सारांश तालिका

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

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

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

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

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

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

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

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

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

यदि कोई लेन-देन पढ़ने के लिए और संशोधित होने और दोनों को पढ़ने और अद्यतन करने से पंक्तियों को लॉक करता है, तो हमें दोहराने योग्य पढ़ें स्तर मिलता है: पंक्ति को फिर से पढ़ने से समान मान वापस आ जाएगा।

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

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

PostgreSQL में अलगाव स्तर

समय के साथ, लेन-देन प्रबंधन के लॉक-आधारित प्रोटोकॉल को स्नैपशॉट अलगाव प्रोटोकॉल (SI) से बदल दिया गया। इसका विचार यह है कि प्रत्येक लेनदेन एक निश्चित समय पर डेटा के लगातार स्नैपशॉट के साथ काम करता है, और केवल उन परिवर्तनों को स्नैपशॉट में प्राप्त होता है जो इसे बनाने से पहले प्रतिबद्ध थे।

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

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

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

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

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

=> 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;

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

पढ़े हुए स्तर पर रहते हुए इस तरह की विसंगति से कैसे बचा जाए? बेशक, एक ऑपरेटर का उपयोग करें। उदाहरण के लिए:

  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 आपको फ़ंक्शन को परिभाषित करने की अनुमति देता है, और फ़ंक्शन में अस्थिरता श्रेणी की अवधारणा होती है। यदि किसी फ़ंक्शन में एक VOLATILE फ़ंक्शन को कॉल किया जाता है और उस फ़ंक्शन में किसी अन्य क्वेरी को निष्पादित किया जाता है, तो फ़ंक्शन के अंदर क्वेरी में डेटा दिखाई देगा जो मुख्य क्वेरी में डेटा के साथ असंगत हैं।

 => 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;

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

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

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

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

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

आइए देखें कि क्या होता है जब दो लेनदेन एक ही पंक्ति को संशोधित करने का प्रयास करते हैं। अब बॉब के दो खातों पर Bob1000 है:

 => 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;

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

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

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

निष्पादन का दूसरा चरण चयनित पंक्तियों को एक-एक करके अद्यतन कर रहा है। यहां दूसरा लेन-देन "लटका" करने के लिए मजबूर किया जाता है क्योंकि आईडी = 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 उस पंक्ति को फिर से पढ़ता है जिसे वह अपडेट करना चाह रहा है (लेकिन केवल यह एक)। परिणामस्वरूप, बॉब ने ,900 की राशि के आधार पर ,9 अर्जित किया। लेकिन अगर बॉब के पास ₽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;<span/> | => UPDATE accounts SET amount = amount * 1.01<span/> | WHERE client IN (<span/> | SELECT client<span/> | FROM accounts<span/> | GROUP BY client<span/> | HAVING sum(amount) >= 1000<span/> | );<span/>

 => 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 के लिए, बल्कि स्नैपशॉट अलगाव के अन्य कार्यान्वयन के लिए भी सच है।)

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

निम्नलिखित स्थिरता नियम को मानें: यदि ग्राहक के सभी खातों पर कुल राशि गैर-ऋणात्मक बनी हुई है, तो ग्राहक खातों पर नकारात्मक राशि की अनुमति है ।

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

 => 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 तक कम हो सकती है।

 => 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

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

असंगत लेखन

इसे समझने के लिए, आइए एक असंगत लेखन विसंगति के साथ परिदृश्य को दोहराएं:

 => 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 एक दिलचस्प तकनीक प्रदान करता है: ऐसा लेनदेन तब तक बंद रखा जा सकता है जब तक कि इसका निष्पादन सुरक्षित न हो। यह एकमात्र मामला है जब एक सेलेक्ट ऑपरेटर को पंक्ति अपडेट द्वारा लॉक किया जा सकता है। यह ऐसा दिखता है:

 => 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;

तीसरे लेनदेन को स्पष्ट रूप से केवल और निश्चित रूप से घोषित किया गया है:

 | => 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 प्रश्नों का उपयोग करने वाली रिपोर्ट बनाने के लिए बहुत सुविधाजनक है।

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

पर पढ़ें ।

PostgreSQL-1 में MVCC। अलगाव

अलगाव क्या है और यह क्यों महत्वपूर्ण है?

एसक्यूएल मानक में अलगाव के स्तर और विसंगतियों

हानि अद्यतन

गंदे पढ़े और पढ़े बिना पढ़े

नॉन-रिपीटेबल रीड और रीड कमिटेड

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

विसंगतियों और क्रमिक अनुपस्थिति

सारांश तालिका

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

PostgreSQL में अलगाव स्तर

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

गंदे पढ़ने की अनुपस्थिति

न पढ़ने वाला

असंगत पढ़ा

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

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

गैर-दोहराने योग्य और प्रेत की अनुपस्थिति पढ़ता है

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

असंगत लेखन

पढ़ें-केवल लेनदेन की विसंगति

serializable

असंगत लेखन

पढ़ें-केवल लेनदेन की विसंगति

किस अलगाव स्तर का उपयोग करना है?

More articles: