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

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

संबंध

यदि आप टेबल और इंडेक्स के अंदर देखते हैं, तो यह पता चला है कि वे एक समान तरीके से व्यवस्थित हैं। दोनों डेटाबेस ऑब्जेक्ट्स हैं जिनमें कुछ डेटा होते हैं जिनमें पंक्तियाँ होती हैं।

इसमें कोई संदेह नहीं है कि एक तालिका में पंक्तियाँ होती हैं, लेकिन यह एक सूचकांक के लिए कम स्पष्ट है। हालांकि, एक बी-पेड़ की कल्पना करें: इसमें नोड्स होते हैं जिनमें अनुक्रमित मान और अन्य नोड्स या टेबल पंक्तियों के संदर्भ होते हैं। यह ये नोड्स हैं जिन्हें सूचकांक पंक्तियों माना जा सकता है, और वास्तव में, वे हैं।

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

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

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

कांटे और फाइलें

आमतौर पर कई कांटे प्रत्येक संबंध के अनुरूप होते हैं। कांटे कई प्रकार के हो सकते हैं, और उनमें से प्रत्येक में एक निश्चित प्रकार का डेटा होता है।

यदि कोई कांटा है, तो इसे पहले एकमात्र फ़ाइल द्वारा दर्शाया जाता है। फ़ाइलनाम एक संख्यात्मक पहचानकर्ता है, जिसे एक अंत तक जोड़ा जा सकता है जो कांटा नाम से मेल खाता है।

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

फ़ाइल आकार का 1 जीबी सीमा अलग-अलग फ़ाइल सिस्टम का समर्थन करने के लिए ऐतिहासिक रूप से उत्पन्न हुई, जिनमें से कुछ बड़े आकार की फ़ाइलों से निपट नहीं सकते हैं। PostgreSQL ( ./configure --with-segsize ) का निर्माण करते समय आप इस सीमा को बदल सकते हैं।

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

एक टेबलस्पेस और एक डेटाबेस से संबंधित वस्तुओं की सभी फाइलें एक निर्देशिका में संग्रहीत की जाएंगी। आपको यह ध्यान में रखने की आवश्यकता है क्योंकि फाइल सिस्टम आमतौर पर एक निर्देशिका में बड़ी संख्या में फ़ाइलों के साथ ठीक काम करने में विफल रहता है।

यहां ध्यान दें कि फाइलें, बदले में, आमतौर पर 8 KB द्वारा पृष्ठ (या ब्लॉक ) में विभाजित होती हैं। हम पृष्ठों की आंतरिक संरचना पर थोड़ा और चर्चा करेंगे।

अब फोर्क प्रकारों को देखते हैं।

मुख्य कांटा स्वयं डेटा है: बहुत तालिका और सूचकांक पंक्तियाँ। मुख्य कांटा किसी भी संबंध के लिए उपलब्ध है (उन विचारों को छोड़कर, जिनमें डेटा नहीं है)।

मुख्य कांटे की फ़ाइलों के नाम में केवल संख्यात्मक पहचानकर्ता होते हैं। उदाहरण के लिए, यह उस तालिका का पथ है जिसे हमने पिछली बार बनाया था:

 => SELECT pg_relation_filepath('accounts');

  pg_relation_filepath ---------------------- base/41493/41496 (1 row)

ये पहचानकर्ता कहाँ से उत्पन्न होते हैं? "आधार" निर्देशिका "pg_default" तालिकाओं से मेल खाती है। डेटाबेस के अनुरूप अगला उपनिर्देशिका, वह जगह है जहाँ ब्याज की फ़ाइल स्थित है:

 => SELECT oid FROM pg_database WHERE datname = 'test';

  oid ------- 41493 (1 row)

 => SELECT relfilenode FROM pg_class WHERE relname = 'accounts';

  relfilenode ------------- 41496 (1 row)

पथ सापेक्ष है, यह डेटा निर्देशिका (PGDATA) से शुरू निर्दिष्ट है। इसके अलावा, वस्तुतः PostgreSQL के सभी पथ PGDATA से शुरू होने वाले निर्दिष्ट हैं। इसके लिए धन्यवाद, आप PGDATA को सुरक्षित रूप से एक अलग स्थान पर ले जा सकते हैं - कुछ भी इसे परिभाषित नहीं करता है (इसके अलावा LD_LIBRARY_PATH में पुस्तकालयों के लिए पथ सेट करने के लिए आवश्यक हो सकता है)।

इसके अलावा, फाइल सिस्टम में देख रहे हैं:

 postgres$ ls -l --time-style=+ /var/lib/postgresql/11/main/base/41493/41496

 -rw------- 1 postgres postgres 8192 /var/lib/postgresql/11/main/base/41493/41496

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

