पोस्टग्रेज लॉक मैनेजर को अनलॉक करना। ब्रूस मोमजियन

ब्रूस मोमजियन की 2020 वार्ता "अनलॉकिंग द पोस्टग्रेस लॉक मैनेजर" की प्रतिलेख।

(नोट: स्लाइड्स से सभी SQL प्रश्न इस लिंक से प्राप्त किए जा सकते हैं: http://momjian.us/main/writings/pgsql/locking.sql)

नमस्ते! यहां रूस में दोबारा आना बहुत अच्छा है। मुझे खेद है कि मैं पिछले साल नहीं आ सका, लेकिन इस साल इवान और मेरी बड़ी योजनाएँ हैं। मुझे आशा है कि मैं यहां अधिक बार आ सकूंगा। मुझे रूस आना बहुत पसंद है. मैं टूमेन, टवर का दौरा करूंगा। मुझे बहुत खुशी है कि मैं इन शहरों का दौरा कर सकूंगा।

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

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

यह काफी अप्रिय बातचीत है. ब्लॉक करना सबसे लोकप्रिय विषय नहीं है. हम चाहते हैं कि ये कहीं गायब हो जाए. यह दंत चिकित्सक के पास जाने जैसा है।

1. लॉकिंग उन बहुत से लोगों के लिए एक समस्या है जो डेटाबेस में काम करते हैं और एक ही समय में कई प्रक्रियाएँ चल रही हैं। उन्हें ब्लॉक करने की जरूरत है. यानी आज मैं आपको ब्लॉक करने पर बेसिक जानकारी दूंगा।
2. लेन-देन आईडी. यह प्रेजेंटेशन का काफी उबाऊ हिस्सा है, लेकिन उन्हें समझने की जरूरत है।
3. आगे हम ब्लॉकिंग के प्रकारों के बारे में बात करेंगे। यह काफी यांत्रिक हिस्सा है.
4. और नीचे हम ब्लॉकिंग के कुछ उदाहरण देंगे। और इसे समझना काफी कठिन होगा.

चलो ब्लॉक करने के बारे में बात करते हैं.

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

और यहां हम उन तालों के नाम देखते हैं जो Oracle से हमारे पास आए थे। हम उन का उपयोग करते हैं।

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

और "पहुँच" शब्द भी बहुत महत्वपूर्ण है। और शब्द "पंक्ति" एक स्ट्रिंग हैं। यानी एक्सेस डिस्ट्रीब्यूशन, रो डिस्ट्रीब्यूशन।

एक और मुद्दा जिसे पोस्टग्रेज़ में समझने की आवश्यकता है, जिसे मैं दुर्भाग्य से अपनी बातचीत में शामिल नहीं कर पाऊंगा, वह है एमवीसीसी। मेरी वेबसाइट पर इस विषय पर एक अलग प्रस्तुति है। और अगर आपको लगता है कि यह प्रस्तुति कठिन है, तो एमवीसीसी शायद मेरी सबसे कठिन प्रस्तुति है। और यदि आपकी रुचि हो तो आप इसे वेबसाइट पर देख सकते हैं। आप वीडियो देख सकते हैं.

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

यह भी ध्यान रखें कि स्लाइड्स को समझना काफी कठिन होगा, इसलिए लाल रंग में जो हाइलाइट किया गया है उस पर आपको ध्यान देने की आवश्यकता है।

http://momjian.us/main/writings/pgsql/locking.sql

चलो देखते हैं। लेन-देन संख्या लाल रंग में हाइलाइट की गई है। SELECT pg_back फ़ंक्शन यहां दिखाया गया है। यह मेरा लेनदेन और लेनदेन आईडी लौटाता है।

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

इस मामले में हम लेनदेन आईडी देखते हैं। यह वह नंबर है जिसे हमने उसे सौंपा है। और Postgres में एक अन्य प्रकार की लेनदेन आईडी होती है, जिसे वर्चुअल लेनदेन आईडी कहा जाता है

और हमें ये समझना होगा. यह बहुत महत्वपूर्ण है, अन्यथा हम Postgres में लॉकिंग को समझ नहीं पाएंगे।

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

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

इसलिए, यदि मैं अनुरोध चलाता हूं, तो यह कहता है कि बैकएंड आईडी 2 है।

और अगर मैं ऐसे लेन-देन की एक श्रृंखला चलाता हूं, तो हम देखते हैं कि हर बार जब मैं कोई क्वेरी चलाता हूं तो काउंटर बढ़ जाता है। उदाहरण के लिए, जब मैं क्वेरी 2/10, 2/11, 2/12 इत्यादि चलाता हूँ।

ध्यान रखें कि यहां दो कॉलम हैं. बाईं ओर हम वर्चुअल ट्रांजेक्शन आईडी - 2/12 देखते हैं। और दाईं ओर हमारे पास एक स्थायी लेनदेन आईडी है। और यह फ़ील्ड खाली है. और यह लेनदेन डेटाबेस को संशोधित नहीं करता है। इसलिए मैं इसे स्थायी लेनदेन आईडी नहीं देता।

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

तो यहाँ एक और अनुरोध, एक और लेन-देन है। आभासी लेनदेन संख्या 2/13 है। और यदि मैं लगातार लेनदेन आईडी मांगता हूं, तो जब मैं क्वेरी चलाऊंगा, तो मुझे यह मिल जाएगा।

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

हम तीसरे खंड की ओर बढ़ते हैं। यहां हम पोस्टग्रेज़ में विभिन्न प्रकार के तालों के बारे में जानेंगे। यह बहुत दिलचस्प नहीं है. अंतिम भाग अधिक रोचक होगा. लेकिन हमें बुनियादी बातों पर विचार करना चाहिए, क्योंकि अन्यथा हम समझ नहीं पाएंगे कि आगे क्या होगा।

हम इस अनुभाग को पढ़ेंगे, हम प्रत्येक प्रकार के ताले को देखेंगे। और मैं आपको उदाहरण दिखाऊंगा कि वे कैसे स्थापित हैं, वे कैसे काम करते हैं, मैं आपको कुछ प्रश्न दिखाऊंगा जिनका उपयोग आप यह देखने के लिए कर सकते हैं कि पोस्टग्रेज में लॉकिंग कैसे काम करती है।

एक क्वेरी बनाने और यह देखने के लिए कि पोस्टग्रेज़ में क्या हो रहा है, हमें सिस्टम दृश्य में क्वेरी जारी करने की आवश्यकता है। इस स्थिति में, pg_lock को लाल रंग में हाइलाइट किया गया है। Pg_lock एक सिस्टम टेबल है जो हमें बताती है कि पोस्टग्रेज़ में वर्तमान में कौन से लॉक उपयोग में हैं।

हालाँकि, मेरे लिए आपको अकेले pg_lock दिखाना बहुत कठिन है क्योंकि यह काफी जटिल है। इसलिए मैंने एक दृश्य बनाया जो pg_locks दिखाता है। और यह मेरे लिए कुछ काम भी करता है जिससे मुझे बेहतर ढंग से समझने में मदद मिलती है। यानी, इसमें मेरे लॉक, मेरा अपना सत्र आदि शामिल नहीं है। यह सिर्फ मानक एसक्यूएल है और यह आपको बेहतर ढंग से दिखाने की अनुमति देता है कि क्या हो रहा है।

दूसरी समस्या यह है कि यह दृश्य बहुत व्यापक है, इसलिए मुझे दूसरा दृश्य बनाना होगा - लॉकव्यू2।

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

इसलिए हमने लॉकडेमो नामक एक तालिका बनाई। और हमने वहां एक लाइन बनाई. यह हमारी नमूना तालिका है. और हम आपको केवल तालों के उदाहरण दिखाने के लिए अनुभाग बनाएंगे।

तो, एक पंक्ति, एक स्तंभ। पहले प्रकार के लॉक को एक्सेस शेयर कहा जाता है। यह सबसे कम प्रतिबंधात्मक अवरोधन है. इसका मतलब यह है कि यह व्यावहारिक रूप से अन्य तालों के साथ संघर्ष नहीं करता है।

और यदि हम किसी लॉक को स्पष्ट रूप से परिभाषित करना चाहते हैं, तो हम "लॉक टेबल" कमांड चलाते हैं। और यह स्पष्ट रूप से ब्लॉक हो जाएगा, यानी एक्सेस शेयर मोड में हम लॉक टेबल लॉन्च करते हैं। और यदि मैं पृष्ठभूमि में पीएसक्यूएल चलाता हूं, तो मैं अपने पहले सत्र से दूसरा सत्र इस तरह शुरू करता हूं। यानी मैं यहां क्या करूंगा? मैं दूसरे सत्र में जाता हूं और उससे कहता हूं "मुझे इस अनुरोध के लिए लॉकव्यू दिखाओ।" और यहाँ मेरे पास इस तालिका में AccessShareLock है। यह बिल्कुल वही है जो मैंने अनुरोध किया था। और उनका कहना है कि ब्लॉक दे दिया गया है. बहुत सरल।

इसके अलावा अगर हम दूसरे कॉलम को देखें तो वहां कुछ भी नहीं है. वे खाली हैं.

और यदि मैं "SELECT" कमांड चलाता हूं, तो यह AccessShareLock का अनुरोध करने का अंतर्निहित (स्पष्ट) तरीका है। इसलिए मैं अपनी तालिका जारी करता हूं और क्वेरी चलाता हूं और क्वेरी कई पंक्तियां लौटाती है। और एक पंक्ति में हम AccessShareLock देखते हैं। इस प्रकार, SELECT टेबल पर AccessShareLock को कॉल करता है। और यह वस्तुतः किसी भी चीज़ के साथ संघर्ष नहीं करता है क्योंकि यह निम्न-स्तरीय लॉक है।

यदि मैं SELECT चलाऊँ और मेरे पास तीन अलग-अलग तालिकाएँ हों तो क्या होगा? पहले मैं केवल एक टेबल चला रहा था, अब मैं तीन चला रहा हूं: pg_class, pg_namespace और pg_attribute।

और अब जब मैं क्वेरी को देखता हूं, तो मुझे तीन तालिकाओं में 9 AccessShareLocks दिखाई देते हैं। क्यों? तीन तालिकाएँ नीले रंग में हाइलाइट की गई हैं: pg_attribute, pg_class, pg_namespace। लेकिन आप यह भी देख सकते हैं कि इन तालिकाओं के माध्यम से परिभाषित सभी अनुक्रमणिका में AccessShareLock भी है।

और यह एक ऐसा ताला है जो व्यावहारिक रूप से दूसरों के साथ संघर्ष नहीं करता है। और यह बस हमें तालिका का चयन करते समय उसे रीसेट करने से रोकता है। यह समझ में आता है। यानी अगर हम कोई टेबल सेलेक्ट करते हैं और वह उसी वक्त गायब हो जाती है तो यह गलत है, इसलिए एक्सेसशेयर एक निम्न स्तर का लॉक है जो हमें बताता है "जब मैं काम कर रहा हूं तो इस तालिका को न गिराएं". मूलतः, वह बस यही करती है।

रो शेयर - यह लॉक थोड़ा अलग है।

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

तो शेयर लॉक क्या करता है? हम देखते हैं कि SELECT के लिए लेनदेन आईडी 681 है। और ये दिलचस्प है. यहां क्या हुआ? पहली बार जब हम नंबर देखते हैं तो वह "लॉक" फ़ील्ड में होता है। हम लेनदेन आईडी लेते हैं और यह कहता है कि यह इसे विशेष मोड में अवरुद्ध कर रहा है। यह बस इतना करता है कि यह कहता है कि मेरे पास एक पंक्ति है जो तकनीकी रूप से तालिका में कहीं बंद है। लेकिन वह यह नहीं बताता कि वास्तव में कहां। हम इस पर थोड़ी देर बाद और अधिक विस्तार से विचार करेंगे।

यहां हम कहते हैं कि ताला हमारे द्वारा उपयोग किया जाता है।

तो, एक एक्सक्लूसिव लॉक स्पष्ट रूप से कहता है कि यह एक्सक्लूसिव है। और साथ ही यदि आप इस तालिका में एक पंक्ति हटा देते हैं, तो ऐसा ही होगा, जैसा कि आप देख सकते हैं।

शेयर एक्सक्लूसिव एक लंबा लॉक है।

यह (विश्लेषण) विश्लेषक कमांड है जिसका उपयोग किया जाएगा।

शेयर लॉक - आप शेयर मोड में स्पष्ट रूप से लॉक कर सकते हैं।

आप एक अद्वितीय अनुक्रमणिका भी बना सकते हैं. और वहां आप शेयर लॉक देख सकते हैं, जो उनका हिस्सा है। और यह टेबल को लॉक कर देता है और उस पर SHARE LOCK लगा देता है।

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

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

शेयर रो एक्सक्लूसिव - फिर से इसे स्पष्ट रूप से (स्पष्ट रूप से) सेट किया जा सकता है।

या हम एक नियम बना सकते हैं, यानी, एक विशिष्ट मामला ले सकते हैं जिसमें इसका उपयोग किया जाएगा।

एक्सक्लूसिव लॉकिंग का मतलब है कि कोई भी व्यक्ति टेबल को नहीं बदल सकता है।

यहां हमें विभिन्न प्रकार के ताले देखने को मिलते हैं।

उदाहरण के लिए, एक्सेस एक्सक्लूसिव एक ब्लॉकिंग कमांड है। उदाहरण के लिए, यदि आप करते हैं CLUSTER table, तो इसका मतलब ये होगा कि वहां कोई लिख नहीं पाएगा. और यह न केवल तालिका को, बल्कि अनुक्रमणिका को भी लॉक कर देता है।

यह एक्सेस एक्सक्लूसिव ब्लॉकिंग का दूसरा पेज है, जहां हम देखते हैं कि यह तालिका में वास्तव में क्या ब्लॉक करता है। यह अलग-अलग टेबल पंक्तियों को लॉक कर देता है, जो काफी दिलचस्प है।

बस यही बुनियादी जानकारी है जो मैं देना चाहता था। हमने लॉक के बारे में बात की, लेनदेन आईडी के बारे में, हमने वर्चुअल लेनदेन आईडी के बारे में, स्थायी लेनदेन आईडी के बारे में बात की।

और अब हम कुछ अवरोधक उदाहरणों से गुजरेंगे। यह सबसे दिलचस्प हिस्सा है. हम बहुत दिलचस्प मामलों को देखेंगे. और इस प्रस्तुति में मेरा लक्ष्य आपको यह बेहतर समझ देना है कि पोस्टग्रेज वास्तव में क्या कर रहा है जब यह कुछ चीजों को अवरुद्ध करने का प्रयास करता है। मुझे लगता है कि वह हिस्सों को रोकने में बहुत अच्छा है।

आइए कुछ विशिष्ट उदाहरण देखें.

हम तालिकाओं और तालिका में एक पंक्ति से शुरुआत करेंगे। जब मैं कुछ डालता हूं तो मुझे टेबल पर एक्सक्लूसिवलॉक, ट्रांजेक्शन आईडी और एक्सक्लूसिवलॉक प्रदर्शित होता है।

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

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

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

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

यदि मैं दो पंक्तियाँ अद्यतन करना चाहूँ तो क्या होगा? और हम देखते हैं कि वह वैसा ही व्यवहार करता है। हम दोगुनी संख्या में अपडेट करते हैं, लेकिन लॉक लाइनों की संख्या बिल्कुल समान होती है।

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

यदि मैं कुछ हटाना चाहूँ तो क्या होगा? यदि मैं, उदाहरण के लिए, एक पंक्ति हटाता हूं और मेरे पास अभी भी मेरे दो अवरुद्ध इनपुट हैं, और यहां तक ​​​​कि अगर मैं उन सभी को हटाना चाहता हूं, तो वे अभी भी वहां हैं।

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

स्पष्ट अवरोधन के बारे में क्या?

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

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

और वही बात, अगर हम share करते हैं तो हम इसे पूरे 30 बार कर सकते हैं।

हम अपनी तालिका पुनर्स्थापित करते हैं, सब कुछ हटाते हैं, फिर एक पंक्ति दोबारा सम्मिलित करते हैं।

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

मैं आपको इसका एक उदाहरण दिखाता हूँ. मैं अब चुनाव करूंगा. फिर हम INSERT करेंगे. और फिर आप देख सकते हैं - 694। आप उस लेनदेन की आईडी देख सकते हैं जिसने यह प्रविष्टि की थी। और यह इसी तरह काम करता है.

और अगर मैं अब अपनी बैकएंड आईडी को देखूं, तो यह अब 695 है।

और मैं अपनी तालिका में 695 प्रदर्शित होते हुए देख सकता हूँ।

और अगर मैं यहां इस तरह से अपडेट करता हूं तो मुझे एक अलग मामला मिलता है। इस मामले में, 695 एक विशिष्ट लॉक है, और अद्यतन का व्यवहार समान है, लेकिन उनके बीच कोई विरोध नहीं है, जो काफी असामान्य है।

और आप देख सकते हैं कि सबसे ऊपर यह ShareLock है, और सबसे नीचे यह एक्सक्लूसिवलॉक है। और दोनों लेन-देन सफल हो गये।

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

आइए रीसेट करें और एक और ऑपरेशन करें।

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

और इसे स्पष्ट करने के लिए, मैं लॉकडेमो तालिका को देखूंगा। और हम एक पंक्ति को देखेंगे. प्रति लेनदेन 698.

हमने इसे 2 तक अपडेट कर दिया है। 699 पहला अपडेट है. और यह सफल रहा या यह लंबित लेनदेन में है और हमारे पुष्टि या रद्द करने की प्रतीक्षा कर रहा है।

लेकिन कुछ और देखें - 2/51 हमारा पहला लेनदेन है, हमारा पहला सत्र है। 3/112 शीर्ष से आया दूसरा अनुरोध है जिसने उस मान को 3 में बदल दिया है। और यदि आप ध्यान दें, तो शीर्ष ने खुद को लॉक कर दिया है, जो 699 है। लेकिन 3/112 ने लॉक की अनुमति नहीं दी। Lock_mode कॉलम बताता है कि वह किस चीज़ का इंतज़ार कर रहा है। यह 699 की अपेक्षा करता है। और यदि आप देखें कि 699 कहां है, तो यह अधिक है। और पहले सत्र ने क्या किया? उसने अपनी लेनदेन आईडी पर एक विशेष लॉक बनाया। पोस्टग्रेज़ इसे इसी प्रकार करता है। यह अपनी ही ट्रांजेक्शन आईडी को ब्लॉक कर देता है। और यदि आप किसी के पुष्टि या रद्द करने की प्रतीक्षा करना चाहते हैं, तो आपको लंबित लेनदेन होने तक प्रतीक्षा करनी होगी। और इसीलिए हम एक अजीब रेखा देख सकते हैं।

आइए फिर से देखें. बाईं ओर हम अपनी प्रोसेसिंग आईडी देखते हैं। दूसरे कॉलम में हम अपनी वर्चुअल ट्रांजेक्शन आईडी देखते हैं, और तीसरे में हम लॉक_टाइप देखते हैं। इसका अर्थ क्या है? मूलतः यह जो कहता है वह यह है कि यह लेनदेन आईडी को अवरुद्ध कर रहा है। लेकिन ध्यान दें कि नीचे की सभी पंक्तियाँ संबंध बताती हैं। और इसलिए आपकी मेज पर दो प्रकार के ताले हैं। एक रिलेशन लॉक है. और फिर ट्रांजेक्शनआईडी ब्लॉकिंग है, जहां आप खुद ही ब्लॉक कर देते हैं, जो बिल्कुल वैसा ही होता है जैसा कि पहली पंक्ति में या सबसे नीचे होता है, जहां ट्रांजैक्शनआईडी है, जहां हम अपना ऑपरेशन पूरा करने के लिए 699 का इंतजार करते हैं।

मैं देखूंगा कि यहां क्या होता है. और यहां दो चीजें एक साथ घटित होती हैं. आप पहली पंक्ति में एक लेनदेन आईडी लॉक देख रहे हैं जो स्वयं लॉक हो जाता है। और वह लोगों को इंतजार कराने के लिए खुद को रोक लेती है।

यदि आप छठी पंक्ति को देखें, तो यह पहली जैसी ही प्रविष्टि है। और इसलिए लेनदेन 6 अवरुद्ध है। 699 स्व-लॉकिंग भी है। और फिर नीचे की पंक्ति में आप देखेंगे कि हम 700 के संचालन समाप्त होने की प्रतीक्षा कर रहे हैं।

और लॉक_टाइप, टुपल में आपको संख्याएँ दिखाई देती हैं।

आप देख सकते हैं कि यह 0/10 है। और यह पृष्ठ संख्या है, और इस विशेष पंक्ति का ऑफसेट भी है।

और आप देखते हैं कि जब हम अपडेट करते हैं तो यह 0/11 हो जाता है।

लेकिन हकीकत में यह 0/10 है, क्योंकि इस ऑपरेशन के लिए इंतजार करना पड़ता है। हमारे पास यह देखने का अवसर है कि यह वह श्रृंखला है जिसकी मैं पुष्टि करने की प्रतीक्षा कर रहा हूं।

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

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

यह एक पुनरावर्ती दृश्य है जिसका एक अन्य खंड भी है। और फिर यह सब कुछ फिर से एक साथ लाता है। आइए इसका उपयोग करें.

क्या होगा यदि हम एक साथ तीन अपडेट करें और कहें कि पंक्ति अब तीन है। और हम 3 से 4 बदल देंगे.

और यहां हम 4. और ट्रांजेक्शन आईडी 702 देखते हैं।

और फिर मैं 4 को 5 में बदल दूँगा। और 5 को 6 में, और 6 को 7 में बदल दूँगा। और मैं कई लोगों को पंक्तिबद्ध कर दूँगा जो इस एक लेन-देन के ख़त्म होने का इंतज़ार कर रहे होंगे।

और सब कुछ स्पष्ट हो जाता है. पहली पंक्ति क्या है? यह 702 है। यह लेनदेन आईडी है जो मूल रूप से यह मान निर्धारित करती है। मेरे ग्रांटेड कॉलम में क्या लिखा है? मेरे पास निशान हैं f. ये मेरे अपडेट हैं जिन्हें (5, 6, 7) स्वीकृत नहीं किया जा सकता क्योंकि हम लेनदेन आईडी 702 के समाप्त होने की प्रतीक्षा कर रहे हैं। वहां हमारे पास ट्रांजेक्शन आईडी ब्लॉकिंग है। और इसके परिणामस्वरूप 5 ट्रांजेक्शनल आईडी लॉक हो जाते हैं।

और यदि आप 704, 705 को देखें, तो वहां अभी तक कुछ भी नहीं लिखा गया है, क्योंकि वे नहीं जानते कि अभी तक क्या हो रहा है। वे बस यही लिखते हैं कि उन्हें कुछ पता नहीं कि क्या हो रहा है. और वे बस इसलिए सो जाएंगे क्योंकि वे किसी के खत्म होने का इंतजार कर रहे हैं और जब पंक्तियां बदलने का मौका आएगा तो उन्हें जगाया जाएगा।

यह है जो ऐसा लग रहा है। साफ है कि ये सभी 12वीं लाइन का इंतजार कर रहे हैं.

हमने यहां यही देखा. यहाँ 0/12 है.

इसलिए एक बार पहला लेन-देन स्वीकृत हो जाने पर, आप यहां देख सकते हैं कि पदानुक्रम कैसे काम करता है। और अब सब कुछ स्पष्ट हो गया है. वे सब स्वच्छ हो जाते हैं। और वे वास्तव में अभी भी इंतज़ार कर रहे हैं.

यहाँ क्या हो रहा है. 702 प्रतिबद्ध. और अब 703 को यह पंक्ति लॉक मिल जाता है, और फिर 704 703 के प्रतिबद्ध होने की प्रतीक्षा करना शुरू कर देता है। और 705 भी इसका इंतज़ार कर रहा है. और जब ये सब पूरा हो जाता है तो वो खुद को साफ़ कर लेते हैं. और मैं यह बताना चाहूंगा कि हर कोई लाइन में लगा हुआ है। और यह ट्रैफिक जाम की स्थिति के समान है जब हर कोई पहली कार का इंतजार कर रहा होता है। पहली कार रुकती है और सभी लोग एक लंबी लाइन में खड़े हो जाते हैं। फिर यह चलती है, फिर अगली कार आगे बढ़ सकती है और अपना ब्लॉक आदि प्राप्त कर सकती है।

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

और, उदाहरण के लिए, यदि इवान कहता है: "मुझे कुछ दो," और मैं कहता हूं: "नहीं, मैं इसे तुम्हें तभी दूंगा जब तुम मुझे कुछ और दोगे।" और वह कहता है, "नहीं, यदि आप इसे मुझे नहीं देंगे तो मैं इसे आपको नहीं दूंगा।" और हम एक गतिरोध की स्थिति में पहुँच जाते हैं। मुझे यकीन है कि इवान ऐसा नहीं करेगा, लेकिन आप इसका मतलब समझते हैं कि हमारे पास दो लोग हैं जो कुछ पाना चाहते हैं और वे इसे तब तक देने के लिए तैयार नहीं हैं जब तक कि दूसरा व्यक्ति उन्हें वह नहीं दे देता जो वे चाहते हैं। और कोई समाधान नहीं है.

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

और अब हम दो डेडलॉक स्थापित करेंगे। हम 50 और 80 डालेंगे। पहली पंक्ति में, मैं 50 से 50 तक अपडेट करूंगा। मुझे लेनदेन संख्या 710 मिलेगी।

और फिर मैं 80 से 81, और 50 से 51 बदल दूँगा।

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

और यह यहां तक ​​बताता है कि किस पंक्ति में गतिरोध उत्पन्न होता है। और यहीं से यह अजीब होने लगता है।

अब हम 80 से 80 अपडेट कर रहे हैं.

और यहीं से गतिरोध शुरू होता है। 710, 711 से प्रतिक्रिया की प्रतीक्षा कर रहा है, और 711, 710 की प्रतीक्षा कर रहा है। और इसका अंत अच्छा नहीं होगा। और इससे निकलने का कोई रास्ता नहीं है. और वे एक-दूसरे से प्रतिक्रिया की अपेक्षा करेंगे।

और यह हर चीज़ में देरी करना शुरू कर देगा। और हम ऐसा नहीं चाहते.

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

क्या तीन-तरफ़ा गतिरोध हैं? क्या ऐसा संभव है? हाँ।

हम इन नंबरों को एक तालिका में दर्ज करते हैं। हम 40 से 40 बदलते हैं, हम ब्लॉकिंग करते हैं।

हम 60 से 61, 80 से 81 बदलते हैं।

और फिर हम 80 बदलते हैं और फिर उछाल!

और 714 अब 715 का इंतजार कर रहा है। 716वां 715वें का इंतजार कर रहा है। और इसके बारे में कुछ नहीं किया जा सकता.

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

और पोस्टग्रेज़ जानता है कि यह किस पंक्ति पर होता है। और इसलिए यह आपको निम्नलिखित संदेश देगा, जो दर्शाता है कि आपको एक समस्या है जहां तीन इनपुट एक दूसरे को अवरुद्ध कर रहे हैं। और यहां कोई प्रतिबंध नहीं है. यह ऐसा मामला हो सकता है जहां 20 प्रविष्टियां एक-दूसरे को अवरुद्ध करती हैं।

अगली समस्या क्रमबद्ध है.

यदि विशेष क्रमबद्ध लॉक।

और हम 719 पर लौटते हैं। इसका आउटपुट बिल्कुल सामान्य है।

और आप लेनदेन को क्रमबद्ध करने के लिए क्लिक कर सकते हैं।

और आपको एहसास होता है कि अब आपके पास एक अलग तरह का एसए लॉक है - इसका मतलब है क्रमबद्ध।

और इसलिए हमारे पास SARieadLock नामक एक नए प्रकार का लॉक है, जो एक सीरियल लॉक है और आपको सीरियल में प्रवेश करने की अनुमति देता है।

और आप अद्वितीय अनुक्रमणिका भी सम्मिलित कर सकते हैं।

इस तालिका में हमारे पास अद्वितीय अनुक्रमणिकाएँ हैं।

तो अगर मैं यहां नंबर 2 डालता हूं, तो मेरे पास 2 होता है। लेकिन सबसे ऊपर, मैं एक और 2 डालता हूं। और आप देख सकते हैं कि 721 में एक विशेष लॉक है। लेकिन अब 722 अपना ऑपरेशन पूरा होने के लिए 721 का इंतजार कर रहा है क्योंकि वह 2 तब तक नहीं डाल सकता जब तक उसे यह पता न चल जाए कि 721 का क्या होगा।

और यदि हम घटाव करते हैं।

यहां हमारे पास 723 हैं.

और अगर हम पॉइंट को सेव करते हैं और फिर उसे अपडेट करते हैं तो हमें एक नई ट्रांजैक्शन आईडी मिलती है। यह व्यवहार का एक और पैटर्न है जिसके बारे में आपको जागरूक होने की आवश्यकता है। अगर हम इसे वापस करते हैं तो ट्रांजैक्शन आईडी खत्म हो जाती है. 724 जा रहा है. लेकिन अब हमारे पास 725 हैं.

तो मैं यहाँ क्या करने का प्रयास कर रहा हूँ? मैं आपको असामान्य तालों के उदाहरण दिखाने की कोशिश कर रहा हूं जो आपको मिल सकते हैं: चाहे वह क्रमबद्ध ताले हों या SAVEPOINT, ये विभिन्न प्रकार के ताले हैं जो लॉक तालिका में दिखाई देंगे।

यह स्पष्ट (स्पष्ट) तालों का निर्माण है, जिसमें pg_advisory_lock है।

और आप देखते हैं कि अवरोधन प्रकार सलाहकार के रूप में सूचीबद्ध है। और यहाँ यह लाल रंग में "सलाहकार" कहता है। और आप एक साथ pg_advisory_unlock के साथ इस तरह ब्लॉक कर सकते हैं।

और अंत में, मैं आपको एक और चौंका देने वाली चीज़ दिखाना चाहूँगा। मैं एक और दृश्य बनाऊंगा. लेकिन मैं pg_locks तालिका को pg_stat_activity तालिका के साथ जोड़ूंगा। और मैं ऐसा क्यों करना चाहता हूँ? क्योंकि यह मुझे सभी मौजूदा सत्रों को देखने और यह देखने की अनुमति देगा कि वे वास्तव में किस प्रकार के लॉक की प्रतीक्षा कर रहे हैं। और यह काफी दिलचस्प है जब हम लॉक टेबल और क्वेरी टेबल को एक साथ रखते हैं।

और यहां हम pg_stat_view बनाते हैं।

और हम पंक्ति को एक-एक करके अद्यतन करते हैं। और यहां हम 724 देखते हैं। और फिर हम अपनी पंक्ति को तीन तक अद्यतन करते हैं। और अब आप यहाँ क्या देखते हैं? ये अनुरोध हैं, यानी आप बाएं कॉलम में सूचीबद्ध अनुरोधों की पूरी सूची देखते हैं। और फिर दाईं ओर आप रुकावटें और वे क्या पैदा करते हैं, देख सकते हैं। और यह आपके लिए अधिक स्पष्ट हो सकता है ताकि आपको हर बार प्रत्येक सत्र में वापस जाकर यह न देखना पड़े कि आपको इसमें शामिल होने की आवश्यकता है या नहीं। वे हमारे लिए ऐसा करते हैं.

एक और सुविधा जो बहुत उपयोगी है वह है pg_blocking_pids. आपने शायद उसके बारे में कभी नहीं सुना होगा। वह क्या कर रही है? यह हमें यह बताने की अनुमति देता है कि इस सत्र 11740 के लिए वह किस विशिष्ट प्रक्रिया आईडी की प्रतीक्षा कर रहा है। और आप देख सकते हैं कि 11740, 724 की प्रतीक्षा कर रहा है। और 724 सबसे ऊपर है। और 11306 आपकी प्रोसेस आईडी है। मूलतः, यह फ़ंक्शन आपकी लॉक टेबल से होकर गुजरता है। और मैं जानता हूं कि यह थोड़ा जटिल है, लेकिन आप इसे समझने में कामयाब होते हैं। अनिवार्य रूप से यह फ़ंक्शन इस लॉक टेबल के माध्यम से जाता है और यह पता लगाने की कोशिश करता है कि इस प्रक्रिया आईडी को वह लॉक कहां दिया गया है जिसका वह इंतजार कर रहा है। और यह यह भी पता लगाने की कोशिश करता है कि लॉक की प्रतीक्षा कर रही प्रक्रिया की कौन सी प्रक्रिया आईडी है। तो आप इस फ़ंक्शन को चला सकते हैं pg_blocking_pids.

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

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

प्रश्न:

उदाहरण के लिए, यदि मैं पंक्तियों को अद्यतन करने का प्रयास कर रहा हूं, और दूसरे सत्र में संपूर्ण तालिका को हटाने का प्रयास कर रहा हूं। जहां तक ​​मैं समझता हूं, इंटेंट लॉक जैसा कुछ होना चाहिए। क्या पोस्टग्रेज़ में ऐसी कोई चीज़ है?

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

चलो फिर से करे। चलिए डिलीट उदाहरण पर चलते हैं। और आप देखते हैं कि कैसे पूरी तालिका के ऊपर पंक्ति पर एक विशेष ताला लगा हुआ है।

यह लॉक एक्सक्लूसिव जैसा दिखेगा, है ना?

हाँ, ऐसा ही दिखता है. मैं समझ गया कि आप किस बारे में बात कर रहे हैं. आप कह रहे हैं कि यदि मैं SELECT करता हूं तो मेरे पास एक ShareExclusive होता है और फिर मैं इसे Row एक्सक्लूसिव बना देता हूं, क्या यह कोई समस्या बन जाती है? लेकिन आश्चर्य की बात यह है कि इससे कोई समस्या नहीं होती। यह लॉक डिग्री को बढ़ाने जैसा दिखता है, लेकिन अनिवार्य रूप से मेरे पास एक लॉक है जो विलोपन को रोकता है। और अब, जब मैं इस लॉक को और अधिक शक्तिशाली बनाता हूं, तब भी यह विलोपन को रोकता है। तो ऐसा नहीं है कि मैं ऊपर जा रहा हूँ। यानी, जब यह निचले स्तर पर था तब भी इसे होने से रोका, इसलिए जब मैं इसका स्तर बढ़ाता हूं तब भी यह तालिका को हटाए जाने से रोकता है।

मैं समझ गया कि आप किस बारे में बात कर रहे हैं. यहां कोई ताला बढ़ाने का मामला नहीं है, जहां आप एक मजबूत ताला लगाने के लिए एक ताला छोड़ने की कोशिश कर रहे हैं। यहां यह केवल बोर्ड भर में इस रोकथाम को बढ़ाता है, ताकि यह किसी भी संघर्ष का कारण न बने। लेकिन यह एक अच्छा सवाल है. यह पूछने के लिए आपका बहुत-बहुत धन्यवाद!

जब हमारे पास कई सत्र हों, बड़ी संख्या में उपयोगकर्ता हों तो गतिरोध की स्थिति से बचने के लिए हमें क्या करने की आवश्यकता है?

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

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

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

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

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

क्या आप स्लाइड 75 खोल सकते हैं?

हां.

और मेरा प्रश्न निम्नलिखित है. दोनों अद्यतन प्रक्रियाएँ 703 की अपेक्षा क्यों कर रही हैं?

और यह एक बड़ा सवाल है. वैसे, मुझे समझ नहीं आता कि पोस्टग्रेज़ ऐसा क्यों करता है। लेकिन जब 703 बनाया गया था, तो यह 702 की उम्मीद कर रहा था। और जब 704 और 705 दिखाई देते हैं, तो ऐसा लगता है जैसे वे नहीं जानते कि वे क्या उम्मीद कर रहे हैं क्योंकि वहां अभी तक कुछ भी नहीं है। और पोस्टग्रेज़ इसे इस तरह से करता है: जब आपको लॉक नहीं मिल पाता है, तो यह लिखता है "आपको संसाधित करने का क्या मतलब है?", क्योंकि आप पहले से ही किसी का इंतजार कर रहे हैं। तो हम इसे बस हवा में लटका देंगे, यह इसे बिल्कुल भी अपडेट नहीं करेगा। लेकिन यहाँ क्या हुआ? जैसे ही 702 ने प्रक्रिया पूरी की और 703 को इसका लॉक प्राप्त हुआ, सिस्टम वापस लौट आया। और उसने कहा कि अब हमारे पास दो लोग हैं जो इंतजार कर रहे हैं. और फिर आइए उन्हें एक साथ अपडेट करें। और बता दें कि दोनों उम्मीद कर रहे हैं.

मुझे नहीं पता कि पोस्टग्रेज़ ऐसा क्यों करता है। लेकिन एक समस्या है जिसका नाम है f.... मुझे ऐसा लगता है कि यह रूसी भाषा का कोई शब्द नहीं है। यह तब है जब हर कोई एक महल की प्रतीक्षा कर रहा है, भले ही 20 अधिकारी हों जो महल की प्रतीक्षा कर रहे हों। और अचानक वे सभी एक ही समय में जाग जाते हैं। और हर कोई प्रतिक्रिया देने की कोशिश करने लगता है. लेकिन सिस्टम ऐसा बनाता है कि हर कोई 703 का इंतजार कर रहा है। क्योंकि वे सभी इंतजार कर रहे हैं, और हम तुरंत उन सभी को लाइन में लगा देंगे। और यदि कोई अन्य नया अनुरोध प्रकट होता है जो इसके बाद उत्पन्न हुआ था, उदाहरण के लिए, 707, तो फिर से खालीपन होगा।

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

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

मुझे ऐसा लगता है कि यह अधिक तर्कसंगत है जब 705, 704 की अपेक्षा करता है।

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

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

वहाँ ईगोर रोगोव द्वारा तालों के बारे में लेख. देखिये, ये दिलचस्प भी हैं और उपयोगी भी। निःसंदेह, विषय अत्यंत जटिल है। बहुत बहुत धन्यवाद, ब्रूस!

स्रोत: www.habr.com