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

आज हम देखते हैं कि पंक्ति संस्करणों से डेटा के लगातार संस्करण कैसे प्राप्त किए जाते हैं।

डेटा स्नैपशॉट क्या है

शारीरिक रूप से, डेटा पृष्ठों में एक ही पंक्ति के कई संस्करण हो सकते हैं। इसके अलावा, प्रत्येक लेन-देन को प्रत्येक पंक्ति का केवल एक (या कोई भी) संस्करण नहीं देखना चाहिए, ताकि वे एक निश्चित समय पर डेटा के ACID- संगत चित्र का निर्माण करें।

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

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



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

स्नैपशॉट में पंक्ति संस्करणों की दृश्यता

दृश्यता नियम

बेशक, एक स्नैपशॉट सभी आवश्यक पंक्ति संस्करणों की भौतिक प्रतिलिपि नहीं है। वास्तव में, एक स्नैपशॉट कई संख्याओं द्वारा निर्दिष्ट किया जाता है, और स्नैपशॉट में पंक्ति संस्करणों की दृश्यता नियमों द्वारा निर्धारित की जाती है।

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

दृश्यता के सटीक नियम काफी जटिल हैं और कई अलग-अलग स्थितियों और चरम मामलों को ध्यान में रखते हैं।

इसे आसानी से src / backend / utils / time / tqual.c (संस्करण 12 में, चेक src / backend / access / heap / heapam_visibility.c पर ले जाया गया) को देखकर सत्यापित किया जा सकता है।

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

बदले में, स्नैपशॉट में लेनदेन परिवर्तन दिखाई देते हैं, यदि या तो यह वही लेनदेन है जिसने स्नैपशॉट बनाया है (वह अपने स्वयं के परिवर्तन देखता है), या स्नैपशॉट बनाने से पहले लेन-देन प्रतिबद्ध था।

यह संभव है कि लेन-देन को सेगमेंट के रूप में चित्रित किया जाए (शुरुआत से लेकर प्रतिबद्ध समय तक):



यहां:

• लेनदेन 2 में परिवर्तन दिखाई देगा क्योंकि यह स्नैपशॉट बनने से पहले पूरा हो गया था,
• लेन-देन में परिवर्तन 1 दिखाई नहीं देगा क्योंकि यह उस समय सक्रिय था जब स्नैपशॉट लिया गया था,
• लेन-देन 3 में परिवर्तन दिखाई नहीं देंगे क्योंकि यह स्नैपशॉट लेने के बाद शुरू हुआ (यह समाप्त हो गया या नहीं) इससे कोई फर्क नहीं पड़ता।

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

स्नैपशॉट बनाते समय हम सभी लेन-देन की वर्तमान स्थिति का पता लगा सकते हैं। यह जानकारी ProcArray संरचना में सर्वर की साझा मेमोरी में है, जिसमें सभी सक्रिय सत्रों और उनके लेनदेन की सूची है।

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

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

यह हास्यास्पद है कि शुरू में ऐसी कार्यक्षमता थी, लेकिन बाद में इसे डीबीएमएस से हटा दिया गया था। आप इसके बारे में जोसेफ हेलरस्टीन के एक लेख में पढ़ सकते हैं।

तो, एक डेटा स्नैपशॉट कई मापदंडों द्वारा निर्धारित किया जाता है:

• स्नैपशॉट बनाने का क्षण, अर्थात्, अगले लेनदेन की संख्या जो सिस्टम में मौजूद नहीं है ( स्नैपशॉट । xmax );
• स्नैपशॉट ( Snapshot.xip ) के समय सक्रिय लेनदेन की एक सूची।

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

इसके अलावा, कुछ और पैरामीटर चित्र में सहेजे गए हैं, लेकिन वे हमारे लिए महत्वपूर्ण नहीं हैं।

उदाहरण

स्नैपशॉट द्वारा दृश्यता कैसे निर्धारित की जाती है यह देखने के लिए, हम ऊपर चर्चा किए गए तीन लेनदेन के साथ स्थिति को पुन: पेश करते हैं। तालिका में तीन पंक्तियाँ होंगी:

• पहले एक स्नैपशॉट बनाने से पहले शुरू होने वाले लेनदेन द्वारा जोड़ा गया था, लेकिन बाद में समाप्त हो गया,
• दूसरा स्नैपशॉट बनने से पहले शुरू और समाप्त होने वाले लेनदेन द्वारा जोड़ा जाता है,
• तस्वीर लेने के बाद तीसरा जोड़ा गया।

=> TRUNCATE TABLE accounts; 

पहला लेनदेन (अभी पूरा नहीं हुआ):

 => BEGIN; => INSERT INTO accounts VALUES (1, '1001', 'alice', 1000.00); => SELECT txid_current(); 

 => SELECT txid_current(); txid_current -------------- 3695 (1 row) 

दूसरा लेन-देन (स्नैपशॉट बनने से पहले पूरा हुआ):

 | => BEGIN; | => INSERT INTO accounts VALUES (2, '2001', 'bob', 100.00); | => SELECT txid_current(); 

 | txid_current | -------------- | 3696 | (1 row) 

 | => COMMIT; 