"खाते" तालिका लॉग की गई है, और इसलिए, इसमें आरंभीकरण कांटा नहीं है। लेकिन प्रयोग करने के लिए, हम लॉगिंग बंद कर सकते हैं:

 => ALTER TABLE accounts SET UNLOGGED; => SELECT pg_relation_filepath('accounts');

  pg_relation_filepath ---------------------- base/41493/41507 (1 row)

उदाहरण स्पष्ट करता है कि मक्खी पर लॉग ऑन करने और बंद करने की संभावना विभिन्न नामों के साथ डेटा को फ़ाइलों को फिर से लिखने के साथ जुड़ी हुई है।

एक प्रारंभिक कांटा का मुख्य कांटा के समान नाम है, लेकिन "_init" प्रत्यय के साथ:

 postgres$ ls -l --time-style=+ /var/lib/postgresql/11/main/base/41493/41507_init

 -rw------- 1 postgres postgres 0 /var/lib/postgresql/11/main/base/41493/41507_init

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

मुक्त स्थान के नक्शे का नाम "_fsm" प्रत्यय है। लेकिन यह फ़ाइल तुरंत नहीं, बल्कि केवल आवश्यकता के रूप में प्रकट होती है। इसे प्राप्त करने का सबसे आसान तरीका एक तालिका को वैक्यूम करना है (हम समय आने पर बताएंगे कि क्यों है):

 => VACUUM accounts;

 postgres$ ls -l --time-style=+ /var/lib/postgresql/11/main/base/41493/41507_fsm

 -rw------- 1 postgres postgres 24576 /var/lib/postgresql/11/main/base/41493/41507_fsm

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

 postgres$ ls -l --time-style=+ /var/lib/postgresql/11/main/base/41493/41507_vm

 -rw------- 1 postgres postgres 8192 /var/lib/postgresql/11/main/base/41493/41507_vm

पेज

जैसा कि पहले ही उल्लेख किया गया है, फाइलें तार्किक रूप से पृष्ठों में विभाजित हैं।

एक पृष्ठ में आमतौर पर 8 KB का आकार होता है। आकार को कुछ सीमाओं (16 KB या 32 KB) के भीतर बदला जा सकता है, लेकिन केवल निर्माण ( ./configure --with-blocksize ) के दौरान। एक निर्मित और रन इंस्टेंस केवल एक ही आकार के पृष्ठों के साथ काम कर सकता है।

फोर्क के बावजूद जहां फाइलें होती हैं, सर्वर उन्हें उसी तरह से उपयोग करता है। पृष्ठ पहले बफर कैश में पढ़े जाते हैं, जहां प्रक्रियाएं पढ़ सकती हैं और उन्हें बदल सकती हैं; फिर जैसे ही आवश्यकता होती है, वे डिस्क पर वापस आ जाते हैं।

प्रत्येक पृष्ठ में आंतरिक विभाजन होता है और सामान्य रूप से निम्नलिखित विभाजन होते हैं:

        ० + ----------------------------------- +
           |  हेडर |
       24 + ----------------------------------- +
           |  पंक्ति संस्करणों के लिए पॉइंटर्स की सरणी |
    निचला + ----------------------------------- +
           |  खाली स्थान |
    ऊपरी + ----------------------------------- +
           |  पंक्ति संस्करण |
  विशेष + ----------------------------------- +
           |  विशेष स्थान |
 पेजाइज़ + ----------------------------------- +

आप "शोध" एक्सटेंशन पेजिंस्पेक्ट का उपयोग करके इन विभाजनों के आकार को आसानी से जान सकते हैं:

 => CREATE EXTENSION pageinspect; => SELECT lower, upper, special, pagesize FROM page_header(get_raw_page('accounts',0));

  lower | upper | special | pagesize -------+-------+---------+---------- 40 | 8016 | 8192 | 8192 (1 row)

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

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

विशेष स्थान के बाद, पंक्ति संस्करण स्थित हैं, अर्थात, बहुत ही डेटा जिसे हम तालिका में संग्रहीत करते हैं और कुछ आंतरिक जानकारी।

शीर्ष लेख के ठीक बाद एक पृष्ठ के शीर्ष पर, सामग्री की तालिका होती है: पृष्ठ में उपलब्ध संस्करणों के बिंदुओं की सरणी ।

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

संकेत

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

प्रत्येक पॉइंटर में चार बाइट्स होते हैं और इनमें शामिल होते हैं:

पंक्ति संस्करण का संदर्भ
इस पंक्ति संस्करण का आकार
पंक्ति संस्करण की स्थिति निर्धारित करने के लिए कई बाइट्स

डेटा प्रारूप

डिस्क पर डेटा प्रारूप बिल्कुल वैसा ही है जैसे रैम में डेटा प्रतिनिधित्व। पृष्ठ को बफ़र कैश में "जैसा है", बिना किसी रूपांतरण के पढ़ा जाता है। इसलिए, एक प्लेटफ़ॉर्म से डेटा फ़ाइलें अन्य प्लेटफार्मों के साथ असंगत हैं।

उदाहरण के लिए, X86 आर्किटेक्चर में, बाइट ऑर्डर सबसे महत्वपूर्ण बाइट्स (लिटिल-एंडियन) से कम से कम महत्वपूर्ण है, z / आर्किटेक्चर व्युत्क्रम ऑर्डर (बिग-एंडियन) का उपयोग करता है, और एआरएम में ऑर्डर को स्वैप किया जा सकता है।

कई आर्किटेक्चर मशीन शब्दों की सीमाओं पर डेटा संरेखण के लिए प्रदान करते हैं। उदाहरण के लिए, 32-बिट x86 सिस्टम पर, पूर्णांक संख्या (प्रकार "पूर्णांक", जो 4 बाइट्स पर कब्जा करती है) को 4-बाइट शब्दों की सीमा पर संरेखित किया जाएगा, उसी तरह जैसे कि डबल-सटीक संख्या (टाइप "डबल सटीक" , जो 8 बाइट्स पर कब्जा करता है)। और 64-बिट सिस्टम पर, 8-बाइट शब्दों की सीमा पर डबल-सटीक संख्याओं को संरेखित किया जाएगा। यह एक और असंगति कारण है।

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

पंक्ति संस्करण और टोस्ट

हम अगली बार पंक्ति संस्करणों की आंतरिक संरचना के विवरण पर चर्चा करेंगे। इस बिंदु पर, हमारे लिए यह जानना महत्वपूर्ण है कि प्रत्येक संस्करण को एक पृष्ठ पूरी तरह से फिट होना चाहिए: पोस्टग्रेक्यूएल के पास अगले पृष्ठ पर पंक्ति को "विस्तारित" करने का कोई तरीका नहीं है। इसके बजाय ओवरसाइज़्ड एट्रीब्यूट्स स्टोरेज तकनीक (टोस्ट) का उपयोग किया जाता है। नाम ही संकेत देता है कि एक पंक्ति को विस्फोट में काट दिया जा सकता है।

इसके अलावा, टोस्ट कई रणनीतियों का अर्थ है। हम छोटे टोस्ट विखंडू में उन्हें तोड़ने के बाद लंबी विशेषता मानों को एक अलग आंतरिक तालिका में प्रसारित कर सकते हैं। एक अन्य विकल्प एक मूल्य को संपीड़ित करना है ताकि पंक्ति संस्करण एक नियमित पृष्ठ फिट हो। और हम दोनों कर सकते हैं: पहले संपीड़ित करें और फिर ब्रेक अप करें और संचारित करें।

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

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

प्रारंभिक रणनीतियों को स्तंभ डेटा प्रकारों द्वारा परिभाषित किया गया है। आप psql में \d+ कमांड का उपयोग करके उन्हें देख सकते हैं, लेकिन चूंकि यह अतिरिक्त रूप से कई अन्य जानकारी का उत्पादन करता है, हम सिस्टम कैटलॉग को क्वेरी करेंगे:

 => SELECT attname, atttypid::regtype, CASE attstorage WHEN 'p' THEN 'plain' WHEN 'e' THEN 'external' WHEN 'm' THEN 'main' WHEN 'x' THEN 'extended' END AS storage FROM pg_attribute WHERE attrelid = 'accounts'::regclass AND attnum > 0;

  attname | atttypid | storage ---------+----------+---------- id | integer | plain number | text | extended client | text | extended amount | numeric | main (4 rows)

रणनीतियों के नाम का अर्थ है:

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

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

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

कभी-कभी यह कुछ स्तंभों के लिए रणनीति बदलने के लिए उपयोगी हो सकता है। उदाहरण के लिए, यदि यह पहले से ज्ञात है कि किसी कॉलम में डेटा को संपीड़ित नहीं किया जा सकता है, तो हम इसके लिए "बाहरी" रणनीति निर्धारित कर सकते हैं, जो हमें बेकार संपीड़न प्रयासों से बचने के लिए समय बचाने में सक्षम बनाता है। यह निम्नानुसार किया जाता है:

 => ALTER TABLE accounts ALTER COLUMN number SET STORAGE external;

