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

अब हम देखेंगे कि ट्यूपल्स से लगातार डेटा स्नैपशॉट कैसे प्राप्त किए जाते हैं।

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

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

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

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



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

एक स्नैपशॉट में tuples की दृश्यता

दृश्यता नियम

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

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

सटीक दृश्यता नियम बहुत जटिल हैं और विभिन्न मामलों और चरम सीमाओं को ध्यान में रखते हैं।

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

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

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

हम सेगमेंट द्वारा (शुरू समय से लेकर कम समय तक) लेनदेन का रेखांकन कर सकते हैं:



यहां:

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

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

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

लेकिन हम पोस्ट फैक्टम का पता लगाने में असमर्थ होंगे कि स्नैपशॉट के निर्माण के समय एक निश्चित लेनदेन सक्रिय था या नहीं। इसलिए, एक स्नैपशॉट को सभी वर्तमान सक्रिय लेनदेन की एक सूची संग्रहीत करनी होगी।

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

मज़ाकिया किस्म का यह है कि यह कार्यक्षमता पहले उपलब्ध थी, लेकिन फिर DBMS से हटा दी गई। आप इस बारे में जोसेफ एम। हेलरस्टीन के लेख में पढ़ सकते हैं।

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

• जिस समय स्नैपशॉट बनाया गया था, अधिक सटीक रूप से, अगले लेनदेन की आईडी, सिस्टम में अभी तक अनुपलब्ध ( snapshot.xmax । snapshot.xmax )।
• स्नैपशॉट बनाया गया था ( snapshot.xip ) इस समय सक्रिय (प्रगति में) लेनदेन की सूची।

सुविधा और अनुकूलन के लिए, शुरुआती सक्रिय लेनदेन की आईडी भी संग्रहीत है ( snapshot.xmin । snapshot.xmin )। यह मान एक महत्वपूर्ण अर्थ रखता है, जिस पर नीचे चर्चा की जाएगी।

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

उदाहरण

यह समझने के लिए कि स्नैपशॉट दृश्यता कैसे निर्धारित करता है, आइए उपरोक्त उदाहरण को तीन लेनदेन के साथ पुन: प्रस्तुत करें। तालिका में तीन पंक्तियाँ होंगी, जहाँ:

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

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

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

सभी स्नैपशॉट द्वारा निर्धारित किया जाता है। आइए इसे देखें:

 || => SELECT txid_current_snapshot(); 

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

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

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

 => 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 pseudo- cmin प्रतिनिधित्व किया गया है) है, जो लेनदेन के अंदर क्रम संख्या दिखाता है। सम्मिलन के लिए cmin संख्या है, और cmax - विलोपन के लिए, लेकिन टपल हेडर में स्थान बचाने के लिए, यह वास्तव में दो अलग-अलग लोगों के बजाय एक क्षेत्र है। यह माना जाता है कि एक लेन-देन समान रूप से सम्मिलित करता है और एक ही पंक्ति को हटाता है।

लेकिन अगर ऐसा होता है, तो एक विशेष कॉम्बो कमांड आईडी ( combocid ) उसी क्षेत्र में डाली जाती है, और बैकएंड प्रक्रिया इस combocid लिए वास्तविक cmin और cmax को याद combocid । लेकिन यह पूरी तरह से विदेशी है।

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

 => BEGIN; => SELECT txid_current(); 

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

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

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

 => 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 साथ 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; 

घटना क्षितिज

जल्द से जल्द सक्रिय लेनदेन ( snapshot.xmin ) की आईडी एक महत्वपूर्ण अर्थ बनाती है: यह लेनदेन के "घटना क्षितिज" को निर्धारित करती है। यही है, अपने क्षितिज से परे लेन-देन हमेशा अप-टू-डेट पंक्ति संस्करणों को देखता है।

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



आप सिस्टम कैटलॉग में लेनदेन क्षितिज देख सकते हैं:

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

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

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

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

और इसका मतलब यह है कि DB में मृत tuples को वैक्यूम नहीं किया जा सकता है। इसके अलावा, यह संभव है कि एक "लॉन्ग-प्ले" लेन-देन अन्य लेन-देन के साथ डेटा द्वारा प्रतिच्छेद नहीं करता है, लेकिन यह वास्तव में मायने नहीं रखता है क्योंकि सभी एक डेटाबेस क्षितिज साझा करते हैं।

यदि हम अब लेनदेन के बजाय स्नैपशॉट (स्नैपशॉट. snapshot.xmin से snapshot.xmin . snapshot.xmax ) का प्रतिनिधित्व करते हैं, तो हम स्थिति का अनुमान लगा सकते हैं:



इस आंकड़े में, सबसे कम स्नैपशॉट एक अपूर्ण लेनदेन से संबंधित है, और दूसरे स्नैपशॉट में स्नैपशॉट। snapshot.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) 

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

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

स्नैपशॉट निर्यात

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

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

pg_export_snapshot फ़ंक्शन स्नैपशॉट आईडी लौटाता है, जिसे किसी अन्य लेनदेन ( pg_export_snapshot बाहर टूल का उपयोग करके) को पास किया जा सकता है।

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

  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; 

पर पढ़ें ।