दूसरे सत्र में लेनदेन में एक स्नैपशॉट बनाएँ।

 || => BEGIN ISOLATION LEVEL REPEATABLE READ; || => SELECT xmin, xmax, * FROM accounts; 

 || xmin | xmax | id | number | client | amount || ------+------+----+--------+--------+-------- || 3696 | 0 | 2 | 2001 | bob | 100.00 || (1 row) 

स्नैपशॉट बनने के बाद हम पहला लेनदेन पूरा करते हैं:

 => COMMIT; 

और तीसरा लेनदेन (बाद में स्नैपशॉट पर दिखाई दिया):

 | => BEGIN; | => INSERT INTO accounts VALUES (3, '2002', 'bob', 900.00); | => SELECT txid_current(); 

 | txid_current | -------------- | 3697 | (1 row) 

 | => COMMIT; 

जाहिर है, एक रेखा अभी भी हमारी छवि में दिखाई देती है:

 || => SELECT xmin, xmax, * FROM accounts; 

 || xmin | xmax | id | number | client | amount || ------+------+----+--------+--------+-------- || 3696 | 0 | 2 | 2001 | bob | 100.00 || (1 row) 

सवाल यह है कि PostgreSQL इसे कैसे समझता है।

सब कुछ तस्वीर से निर्धारित होता है। आइए इसे देखें:

 || => SELECT txid_current_snapshot(); 

 || txid_current_snapshot || ----------------------- || 3695:3697:3695 || (1 row) 

यहाँ, कॉलन स्नैपशॉट.xmin, Snapshot.xmax और Snapshot.xip को सूचीबद्ध करता है (इस मामले में, एक संख्या, लेकिन सामान्य तौर पर, एक सूची)।

ऊपर वर्णित नियमों के अनुसार, छवि को स्नैपशॉट.xip के अपवाद के साथ स्नैपशॉट.xmin <= xid <Snapshot.xmax के साथ लेनदेन द्वारा किए गए परिवर्तनों को दिखाना चाहिए। आइए तालिका की सभी पंक्तियों को देखें (एक नई तस्वीर में):

 => SELECT xmin, xmax, * FROM accounts ORDER BY id; 

  xmin | xmax | id | number | client | amount ------+------+----+--------+--------+--------- 3695 | 0 | 1 | 1001 | alice | 1000.00 3696 | 0 | 2 | 2001 | bob | 100.00 3697 | 0 | 3 | 2002 | bob | 900.00 (3 rows) 

पहली पंक्ति दिखाई नहीं दे रही है - यह एक लेनदेन द्वारा बनाई गई थी, जो सक्रिय (xip) की सूची में शामिल है।
दूसरी पंक्ति दिखाई देती है - यह एक लेनदेन द्वारा बनाई गई है जो छवि की सीमा के भीतर आती है।
तीसरी पंक्ति दिखाई नहीं दे रही है - यह एक लेनदेन द्वारा बनाई गई थी जो स्नैपशॉट की सीमा में नहीं है।

 || => COMMIT; 

खुद का बदलाव

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

ऐसा करने के लिए, पंक्ति संस्करण के हेडर में एक विशेष क्षेत्र है (जिसे छद्म कॉलम केमिन और सेमीमैक्स में प्रदर्शित किया गया है), लेनदेन के अंदर ऑपरेशन की अनुक्रम संख्या दिखा रहा है। Cmin डालने के लिए संख्या का प्रतिनिधित्व करता है, cmax हटाने के लिए संख्या का प्रतिनिधित्व करता है, लेकिन पंक्ति शीर्षलेख में स्थान बचाने के लिए, यह वास्तव में एक क्षेत्र है, दो अलग नहीं। ऐसा माना जाता है कि एक ही लेन-देन में एक ही पंक्ति को सम्मिलित करना और हटाना दुर्लभ है।

यदि यह अभी भी होता है, तो एक विशेष "कॉम्बो" नंबर उसी फ़ील्ड में डाला जाता है, जिसके बारे में सेवा की प्रक्रिया वास्तविक स्मरण और सेमीमैक्स को याद करती है। लेकिन यह पूरी तरह से विदेशी है।

एक सरल उदाहरण। हम लेन-देन शुरू करते हैं और तालिका में लाइन जोड़ते हैं:

 => BEGIN; => SELECT txid_current(); 

  txid_current -------------- 3698 (1 row) 

 INSERT INTO accounts(id, number, client, amount) VALUES (4, 3001, 'charlie', 100.00); 

हम कॉइन फ़ील्ड के साथ तालिका की सामग्री प्रदर्शित करेंगे (लेकिन केवल हमारे लेनदेन द्वारा जोड़ी गई पंक्तियों के लिए - दूसरों के लिए यह समझ में नहीं आता है):

 => SELECT xmin, CASE WHEN xmin = 3698 THEN cmin END cmin, * FROM accounts; 

  xmin | cmin | id | number | client | amount ------+------+----+--------+---------+--------- 3695 | | 1 | 1001 | alice | 1000.00 3696 | | 2 | 2001 | bob | 100.00 3697 | | 3 | 2002 | bob | 900.00 3698 | 0 | 4 | 3001 | charlie | 100.00 (4 rows) 