क्वेरी को फिर से चलाना, हमें मिलता है:

  attname | atttypid | storage ---------+----------+---------- id | integer | plain number | text | external client | text | extended amount | numeric | main

टोस्ट टेबल और इंडेक्स अलग-अलग pg_toast स्कीमा में स्थित हैं और इसलिए, आमतौर पर दिखाई नहीं देते हैं। अस्थायी तालिकाओं के लिए, "pg_toast_temp_ N " स्कीमा का उपयोग सामान्य "pg_temp_ N " के समान किया जाता है।

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

 => SELECT relnamespace::regnamespace, relname FROM pg_class WHERE oid = ( SELECT reltoastrelid FROM pg_class WHERE relname = 'accounts' );

  relnamespace | relname --------------+---------------- pg_toast | pg_toast_33953 (1 row)

 => \d+ pg_toast.pg_toast_33953

 TOAST table "pg_toast.pg_toast_33953" Column | Type | Storage ------------+---------+--------- chunk_id | oid | plain chunk_seq | integer | plain chunk_data | bytea | plain

यह उचित है कि "सादे" रणनीति को टोस्ट्स पर लागू किया जाता है जिसमें पंक्ति कटा हुआ है: कोई दूसरी-स्तरीय टोस्ट नहीं है।

PostgreSQL इंडेक्स को बेहतर तरीके से छिपाता है, लेकिन इसे ढूंढना मुश्किल नहीं है:

 => SELECT indexrelid::regclass FROM pg_index WHERE indrelid = ( SELECT oid FROM pg_class WHERE relname = 'pg_toast_33953' );

  indexrelid ------------------------------- pg_toast.pg_toast_33953_index (1 row)

 => \d pg_toast.pg_toast_33953_index

 Unlogged index "pg_toast.pg_toast_33953_index" Column | Type | Key? | Definition -----------+---------+------+------------ chunk_id | oid | yes | chunk_id chunk_seq | integer | yes | chunk_seq primary key, btree, for table "pg_toast.pg_toast_33953"

"क्लाइंट" कॉलम "विस्तारित" रणनीति का उपयोग करता है: इसके मूल्यों को संकुचित किया जाएगा। आइए देखें:

 => UPDATE accounts SET client = repeat('A',3000) WHERE id = 1; => SELECT * FROM pg_toast.pg_toast_33953;

  chunk_id | chunk_seq | chunk_data ----------+-----------+------------ (0 rows)

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

और अब ग्राहक का नाम यादृच्छिक वर्णों से मिलकर बनता है:

 => UPDATE accounts SET client = ( SELECT string_agg( chr(trunc(65+random()*26)::integer), '') FROM generate_series(1,3000) ) WHERE id = 1 RETURNING left(client,10) || '...' || right(client,10);

  ?column? ------------------------- TCKGKZZSLI...RHQIOLWRRX (1 row)

इस तरह के अनुक्रम को संकुचित नहीं किया जा सकता है, और यह टोस्ट तालिका में जाता है:

 => SELECT chunk_id, chunk_seq, length(chunk_data), left(encode(chunk_data,'escape')::text, 10) || '...' || right(encode(chunk_data,'escape')::text, 10) FROM pg_toast.pg_toast_33953;

  chunk_id | chunk_seq | length | ?column? ----------+-----------+--------+------------------------- 34000 | 0 | 2000 | TCKGKZZSLI...ZIPFLOXDIW 34000 | 1 | 1000 | DDXNNBQQYH...RHQIOLWRRX (2 rows)

हम देख सकते हैं कि डेटा 2000-बाइट विखंडू में टूट गया है।

जब कोई लंबा मान एक्सेस किया जाता है, तो PostgreSQL स्वचालित रूप से और आवेदन के लिए पारदर्शी रूप से मूल मूल्य को पुनर्स्थापित करता है और इसे क्लाइंट को लौटाता है।

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

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

ध्यान दें कि TOAST केवल तालिकाओं के लिए काम करता है, लेकिन अनुक्रमित के लिए नहीं। यह कुंजी के अनुक्रमित होने के आकार पर एक सीमा लगाता है।

आंतरिक डेटा संरचना के अधिक विवरण के लिए, आप दस्तावेज़ पढ़ सकते हैं।

पर पढ़ें ।

PostgreSQL-2 में MVCC। कांटे, फाइलें, पेज

संबंध

कांटे और फाइलें

पेज

संकेत

डेटा प्रारूप

पंक्ति संस्करण और टोस्ट

More articles: