Postgres लक प्रबन्धक अनलक गर्दै। ब्रुस मोमजियन

ब्रुस मोमजियनको २०२० वार्ताको ट्रान्सक्रिप्ट "अनलकिङ द पोस्टग्रेस लक प्रबन्धक"।

(नोट: स्लाइडहरूबाट सबै SQL प्रश्नहरू यो लिङ्कबाट प्राप्त गर्न सकिन्छ: http://momjian.us/main/writings/pgsql/locking.sql)

नमस्ते! यहाँ फेरि रूसमा आउन पाउनु राम्रो छ। मलाई माफ गर्नुहोस् म गत वर्ष आउन सकिन, तर यो वर्ष इभान र मसँग ठूलो योजना छ। म यहाँ धेरै पटक आउने आशा गर्दछु। मलाई रूस आउन मन पर्छ। म Tyumen, Tver भ्रमण गर्नेछु। म धेरै खुसी छु कि म यी शहरहरू भ्रमण गर्न सक्षम हुनेछु।

मेरो नाम ब्रुस मोमजियान हो। म EnterpriseDB मा काम गर्छु र 23 वर्ष भन्दा बढीको लागि Postgres सँग काम गर्दैछु। म अमेरिकाको फिलाडेल्फियामा बस्छु। म वर्षमा करिब ९० दिन यात्रा गर्छु। र म लगभग 90 सम्मेलनहरूमा भाग लिन्छु। मेरो वेब साइट, जसले स्लाइडहरू समावेश गर्दछ जुन म अब तपाइँलाई देखाउनेछु। तसर्थ, सम्मेलन पछि तपाइँ तिनीहरूलाई मेरो व्यक्तिगत वेबसाइटबाट डाउनलोड गर्न सक्नुहुन्छ। यसमा लगभग 30 प्रस्तुतिहरू पनि छन्। त्यहाँ भिडियोहरू र ठूलो संख्यामा ब्लग प्रविष्टिहरू पनि छन्, 500 भन्दा बढी। यो एकदम जानकारीमूलक स्रोत हो। र यदि तपाइँ यो सामग्रीमा रुचि राख्नुहुन्छ भने, म तपाइँलाई यसलाई प्रयोग गर्न आमन्त्रित गर्दछु।

मैले पोस्टग्रेसमा काम गर्न सुरु गर्नु अघि म एक शिक्षक, एक प्रोफेसर थिएँ। र म धेरै खुसी छु कि म अब तपाईलाई के भन्न चाहन्छु भन्न सक्षम हुनेछु। यो मेरो सबैभन्दा रोचक प्रस्तुतीकरण मध्ये एक हो। र यो प्रस्तुतिमा 110 स्लाइडहरू छन्। हामी साधारण कुराहरु संग कुरा सुरु गर्नेछौं, र अन्त सम्म रिपोर्ट झन् झन् जटिल हुँदै जान्छ, र धेरै जटिल हुनेछ।

यो एक बरु अप्रिय कुराकानी हो। अवरुद्ध सबैभन्दा लोकप्रिय विषय होइन। हामी यो कतै हराउन चाहन्छौं। दन्तचिकित्सककहाँ जानु जस्तै हो।

1. डाटाबेसमा काम गर्ने र एकै समयमा धेरै प्रक्रियाहरू चल्ने धेरै व्यक्तिहरूको लागि लक गर्ने समस्या हो। तिनीहरूलाई अवरुद्ध गर्न आवश्यक छ। त्यो हो, आज म तपाईलाई ब्लक गर्ने आधारभूत ज्ञान दिनेछु।
2. लेनदेन आईडीहरू। यो प्रस्तुति को एक बरु बोरिंग भाग हो, तर तिनीहरूलाई बुझ्न आवश्यक छ।
3. अर्को हामी अवरुद्ध प्रकार को बारे मा कुरा गर्नेछौं। यो एकदम मेकानिकल भाग हो।
4. र तल हामी अवरुद्धका केही उदाहरणहरू दिनेछौं। र यो बुझ्न धेरै गाह्रो हुनेछ।

अवरुद्धको बारेमा कुरा गरौं।

हाम्रो शब्दावली धेरै जटिल छ। तपाईं मध्ये कति जनालाई थाहा छ यो खण्ड कहाँबाट आएको हो? दुई जना । यो Colossal Cave Adventure भनिने खेलबाट हो। यो 80s मा पाठ-आधारित कम्प्युटर खेल थियो, मलाई लाग्छ। त्यहाँ तपाईंले गुफामा, भूलभुलैयामा जानुपर्थ्यो, र पाठ परिवर्तन भयो, तर सामग्री हरेक पटक लगभग उस्तै थियो। यसरी सम्झन्छु यो खेल ।

र यहाँ हामी ओरेकलबाट आएको तालाहरूको नाम देख्छौं। हामी तिनीहरूलाई प्रयोग गर्छौं।

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

र "पहुँच" शब्द पनि धेरै महत्त्वपूर्ण छ। र शब्द "पङ्क्ति" एक स्ट्रिङ हो। त्यो हो, पहुँच वितरण, पङ्क्ति वितरण।

अर्को मुद्दा जुन पोस्टग्रेसमा बुझ्न आवश्यक छ, जुन मैले दुर्भाग्यवश मेरो भाषणमा कभर गर्न सक्दिन, MVCC हो। मेरो वेबसाइटमा यस विषयमा छुट्टै प्रस्तुति छ। र यदि तपाईंलाई यो प्रस्तुति कठिन छ भन्ने लाग्छ भने, MVCC सायद मेरो सबैभन्दा कठिन छ। र यदि तपाइँ इच्छुक हुनुहुन्छ भने, तपाइँ यसलाई वेबसाइटमा हेर्न सक्नुहुन्छ। भिडियो हेर्न सक्नुहुन्छ।

हामीले बुझ्नु पर्ने अर्को कुरा लेनदेन आईडीहरू हो। धेरै लेनदेनहरू अद्वितीय पहिचानकर्ताहरू बिना काम गर्न सक्दैनन्। र यहाँ हामी लेनदेन के हो भनेर व्याख्या छ। Postgres मा दुई लेनदेन नम्बरिङ प्रणाली छ। मलाई थाहा छ यो धेरै सुन्दर समाधान होइन।

यो पनि ध्यानमा राख्नुहोस् कि स्लाइडहरू बुझ्न धेरै गाह्रो हुनेछ, त्यसैले रातोमा हाइलाइट गरिएको के हो तपाईंले ध्यान दिन आवश्यक छ।

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

हेरौं। लेनदेन नम्बर रातो रंगमा हाइलाइट गरिएको छ। SELECT pg_back प्रकार्य यहाँ देखाइएको छ। यसले मेरो लेनदेन र लेनदेन आईडी फिर्ता गर्छ।

अर्को कुरा, यदि तपाईंलाई यो प्रस्तुति मनपर्छ र यसलाई आफ्नो डाटाबेसमा चलाउन चाहनुहुन्छ भने, तपाईं गुलाबी रंगको यो लिङ्कमा गएर यस प्रस्तुतीकरणको लागि SQL डाउनलोड गर्न सक्नुहुन्छ। र तपाइँ यसलाई तपाइँको PSQL मा मात्र चलाउन सक्नुहुन्छ र सम्पूर्ण प्रस्तुति तपाइँको स्क्रिनमा तुरुन्तै हुनेछ। यसले फूलहरू समावेश गर्दैन, तर कम्तिमा हामी यसलाई देख्न सक्छौं।

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

र हामीले यो बुझ्नुपर्छ। यो धेरै महत्त्वपूर्ण छ, अन्यथा हामी Postgres मा लक बुझ्न सक्षम हुनेछैनौं।

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

र यसले Postgres कार्यसम्पादन सुधार गर्दछ, सफा गर्ने क्षमताहरू सुधार गर्दछ, त्यसैले भर्चुअल लेनदेन ID मा दुई नम्बरहरू हुन्छन्। स्ल्याश अघि पहिलो नम्बर ब्याकएन्ड आईडी हो। र दायाँमा हामी केवल एक काउन्टर देख्छौं।

त्यसकारण, यदि मैले अनुरोध चलाउँछु भने, यसले ब्याकएन्ड आईडी २ हो भनेर भन्छ।

र यदि मैले त्यस्ता लेनदेनको शृङ्खला चलाउँछु भने, हामीले प्रत्येक पटक क्वेरी चलाउँदा काउन्टर बढेको देख्छौं। उदाहरण को लागी, जब म क्वेरी 2/10, 2/11, 2/12, आदि चलाउँछु।

ध्यान राख्नुहोस् कि यहाँ दुईवटा स्तम्भहरू छन्। बाँयामा हामी भर्चुअल लेनदेन आईडी देख्छौं - 2/12। र दायाँमा हामीसँग स्थायी लेनदेन आईडी छ। र यो क्षेत्र खाली छ। र यो लेनदेन डाटाबेस परिमार्जन गर्दैन। त्यसैले म यसलाई स्थायी लेनदेन आईडी दिन्न।

मैले विश्लेषण आदेश ((ANALYZE)) चलाउने बित्तिकै, उही प्रश्नले मलाई स्थायी लेनदेन ID दिन्छ। हेर्नुहोस् यो हाम्रो लागि कस्तो परिवर्तन भएको छ। मसँग यो आईडी पहिले थिएन, तर अहिले मसँग छ।

त्यसैले यहाँ अर्को अनुरोध छ, अर्को लेनदेन। भर्चुअल लेनदेन नम्बर 2/13 हो। र यदि मैले लगातार लेनदेन आईडीको लागि सोधें भने, जब मैले क्वेरी चलाउँछु, म यो प्राप्त गर्नेछु।

त्यसैले, एक पटक। हामीसँग भर्चुअल लेनदेन आईडी र निरन्तर लेनदेन आईडी छ। Postgres व्यवहार बुझ्न यो बिन्दु बुझ्नुहोस्।

हामी तेस्रो खण्डमा जान्छौं। यहाँ हामी Postgres मा विभिन्न प्रकारका लकहरू मार्फत हिंड्नेछौं। यो धेरै रोचक छैन। अन्तिम खण्ड धेरै रोचक हुनेछ। तर हामीले आधारभूत कुराहरू विचार गर्नुपर्छ, किनभने अन्यथा हामी बुझ्न सक्दैनौं कि अब के हुन्छ।

हामी यो खण्ड मार्फत जानेछौं, हामी प्रत्येक प्रकारको लक हेर्नेछौं। र म तपाईंलाई तिनीहरू कसरी स्थापना गरिन्छन्, तिनीहरूले कसरी काम गर्छन् भन्ने उदाहरणहरू देखाउनेछु, म तपाईंलाई केही प्रश्नहरू देखाउनेछु जुन तपाईं पोष्टग्रेसमा लक कसरी काम गर्दछ भनेर हेर्न प्रयोग गर्न सक्नुहुन्छ।

क्वेरी सिर्जना गर्न र पोस्टग्रेसमा के भइरहेको छ भनेर हेर्न, हामीले प्रणाली दृश्यमा क्वेरी जारी गर्न आवश्यक छ। यस अवस्थामा, pg_lock रातोमा हाइलाइट गरिएको छ। Pg_lock एउटा प्रणाली तालिका हो जसले हामीलाई Postgres मा हाल प्रयोगमा रहेका लकहरू बताउँछ।

जे होस्, यो धेरै जटिल छ किनभने यो आफैले pg_lock देखाउन मलाई धेरै गाह्रो छ। त्यसैले मैले pg_locks देखाउने दृश्य सिर्जना गरें। र यसले मेरो लागि केहि काम गर्दछ जसले मलाई अझ राम्रोसँग बुझ्न अनुमति दिन्छ। त्यो हो, यसले मेरो लकहरू, मेरो आफ्नै सत्र, आदि समावेश गर्दछ। यो केवल मानक SQL हो र यसले तपाईंलाई के भइरहेको छ भनेर अझ राम्रो देखाउन अनुमति दिन्छ।

अर्को समस्या यो छ कि यो दृश्य धेरै फराकिलो छ, त्यसैले मैले दोस्रो - lockview2 सिर्जना गर्नुपर्छ।

र यसले मलाई तालिकाबाट थप स्तम्भहरू देखाउँछ। र अर्को एउटा जसले मलाई बाँकी स्तम्भहरू देखाउँछ। यो धेरै जटिल छ, त्यसैले मैले यसलाई सकेसम्म सरल रूपमा प्रस्तुत गर्ने प्रयास गरेको छु।

त्यसैले हामीले लकडेमो नामक तालिका सिर्जना गर्यौं। र हामीले त्यहाँ एउटा लाइन बनायौं। यो हाम्रो नमूना तालिका हो। र हामी तपाईलाई तालाका उदाहरणहरू देखाउनको लागि खण्डहरू सिर्जना गर्नेछौं।

त्यसैले, एक पङ्क्ति, एक स्तम्भ। पहिलो प्रकारको लकलाई ACCESS SHARE भनिन्छ। यो सबैभन्दा कम प्रतिबन्धित अवरुद्ध हो। यसको मतलब यो व्यावहारिक रूपमा अन्य तालाहरूसँग विवाद गर्दैन।

र यदि हामी स्पष्ट रूपमा लक परिभाषित गर्न चाहन्छौं भने, हामी "लक टेबल" आदेश चलाउँछौं। र यो स्पष्ट रूपमा अवरुद्ध हुनेछ, अर्थात् ACCESS SHARE मोडमा हामी लक तालिका सुरु गर्छौं। र यदि मैले पृष्ठभूमिमा PSQL चलाउँछु भने, म मेरो पहिलो सत्रबाट यसरी दोस्रो सत्र सुरु गर्छु। त्यो हो, म यहाँ के गर्छु? म अर्को सत्रमा जान्छु र यसलाई भन्छु "मलाई यो अनुरोधको लागि लकभ्यू देखाउनुहोस्।" र यहाँ मसँग यस तालिकामा AccessShareLock छ। यो ठ्याक्कै मैले अनुरोध गरेको हो। र ब्लक तोकिएको उनको भनाइ छ । एकदम सजिलो।

यसबाहेक, यदि हामी दोस्रो स्तम्भमा हेर्छौं, त्यहाँ केहि छैन। तिनीहरू खाली छन्।

र यदि मैले "SELECT" आदेश चलाउँछु, तब यो AccessShareLock अनुरोध गर्ने निहित (स्पष्ट) तरिका हो। त्यसैले म मेरो तालिका रिलिज गर्छु र क्वेरी चलाउँछु र क्वेरीले धेरै पङ्क्तिहरू फर्काउँछ। र लाइनहरु मध्ये एक मा हामी AccessShareLock देख्छौं। यसरी, SELECT ले AccessShareLock लाई टेबलमा कल गर्दछ। र यो लगभग केहि संग विवाद गर्दैन किनभने यो एक निम्न-स्तर लक हो।

के हुन्छ यदि मैले SELECT चलाउँछु र तीनवटा फरक तालिकाहरू छन् भने? पहिले म केवल एउटा तालिका चलाउँदै थिएँ, अब म तीन चलिरहेको छु: pg_class, pg_namespace र pg_attribute।

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

र यो एक ताला हो जुन व्यावहारिक रूपमा अरूसँग विवाद गर्दैन। र यसले गर्दा मात्र हामीले यसलाई चयन गर्दा तालिका रिसेट गर्नबाट रोक्छ। यसले अर्थ राख्छ। त्यो हो, यदि हामीले तालिका चयन गर्छौं, त्यो क्षणमा गायब हुन्छ, तब यो गलत हो, त्यसैले AccessShare एउटा निम्न स्तरको लक हो जसले हामीलाई "म काम गरिरहेको बेला यो तालिका नछाड्नुहोस्" भनी बताउँछ।। मूलतः, उनले यति मात्र गर्छिन्।

ROW SHARE - यो लक अलि फरक छ।

एउटा उदाहरण लिऔं। प्रत्येक पङ्क्तिलाई व्यक्तिगत रूपमा लक गर्ने ROW SHARE विधि चयन गर्नुहोस्। यस तरिकाले कसैले तिनीहरूलाई मेटाउन वा परिवर्तन गर्न सक्दैन जब हामी तिनीहरूलाई हेरिरहेका छौं।

त्यसोभए SHARE LOCK ले के गर्छ? हामीले देख्यौं कि लेनदेन ID SELECT को लागि 681 हो। र यो रोचक छ। यहाँ के भयाे? पहिलो पटक हामीले नम्बर "लक" फिल्डमा देख्छौं। हामी लेनदेन ID लिन्छौं र यसले यसलाई विशेष मोडमा रोकिरहेको छ भन्छ। यो केवल यो गर्छ कि मसँग एउटा पङ्क्ति छ जुन प्राविधिक रूपमा तालिकामा कतै लक गरिएको छ। तर उनले ठ्याक्कै कहाँ भनेका छैनन् । हामी यसलाई थप विस्तारमा केहि पछि हेर्नेछौं।

यहाँ हामी भन्छौं कि ताला हामी द्वारा प्रयोग गरिन्छ।

त्यसोभए, एक विशेष तालाले स्पष्ट रूपमा भन्छ कि यो अनन्य छ। र यदि तपाईंले यो तालिकामा पङ्क्ति मेटाउनुभयो भने, त्यसपछि यो के हुनेछ, तपाईंले देख्न सक्नुहुन्छ।

SHARE EXCLUSIVE लामो लक हो।

यो (ANALYZE) विश्लेषक आदेश हो जुन प्रयोग गरिनेछ।

SHARE LOCK - तपाईं स्पष्ट रूपमा साझा मोडमा लक गर्न सक्नुहुन्छ।

तपाईं एक अद्वितीय अनुक्रमणिका पनि सिर्जना गर्न सक्नुहुन्छ। र त्यहाँ तपाईंले SHARE LOCK देख्न सक्नुहुन्छ, जुन तिनीहरूको अंश हो। र यसले टेबल लक गर्छ र यसमा SHARE LOCK राख्छ।

पूर्वनिर्धारित रूपमा, टेबलमा SHARE LOCK को अर्थ अरू मानिसहरूले तालिका पढ्न सक्छन्, तर कसैले यसलाई परिमार्जन गर्न सक्दैन। र यो वास्तवमा के हुन्छ जब तपाइँ एक अद्वितीय अनुक्रमणिका सिर्जना गर्नुहुन्छ।

यदि मैले एक अद्वितीय समवर्ती अनुक्रमणिका सिर्जना गर्छु भने, मसँग फरक प्रकारको लक हुनेछ किनभने, तपाईलाई सम्झना अनुसार, समवर्ती अनुक्रमणिकाहरू प्रयोग गर्नाले लकिङ आवश्यकता घटाउँछ। र यदि म एक सामान्य लक, एक सामान्य अनुक्रमणिका प्रयोग गर्छु, तब म टेबल अनुक्रमणिकामा लेख्न रोक्छु जब यो सिर्जना भइरहेको छ। यदि मैले समवर्ती अनुक्रमणिका प्रयोग गर्छु भने, मैले फरक प्रकारको लक प्रयोग गर्न आवश्यक छ।

SHARE ROW EXCLUSIVE - फेरि यो स्पष्ट रूपमा (स्पष्ट रूपमा) सेट गर्न सकिन्छ।

वा हामी एक नियम सिर्जना गर्न सक्छौं, अर्थात्, एक विशेष केस लिनुहोस् जसमा यो प्रयोग गरिनेछ।

EXCLUSIVE लकिङ भनेको अरू कसैले टेबल परिवर्तन गर्न सक्दैन।

यहाँ हामी विभिन्न प्रकारका तालाहरू देख्छौं।

EXCESS EXCLUSIVE, उदाहरणका लागि, अवरुद्ध आदेश हो। उदाहरणका लागि, यदि तपाइँ गर्नुहुन्छ भने CLUSTER table, तब यसको अर्थ त्यहाँ कोही पनि लेख्न सक्नेछैन। र यसले केवल तालिका मात्र होइन, तर अनुक्रमणिकाहरू पनि लक गर्दछ।

यो EXCESS EXCLUSIVE ब्लकिङको दोस्रो पृष्ठ हो, जहाँ हामी टेबलमा के ब्लक गर्छ भन्ने कुरा देख्छौं। यसले व्यक्तिगत तालिका पङ्क्तिहरू लक गर्दछ, जुन धेरै रोचक छ।

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

र अब हामी केहि अवरुद्ध उदाहरणहरू मार्फत जानेछौं। यो सबैभन्दा रोचक भाग हो। हामी धेरै रोचक केसहरू हेर्नेछौं। र यस प्रस्तुतीकरणमा मेरो लक्ष्य भनेको तपाइँलाई पोस्टग्रेसले वास्तवमा के गरिरहेको छ भन्ने बारे अझ राम्रो बुझाइ दिनु हो जब यसले केहि चीजहरू ब्लक गर्ने प्रयास गर्दछ। मलाई लाग्छ कि उहाँ भागहरू रोक्नमा धेरै राम्रो हुनुहुन्छ।

केही विशिष्ट उदाहरणहरू हेरौं।

हामी तालिकामा एक पङ्क्ति र तालिकाबाट सुरु गर्नेछौं। जब मैले केहि घुसाउँछु मसँग तालिकामा ExclusiveLock, Transaction ID र ExclusiveLock देखाइन्छ।

यदि मैले थप दुई पङ्क्तिहरू सम्मिलित गरे भने के हुन्छ? र अब हाम्रो तालिकामा तीन पङ्क्तिहरू छन्। र मैले एउटा पङ्क्ति सम्मिलित गरें र यसलाई आउटपुटको रूपमा पाएँ। र यदि मैले थप दुई पङ्क्तिहरू सम्मिलित गरें भने, यसको बारेमा के अनौठो छ? यहाँ एउटा अनौठो कुरा छ किनभने मैले यो तालिकामा तीन पङ्क्तिहरू थपेको छु, तर मसँग अझै पनि लक तालिकामा दुईवटा पङ्क्तिहरू छन्। र यो अनिवार्य रूपमा Postgres को मौलिक व्यवहार हो।

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

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

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

के हुन्छ यदि म दुई पङ्क्तिहरू अद्यावधिक गर्न चाहन्छु? र हामी देख्छौं कि उसले पनि त्यस्तै व्यवहार गर्छ। हामी दुई गुणा धेरै अपडेटहरू गर्छौं, तर लक लाइनहरूको ठ्याक्कै उही संख्या।

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

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

र, उदाहरणका लागि, म 1 लाइनहरू घुसाउन चाहन्छु, र त्यसपछि 000 लाइनहरू मेटाउन वा थप्न चाहन्छु, त्यसपछि ती व्यक्तिगत लाइनहरू जुन मैले थप्छु वा परिवर्तन गर्छु, ती यहाँ रेकर्ड गरिएका छैनन्। तिनीहरू श्रृंखला भित्र नै तल्लो तहमा लेखिएका छन्। र MVCC भाषणको क्रममा मैले यस बारे विस्तृत रूपमा कुरा गरें। तर यो धेरै महत्त्वपूर्ण छ जब तपाइँ तालिका स्तरमा लक गर्दै हुनुहुन्छ र तपाइँ यहाँ व्यक्तिगत पङ्क्तिहरू कसरी रेकर्ड भइरहेको छ भनेर देख्नुहुन्न भनेर सुनिश्चित गर्न लकहरूको विश्लेषण गर्दै हुनुहुन्छ।

स्पष्ट अवरुद्धको बारेमा के हो?

यदि मैले रिफ्रेस क्लिक गर्छु भने, मसँग दुई पङ्क्तिहरू बन्द छन्। र यदि मैले ती सबै छान्नुहोस् र "सबै ठाउँमा अद्यावधिक गर्नुहोस्" मा क्लिक गर्नुहोस्, तब मसँग अझै दुईवटा ब्लकिङ रेकर्डहरू छन्।

हामी प्रत्येक व्यक्तिगत पङ्क्तिको लागि छुट्टै रेकर्डहरू सिर्जना गर्दैनौं। किनभने त्यसपछि उत्पादकता घट्छ, त्यहाँ धेरै हुन सक्छ। र हामी आफैलाई एक अप्रिय स्थितिमा पाउन सक्छौं।

र एउटै कुरा, यदि हामीले साझा गर्यौं भने, हामी यो सबै 30 पटक गर्न सक्छौं।

हामी हाम्रो तालिका पुनर्स्थापित गर्छौं, सबै मेटाउँछौं, त्यसपछि फेरि एउटा पङ्क्ति घुसाउनुहोस्।

अर्को व्यवहार जुन तपाईले पोस्टग्रेसमा देख्नुहुन्छ जुन धेरै राम्रोसँग परिचित र इच्छित व्यवहार हो कि तपाईले अद्यावधिक वा चयन गर्न सक्नुहुन्छ। र तपाईं एकै समयमा यो गर्न सक्नुहुन्छ। र चयन गर्नुहोस् अपडेट ब्लक गर्दैन र उही कुरा विपरीत दिशामा। हामी पाठकलाई लेखकलाई ब्लक नगर्न भन्छौं, र लेखकले पाठकलाई रोकेनन्।

म तपाईंलाई यसको उदाहरण देखाउनेछु। म अब छनोट गर्छु। त्यसपछि हामी INSERT गर्नेछौं। र त्यसपछि तपाईले देख्न सक्नुहुन्छ - 694. तपाईले यो प्रविष्टि गरेको लेनदेनको आईडी देख्न सक्नुहुन्छ। र यो कसरी काम गर्दछ।

र यदि मैले अहिले मेरो ब्याकएन्ड आईडी हेर्छु, यो अब 695 छ।

र म मेरो तालिकामा 695 देखिने देख्न सक्छु।

र यदि म यहाँ यस्तै अपडेट गर्छु भने, त्यसपछि म फरक केस पाउँछु। यस अवस्थामा, 695 एक विशेष लक हो, र अद्यावधिकको समान व्यवहार छ, तर तिनीहरू बीच कुनै विवाद छैन, जुन एकदम असामान्य छ।

र तपाईले देख्न सक्नुहुन्छ कि शीर्षमा यो ShareLock छ, र तल यो ExclusiveLock छ। र दुबै लेनदेन काम गरे।

र यो कसरी हुन्छ भनेर बुझ्नको लागि तपाईंले MVCC मा मेरो कुराकानी सुन्नुपर्छ। तर यो एउटा दृष्टान्त हो कि तपाइँ यसलाई एकै समयमा गर्न सक्नुहुन्छ, अर्थात् एकै समयमा चयन गर्नुहोस् र अपडेट गर्नुहोस्।

रिसेट गरौं र अर्को अपरेशन गरौं।

यदि तपाईंले एउटै पङ्क्तिमा दुईवटा अद्यावधिकहरू एकैसाथ चलाउने प्रयास गर्नुभयो भने, यो अवरुद्ध हुनेछ। र याद गर्नुहोस्, मैले भनेको थिएँ कि पाठकले लेखकलाई रोक्दैन, र लेखकले पाठकलाई रोक्दैन, तर एक लेखकले अर्को लेखकलाई रोक्छ। त्यो हो, हामीसँग एकै समयमा दुई व्यक्तिले एउटै पङ्क्ति अपडेट गर्न सक्दैन। तपाईंले ती मध्ये एक समाप्त नभएसम्म पर्खनु पर्छ।

र यो चित्रण गर्न को लागी, म Lockdemo तालिका हेर्नेछु। र हामी एक पङ्क्ति हेर्नेछौं। प्रति लेनदेन 698।

हामीले यसलाई २ मा अपडेट गरेका छौं। 2 पहिलो अपडेट हो। र यो सफल भयो वा यो पेन्डिङ लेनदेनमा छ र हामीलाई पुष्टि गर्न वा रद्द गर्न पर्खिरहेको छ।

तर अरू केहि हेर्नुहोस् - 2/51 हाम्रो पहिलो लेनदेन हो, हाम्रो पहिलो सत्र। 3/112 दोस्रो अनुरोध हो जुन माथिबाट आएको हो जसले त्यो मानलाई 3 मा परिवर्तन गर्यो। र यदि तपाईंले याद गर्नुभयो भने, माथिल्लो एकले आफै लक गर्यो, जुन 699 हो। तर 3/112 ले लक प्रदान गरेन। लक_मोड स्तम्भले यो के पर्खिरहेको छ भन्छ। यसले 699 को अपेक्षा गर्दछ। र यदि तपाईंले 699 कहाँ छ भनेर हेर्नुभयो भने, यो उच्च छ। र पहिलो सत्रले के गर्यो? उनले आफ्नै लेनदेन आईडीमा एक विशेष लक सिर्जना गरे। Postgres ले यो कसरी गर्छ। यसले आफ्नै लेनदेन आईडी ब्लक गर्दछ। र यदि तपाइँ कसैलाई पुष्टि वा रद्द गर्न पर्खन चाहनुहुन्छ भने, तपाइँले त्यहाँ पेन्डिङ लेनदेन हुँदा पर्खनु पर्छ। र यसैले हामी एक अनौठो रेखा देख्न सक्छौं।

फेरि हेरौं। बाँयामा हामी हाम्रो प्रशोधन आईडी देख्छौं। दोस्रो स्तम्भमा हामी हाम्रो भर्चुअल लेनदेन ID देख्छौं, र तेस्रोमा हामी lock_type देख्छौं। यसको मतलब के हो? अनिवार्य रूपमा यसले के भन्छ कि यसले लेनदेन ID ब्लक गरिरहेको छ। तर ध्यान दिनुहोस् कि तलका सबै पङ्क्तिहरूले सम्बन्ध भन्छन्। र त्यसैले तपाईंसँग टेबलमा दुई प्रकारका तालाहरू छन्। सम्बन्ध ताल्चा छ। र त्यसपछि त्यहाँ transactionid अवरुद्ध छ, जहाँ तपाइँ आफैले ब्लक गर्नुहुन्छ, जुन पहिलो पङ्क्तिमा वा धेरै तलमा हुन्छ, जहाँ transactionid हुन्छ, जहाँ हामी यसको सञ्चालन समाप्त गर्न 699 को प्रतीक्षा गर्छौं।

म यहाँ के हुन्छ हेर्छु। र यहाँ दुई कुरा एकैसाथ हुन्छ। तपाइँ पहिलो पङ्क्तिमा एक लेनदेन आईडी लक हेर्दै हुनुहुन्छ जुन आफै लक हुन्छ। र मानिसहरूलाई पर्खन उनी आफैंलाई रोक्छिन्।

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

र lock_type मा, तपाईंले संख्याहरू देख्नुहुन्छ।

तपाईंले यो 0/10 देख्न सक्नुहुन्छ। र यो पृष्ठ नम्बर हो, र यो विशेष पङ्क्तिको अफसेट पनि।

र तपाईले देख्नुहुन्छ कि यो ०/११ हुन्छ जब हामी अपडेट गर्छौं।

तर वास्तवमा यो 0/10 हो, किनभने यो अपरेशनको लागि पर्खाइ छ। हामीसँग यो शृङ्खला हो जुन म पुष्टि गर्न पर्खिरहेको छु भनेर हेर्ने अवसर छ।

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

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

यो पुनरावर्ती दृश्य हो जसको अर्को खण्ड पनि छ। र त्यसपछि सबै कुरा फेरि सँगै ल्याउँछ। यसलाई प्रयोग गरौं।

के हुन्छ यदि हामीले एकैसाथ तीनवटा अपडेटहरू गर्छौं र पङ्क्ति अब तीन छ भनौं भने। र हामी 3 देखि 4 परिवर्तन गर्नेछौं।

र यहाँ हामी 4. र लेनदेन आईडी 702 देख्छौं।

र त्यसपछि म 4 देखि 5 मा परिवर्तन गर्नेछु। र 5 देखि 6, र 6 देखि 7। र म यो एक लेनदेन समाप्त हुनको लागि पर्खिरहेका धेरै मानिसहरूलाई लाइन बनाउनेछु।

र सबै कुरा स्पष्ट हुन्छ। पहिलो पङ्क्ति के हो? यो ७०२ हो। यो लेनदेन ID हो जसले मूल रूपमा यो मान सेट गर्छ। मेरो ग्रान्टेड स्तम्भमा के लेखिएको छ? मसँग अंक छ f। यी मेरा अपडेटहरू हुन् जुन (5, 6, 7) अनुमोदन गर्न सकिँदैन किनभने हामी लेनदेन ID 702 समाप्त हुनको लागि पर्खिरहेका छौं। त्यहाँ हामीसँग लेनदेन आईडी ब्लक छ। र यसले 5 लेनदेन आईडी लकहरूमा परिणाम दिन्छ।

र यदि तपाईंले 704, 705 मा हेर्नुभयो भने, त्यहाँ अझै केही लेखिएको छैन, किनभने उनीहरूलाई थाहा छैन के भइरहेको छ। तिनीहरूले के भइरहेको छ भनेर उनीहरूलाई थाहा छैन भनेर मात्र लेख्छन्। र तिनीहरू केवल सुत्न जान्छन् किनभने तिनीहरू कसैको अन्त्यको लागि पर्खिरहेका हुन्छन् र पङ्क्तिहरू परिवर्तन गर्ने अवसर हुँदा ब्यूँझिन्छन्।

यो जस्तो देखिन्छ। यो स्पष्ट छ कि तिनीहरू सबै 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 को लागि पर्खिरहेको छ। र यो राम्रोसँग समाप्त हुनेछैन। र यसबाट बाहिर जाने कुनै उपाय छैन। र तिनीहरूले एक अर्काबाट प्रतिक्रियाको अपेक्षा गर्नेछन्।

र यो केवल सबै ढिलाइ सुरु हुनेछ। र हामी त्यो चाहँदैनौं।

र Postgres सँग ध्यान दिने तरिकाहरू छन् जब यो हुन्छ। र जब यो हुन्छ, तपाईंले यो त्रुटि पाउनुहुन्छ। र यसबाट यो स्पष्ट हुन्छ कि यस्तो र यस्तो प्रक्रिया अर्को प्रक्रियाबाट SHARE LOCK को लागि पर्खिरहेको छ, अर्थात्, जुन 711 प्रक्रिया द्वारा अवरुद्ध छ। र त्यो प्रक्रिया यस्तो र यस्तो लेनदेन ID मा एक SHARE lock को लागी पर्खिरहेको थियो र यस्तो र यस्तो प्रक्रिया द्वारा ब्लक गरिएको थियो। त्यसैले यहाँ ठप्पको अवस्था छ ।

के त्यहाँ तीन-तर्फी गतिरोधहरू छन्? के यो सम्भव छ? हो।

हामी यी संख्याहरू तालिकामा प्रविष्ट गर्छौं। हामी 40 मा 40 परिवर्तन गर्छौं, हामी ब्लक गर्छौं।

हामी 60 मा 61, 80 मा 81 परिवर्तन गर्छौं।

र त्यसपछि हामी 80 परिवर्तन गर्छौं र त्यसपछि बूम!

र 714 अब 715 को लागि पर्खिरहेको छ। 716 औं 715 को लागि पर्खिरहेको छ। र यसको बारेमा केहि गर्न सकिँदैन।

यहाँ अब दुई जना छैनन्, यहाँ पहिले नै तीन जना छन्। म तिमीबाट केहि चाहन्छु, यो तेस्रो व्यक्तिबाट केहि चाहन्छ, र तेस्रो व्यक्ति मबाट केहि चाहन्छ। र हामी तीन-तरिका पर्खाइमा समाप्त हुन्छौं किनभने हामी सबै अर्को व्यक्तिलाई उनीहरूले के गर्न आवश्यक छ पूरा गर्न पर्खिरहेका छौं।

र Postgres लाई थाहा छ कुन पङ्क्तिमा यो हुन्छ। र त्यसोभए यसले तपाइँलाई निम्न सन्देश दिनेछ, जसले तपाइँलाई समस्या छ जहाँ तीन इनपुटहरू एकअर्कालाई रोकिरहेका छन् भनेर देखाउँदछ। र यहाँ कुनै प्रतिबन्धहरू छैनन्। यो मामला हुन सक्छ जहाँ 20 प्रविष्टिहरू एकअर्कालाई रोक्छन्।

अर्को समस्या क्रमबद्ध छ।

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

र हामी 719 मा फर्कन्छौं। यसको आउटपुट एकदम सामान्य छ।

र तपाईं क्रमबद्ध बाट लेनदेन बनाउन क्लिक गर्न सक्नुहुन्छ।

र तपाईले महसुस गर्नुभयो कि तपाईसँग अब फरक प्रकारको SA लक छ - यसको मतलब क्रमबद्ध गर्न सकिन्छ।

र त्यसैले हामीसँग SARieadLock भनिने नयाँ प्रकारको लक छ, जुन सिरियल लक हो र तपाइँलाई सिरियलहरू प्रविष्ट गर्न अनुमति दिन्छ।

र पनि तपाईं अद्वितीय अनुक्रमणिका सम्मिलित गर्न सक्नुहुन्छ।

यस तालिकामा हामीसँग अद्वितीय अनुक्रमणिकाहरू छन्।

त्यसोभए यदि मैले यहाँ नम्बर 2 मा राखें भने, त्यसोभए मसँग 2 छ। तर सबैभन्दा माथि, मैले अर्को 2 भित्र राख्छु। र तपाईंले देख्न सक्नुहुन्छ कि 721 मा एक विशेष लक छ। तर अब 722 ले 721 लाई यसको अपरेशन पूरा गर्नको लागि पर्खिरहेको छ किनभने यसले 2 सम्मिलित गर्न सक्दैन जबसम्म यो थाहा हुँदैन कि 721 लाई के हुन्छ।

र यदि हामी सबलेनजेक्शन गर्छौं।

यहाँ हामीसँग 723 छ।

र यदि हामीले पोइन्ट बचत गर्छौं र यसलाई अपडेट गर्छौं भने, हामी नयाँ लेनदेन आईडी पाउँछौं। यो व्यवहारको अर्को ढाँचा हो जुन तपाईलाई सचेत हुन आवश्यक छ। यदि हामीले यो फिर्ता गर्यौं भने, लेनदेन ID हट्छ। 724 छुट्दै छ। तर अब हामीसँग 725 छ।

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

यो स्पष्ट (स्पष्ट) लकहरूको सिर्जना हो, जसमा pg_advisory_lock छ।

र तपाईंले देख्नुहुन्छ कि अवरुद्ध प्रकार सल्लाहकारको रूपमा सूचीबद्ध छ। र यहाँ यसले रातोमा "सल्लाहकार" भन्छ। र तपाइँ pg_advisory_unlock को साथ यो जस्तै ब्लक गर्न सक्नुहुन्छ।

र अन्त्यमा, म तपाईलाई थप एक दिमाग उडाउने कुरा देखाउन चाहन्छु। म अर्को दृश्य सिर्जना गर्नेछु। तर म pg_stat_activity तालिकाको साथ pg_locks तालिकामा सामेल हुनेछु। र म किन यो गर्न चाहन्छु? किनभने यसले मलाई सबै हालका सत्रहरू हेर्न र हेर्न र तिनीहरूले कस्तो प्रकारको लकहरू पर्खिरहेका छन् भनेर हेर्न अनुमति दिनेछ। र यो धेरै चाखलाग्दो छ जब हामी लक तालिका र क्वेरी तालिका सँगै राख्छौं।

र यहाँ हामी pg_stat_view सिर्जना गर्छौं।

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

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

र यो धेरै उपयोगी हुन सक्छ। हामीले यसलाई 9.6 संस्करणमा मात्र थपेका छौं, त्यसैले यो सुविधा मात्र 5 वर्ष पुरानो हो, तर यो धेरै, धेरै उपयोगी छ। र यो दोस्रो अनुरोधमा पनि लागू हुन्छ। यसले ठ्याक्कै के देख्न आवश्यक छ भनेर देखाउँछ।

म तपाईसँग कुरा गर्न चाहन्थें। र मैले अपेक्षा गरे अनुसार, हामीले हाम्रो सबै समय प्रयोग गर्यौं किनभने त्यहाँ धेरै स्लाइडहरू थिए। र स्लाइडहरू डाउनलोडको लागि उपलब्ध छन्। म यहाँ भएकोमा धन्यवाद दिन चाहन्छु। म पक्का छु कि तपाईंले सम्मेलनको बाँकी भागको आनन्द लिनुहुनेछ, धेरै धेरै धन्यवाद!

प्रश्नहरू:

उदाहरणका लागि, यदि म पङ्क्तिहरू अद्यावधिक गर्ने प्रयास गर्दैछु, र दोस्रो सत्रले सम्पूर्ण तालिका मेटाउने प्रयास गरिरहेको छ। जहाँसम्म मैले बुझेको छु, त्यहाँ एक उद्देश्य लक जस्तै केहि हुनुपर्छ। Postgres मा यस्तो कुरा छ?

धेरै सुरुमा फर्कौं। तपाईंले याद गर्न सक्नुहुन्छ कि जब तपाइँ केहि गर्नुहुन्छ, उदाहरणका लागि जब तपाइँ SELECT गर्नुहुन्छ, हामी एक AccessShareLock जारी गर्छौं। र यसले टेबल छोड्नबाट रोक्छ। त्यसोभए, यदि तपाइँ, उदाहरणका लागि, तालिकामा पङ्क्ति अद्यावधिक गर्न वा पङ्क्ति मेटाउन चाहनुहुन्छ भने, त्यसपछि कसैले एकै समयमा सम्पूर्ण तालिका मेटाउन सक्दैन किनभने तपाईंले सम्पूर्ण तालिका र पङ्क्तिमा यो AccessShareLock समात्दै हुनुहुन्छ। र एकपटक तपाईंले गरिसकेपछि, तिनीहरूले यसलाई मेटाउन सक्छन्। तर जब तपाइँ त्यहाँ प्रत्यक्ष रूपमा केहि परिवर्तन गर्नुहुन्छ, तिनीहरूले यो गर्न सक्षम हुनेछैनन्।

फेरि गरौं। मेटाउने उदाहरणमा जाऔं। र तपाईले देख्नुहुन्छ कि कसरी सम्पूर्ण तालिका माथिको पङ्क्तिमा एक विशेष लक छ।

यो लक अनन्य जस्तो देखिनेछ, हैन?

हो, यो जस्तो देखिन्छ। म बुझ्छु तपाईं के कुरा गर्दै हुनुहुन्छ। तपाईले भन्नु भएको छ कि यदि मैले SELECT गरे भने मसँग ShareExclusive छ र त्यसपछि म यसलाई Row Exclusive बनाउँछु, के यसले समस्या हुन्छ? तर अचम्मको कुरा यो समस्या उत्पन्न गर्दैन। यसले लक डिग्री बढाएको जस्तो देखिन्छ, तर अनिवार्य रूपमा मसँग एउटा लक छ जसले मेटाउन रोक्छ। र अब, जब म यो लक थप शक्तिशाली बनाउँछु, यसले अझै पनि मेटाउन रोक्छ। त्यसैले म माथि जाँदैछु जस्तो छैन। त्यो हो, यो तल्लो स्तरमा हुँदा पनि हुनबाट रोक्छ, त्यसैले जब मैले यसको स्तर बढाउँछु, यसले अझै पनि तालिकालाई मेटाउनबाट रोक्छ।

म बुझ्छु तपाईं के कुरा गर्दै हुनुहुन्छ। यहाँ कुनै लक एस्केलेसन केस छैन, जहाँ तपाइँ एक बलियो परिचय दिनको लागि एउटा लक त्याग्न प्रयास गर्दै हुनुहुन्छ। यहाँ यसले बोर्डमा यो रोकथाम मात्र बढाउँछ, त्यसैले यसले कुनै द्वन्द्व उत्पन्न गर्दैन। तर यो राम्रो प्रश्न हो। यो सोध्नु भएकोमा धेरै धेरै धन्यवाद!

हामीसँग धेरै सत्रहरू हुँदा, धेरै प्रयोगकर्ताहरू हुँदा एक गतिरोध अवस्थाबाट बच्न हामीले के गर्नुपर्छ?

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

तपाईको प्रदर्शनको लागि धेरै धेरै धन्यवाद! तपाईंले भ्याकुम फुलको बारेमा कुरा गर्नुभयो र, यदि मैले सही रूपमा बुझें भने, भ्याकुम फुलले फरक भण्डारणमा रेकर्डहरूको क्रमलाई विकृत गर्दछ, त्यसैले तिनीहरूले हालको रेकर्डहरू अपरिवर्तित राख्छन्। किन भ्याकुम फुलले अनन्य लक पहुँच लिन्छ र किन यो लेखन कार्यहरूसँग बाधा पुर्‍याउँछ?

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

Postgres मा लक टाइमआउट थप्न सम्भव छ? Oracle मा, म, उदाहरणका लागि, "अद्यावधिक गर्न चयन गर्नुहोस्" लेख्न सक्छु र अद्यावधिक गर्नु अघि 50 सेकेन्ड पर्खनुहोस्। यो आवेदन को लागी राम्रो थियो। तर Postgres मा, मैले कि त यसलाई तुरुन्तै गर्नु पर्छ र पर्खनु पर्दैन, वा केहि समय सम्म पर्खनुहोस्।

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

के तपाइँ स्लाइड 75 खोल्न सक्नुहुन्छ?

हो।

र मेरो प्रश्न निम्न छ। किन दुबै अद्यावधिक प्रक्रियाहरू 703 को अपेक्षा गर्दै छन्?

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

मलाई थाहा छैन किन Postgres ले यो गर्छ। तर त्यहाँ f भनिने समस्या छ। यो मलाई लाग्छ कि यो रूसी मा एक शब्द होइन। यो तब हुन्छ जब सबैजना एउटा महलको लागि पर्खिरहेका हुन्छन्, भले पनि त्यहाँ 20 अधिकारीहरू महलको लागि पर्खिरहेका छन्। र अचानक तिनीहरू सबै एकै समयमा उठ्छन्। र सबैले प्रतिक्रिया दिन प्रयास गर्न थाल्छन्। तर प्रणालीले यस्तो बनाउँछ कि सबैजना 703 को लागि पर्खिरहेका छन्। किनभने तिनीहरू सबै पर्खिरहेका छन्, र हामी तुरुन्तै ती सबैलाई लाइन गर्नेछौं। र यदि कुनै अन्य नयाँ अनुरोध देखा पर्यो जुन यस पछि उत्पन्न भएको थियो, उदाहरणका लागि, 707, त्यसपछि त्यहाँ फेरि खालीपन हुनेछ।

र यो मलाई लाग्छ कि यो यस चरणमा 702 703 को लागि पर्खिरहेको छ भनेर भन्न सक्छौं, र त्यसपछि आउने सबैलाई यस क्षेत्रमा कुनै प्रवेश हुनेछैन। तर पहिलो वेटर छोड्ने बित्तिकै, अपडेट हुनु अघि त्यो क्षणमा पर्खिरहेका सबैले समान टोकन प्राप्त गर्छन्। र त्यसैले मलाई लाग्छ कि यो गरिएको छ ताकि हामी क्रममा प्रक्रिया गर्न सक्छौं ताकि तिनीहरू ठीकसँग अर्डर गरिएका छन्।

मैले यसलाई सधैं एक अनौठो घटनाको रूपमा हेर्छु। किनकि यहाँ, उदाहरणका लागि, हामी तिनीहरूलाई सूचीबद्ध गर्दैनौं। तर मलाई लाग्छ कि हरेक चोटि हामी नयाँ ताला दिन्छौं, हामी पर्खने प्रक्रियामा रहेका सबैलाई हेर्छौं। त्यसपछि हामी ती सबैलाई पङ्क्तिबद्ध गर्छौं। र त्यसपछि आउने कुनै पनि नयाँ व्यक्तिले प्रशोधन गरिसकेपछि मात्र लाममा आउँछ। धेरै राम्रो प्रश्न। तपाईको प्रश्नको लागि धेरै धेरै धन्यवाद!

यो मलाई लाग्छ कि यो धेरै तार्किक छ जब 705 ले 704 को अपेक्षा गर्दछ।

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

र समस्या यो हो कि हामीसँग CP-infinity छ। र यसैले, यो धेरै सम्भव छ कि हामी पछि उठ्न सक्छौं। र यदि, उदाहरणका लागि, हामीले पछिको एकलाई ब्यूँझाउँछौं, हामी भर्खरै ब्लक प्राप्त गर्नेलाई पर्खनेछौं, त्यसैले हामी वास्तवमा कसलाई पहिले जगाउनेछ भनेर निर्धारण गर्दैनौं। हामी केवल यस्तो अवस्था सिर्जना गर्छौं, र प्रणालीले तिनीहरूलाई अनियमित क्रममा जगाउनेछ।

छन् Egor Rogov द्वारा ताला बारे लेख। हेर्नुहोस्, तिनीहरू पनि रोचक र उपयोगी छन्। विषय, निस्सन्देह, भयानक जटिल छ। धेरै धेरै धन्यवाद, ब्रुस!

स्रोत: www.habr.com