अब क्वेरी के लिए कर्सर खोलें जो तालिका में पंक्तियों की संख्या लौटाता है।

 => DECLARE c CURSOR FOR SELECT count(*) FROM accounts; 

और उसके बाद एक और पंक्ति जोड़ें:

 => INSERT INTO accounts(id, number, client, amount) VALUES (5, 3002, 'charlie', 200.00); 

अनुरोध 4 लौट आएगा - कर्सर खोले जाने के बाद जोड़ी गई रेखा डेटा स्नैपशॉट में नहीं आएगी:

 => FETCH c; 

  count ------- 4 (1 row) 

क्यों? क्योंकि स्नैपशॉट में केवल cmin <1 के साथ लाइन संस्करणों को ध्यान में रखा जाता है।

 => SELECT xmin, CASE WHEN xmin = 3698 THEN cmin END cmin, * FROM accounts; 

  xmin | cmin | id | number | client | amount ------+------+----+--------+---------+--------- 3695 | | 1 | 1001 | alice | 1000.00 3696 | | 2 | 2001 | bob | 100.00 3697 | | 3 | 2002 | bob | 900.00 3698 | 0 | 4 | 3001 | charlie | 100.00 3698 | 1 | 5 | 3002 | charlie | 200.00 (5 rows) 

 => ROLLBACK; 

घटना क्षितिज

जल्द से जल्द सक्रिय लेनदेन (स्नैपशॉट। एक्समिन) की संख्या का एक महत्वपूर्ण अर्थ है - यह लेनदेन के "घटना क्षितिज" को परिभाषित करता है। अर्थात्, अपने क्षितिज से परे, एक लेन-देन हमेशा वर्तमान संस्करणों की पंक्तियों को देखता है।

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



लेनदेन की "घटना क्षितिज" को सिस्टम निर्देशिका में देखा जा सकता है:

 => BEGIN; => SELECT backend_xmin FROM pg_stat_activity WHERE pid = pg_backend_pid(); 

  backend_xmin -------------- 3699 (1 row) 

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

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

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

यदि अब, लेन-देन नहीं, लेकिन स्नैपशॉट (स्नैपशॉट। xmin से स्नैपशॉट। xmax तक) को एक सेगमेंट के रूप में दर्शाया गया है, तो स्थिति की कल्पना निम्नानुसार की जा सकती है:



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

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

 | => BEGIN; | => UPDATE accounts SET amount = amount + 1.00; | => COMMIT; 

 => SELECT backend_xmin FROM pg_stat_activity WHERE pid = pg_backend_pid(); 

  backend_xmin -------------- 3699 (1 row) 

और केवल लेन-देन पूरा होने के बाद, क्षितिज आगे बढ़ता है, जिससे आप पंक्तियों के अप्रासंगिक संस्करणों को साफ कर सकते हैं:

 => COMMIT; => SELECT backend_xmin FROM pg_stat_activity WHERE pid = pg_backend_pid(); 

  backend_xmin -------------- 3700 (1 row) 

यदि वर्णित स्थिति वास्तव में समस्याएं पैदा करती है और आवेदन स्तर पर इससे बचने का कोई तरीका नहीं है, तो, संस्करण 9.6 के साथ शुरू होने पर, दो विकल्प उपलब्ध हैं:

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

डेटा स्नैपशॉट निर्यात करें

ऐसी स्थितियाँ हैं जब समान डेटा चित्र देखने के लिए कई समवर्ती लेनदेन की गारंटी दी जानी चाहिए। एक उदाहरण के रूप में, हम pg_dump उपयोगिता का उपयोग कर सकते हैं, जो समानांतर मोड में काम कर सकती है: सभी कार्यकर्ता प्रक्रियाओं को डेटाबेस को उसी स्थिति में देखना होगा ताकि बैकअप प्रतिलिपि सुसंगत हो।

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

Pg_export_snapshot फ़ंक्शन एक स्नैपशॉट के पहचानकर्ता को वापस करता है जिसे किसी अन्य लेनदेन के लिए (बाहरी साधनों द्वारा DBMS) स्थानांतरित किया जा सकता है।

 => BEGIN ISOLATION LEVEL REPEATABLE READ; => SELECT count(*) FROM accounts; --   

  count ------- 3 (1 row) 

 => SELECT pg_export_snapshot(); 

  pg_export_snapshot --------------------- 00000004-00000E7B-1 (1 row) 

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

 | => DELETE FROM accounts; | => BEGIN ISOLATION LEVEL REPEATABLE READ; | => SET TRANSACTION SNAPSHOT '00000004-00000E7B-1'; 

अब दूसरा लेनदेन पहले के स्नैपशॉट के साथ काम करेगा और, तदनुसार, तीन पंक्तियों को देखें (और शून्य नहीं):

 | => SELECT count(*) FROM accounts; 

 | count | ------- | 3 | (1 row) 

निर्यात किए गए स्नैपशॉट का जीवनकाल निर्यात लेनदेन का जीवनकाल है।

 | => COMMIT; => COMMIT; 

जारी रखा जाए ।