🥇पोस्टग्रेज़: ब्लोट, pg_repack और स्थगित बाधाएँ

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

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

के आधार पर यह लेख लिखा गया है मेरा भाषण PgConf.Russia 2020 पर।

सूजन क्यों होती है?

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

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

मान लीजिए कि हमारे पास एक तालिका है जिसमें हमने कई रिकॉर्ड जोड़े हैं। नया डेटा फ़ाइल के पहले पृष्ठ पर दिखाई दिया है जहाँ तालिका संग्रहीत है। ये पंक्तियों के लाइव संस्करण हैं जो कमिट के बाद अन्य लेनदेन के लिए उपलब्ध हैं (सरलता के लिए, हम मान लेंगे कि अलगाव स्तर रीड कमिटेड है)।

फिर हमने प्रविष्टियों में से एक को अद्यतन किया, जिससे पुराने संस्करण को अब प्रासंगिक नहीं माना गया।

चरण दर चरण, पंक्ति संस्करणों को अद्यतन और हटाते हुए, हमें एक पृष्ठ मिला जिसमें लगभग आधा डेटा "कचरा" है। यह डेटा किसी भी लेनदेन में दिखाई नहीं देता है.

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

इसलिए हमारे उदाहरण में, किसी समय तालिका में चार पृष्ठ होंगे, लेकिन इसके केवल आधे हिस्से में लाइव डेटा होगा। परिणामस्वरूप, तालिका तक पहुँचने पर, हम आवश्यकता से कहीं अधिक डेटा पढ़ेंगे।

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

जब ऐसे खाली या अत्यधिक विरल पृष्ठों की संख्या बड़ी हो जाती है, जिसे ब्लोट कहा जाता है, तो इसका प्रदर्शन पर असर पड़ने लगता है।

ऊपर वर्णित हर चीज़ तालिकाओं में सूजन की घटना की यांत्रिकी है। अनुक्रमणिका में यह लगभग इसी प्रकार होता है।

क्या मुझे सूजन है?

यह निर्धारित करने के कई तरीके हैं कि आपको सूजन है या नहीं। पहले का विचार आंतरिक पोस्टग्रेज आँकड़ों का उपयोग करना है, जिसमें तालिकाओं में पंक्तियों की संख्या, "लाइव" पंक्तियों की संख्या आदि के बारे में अनुमानित जानकारी शामिल है। आप इंटरनेट पर तैयार स्क्रिप्ट के कई रूप पा सकते हैं। हमने आधार के रूप में लिया लिखी हुई कहानी PostgreSQL विशेषज्ञों से, जो टोस्ट और ब्लोट बीट्री इंडेक्स के साथ ब्लोट टेबल का मूल्यांकन कर सकते हैं। हमारे अनुभव में इसकी त्रुटि 10-20% है।

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

हम 20% तक के छोटे ब्लोट मान को स्वीकार्य मानते हैं। इसे फिलफैक्टर का एक एनालॉग माना जा सकता है तालिका बनाना и सूचकांक. 50% और उससे अधिक पर, प्रदर्शन संबंधी समस्याएं शुरू हो सकती हैं।

सूजन से निपटने के तरीके

पोस्टग्रेज़ के पास बॉक्स से बाहर सूजन से निपटने के कई तरीके हैं, लेकिन वे हमेशा सभी के लिए उपयुक्त नहीं होते हैं।

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

AUTOVACUUM के तालिकाओं के साथ न टिक पाने का एक और सामान्य कारण यह है कि इसमें लंबे समय तक चलने वाले लेन-देन होते हैं जो इसे उन लेन-देन के लिए उपलब्ध डेटा को साफ करने से रोकते हैं। यहां सिफ़ारिश भी स्पष्ट है - "लटकते" लेनदेन से छुटकारा पाएं और सक्रिय लेनदेन के समय को कम करें। लेकिन यदि आपके एप्लिकेशन पर लोड OLAP और OLTP का मिश्रित रूप है, तो आपके पास एक साथ कई लगातार अपडेट और छोटी क्वेरीज़, साथ ही दीर्घकालिक संचालन हो सकते हैं - उदाहरण के लिए, एक रिपोर्ट बनाना। ऐसी स्थिति में, लोड को विभिन्न आधारों पर फैलाने के बारे में सोचना उचित है, जो उनमें से प्रत्येक को और अधिक ठीक करने की अनुमति देगा।

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

ऐसी स्थिति में क्या करें जहां आपने ऑटोवैक्यूम स्थापित किया है, लेकिन सूजन बढ़ती जा रही है।

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

टीम क्लस्टर VACUUM FULL की तरह ही तालिकाओं की सामग्री का पुनर्निर्माण करता है, लेकिन आपको एक इंडेक्स निर्दिष्ट करने की अनुमति देता है जिसके अनुसार डेटा को भौतिक रूप से डिस्क पर ऑर्डर किया जाएगा (लेकिन भविष्य में नई पंक्तियों के लिए ऑर्डर की गारंटी नहीं है)। कुछ स्थितियों में, यह कई प्रश्नों के लिए एक अच्छा अनुकूलन है - सूचकांक द्वारा कई रिकॉर्ड पढ़ने के साथ। कमांड का नुकसान VACUUM FULL जैसा ही है - यह ऑपरेशन के दौरान टेबल को लॉक कर देता है।

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

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

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

pg_repack कैसे काम करता है

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

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

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

सिद्धांत में सब कुछ बढ़िया दिखता है, लेकिन व्यवहार में क्या होता है? हमने बिना लोड और अंडर लोड के pg_repack का परीक्षण किया, और समय से पहले रुकने की स्थिति में इसके संचालन की जाँच की (दूसरे शब्दों में, Ctrl + C का उपयोग करके)। सभी परीक्षण सकारात्मक थे.

हम भोजन की दुकान पर गए - और फिर सब कुछ हमारी अपेक्षा के अनुरूप नहीं हुआ।

बिक्री पर पहला पैनकेक

पहले क्लस्टर पर हमें एक अद्वितीय बाधा के उल्लंघन के बारे में एक त्रुटि प्राप्त हुई:

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

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

विलंबित बाधाएँ: उनकी आवश्यकता क्यों है और वे कैसे काम करती हैं

आस्थगित प्रतिबंधों के बारे में एक छोटा सा सिद्धांत।
आइए एक सरल उदाहरण पर विचार करें: हमारे पास दो विशेषताओं वाली कारों की एक तालिका-संदर्भ पुस्तक है - निर्देशिका में कार का नाम और क्रम।

create table cars
(
  name text constraint pk_cars primary key,
  ord integer not null constraint uk_cars unique
);

मान लीजिए कि हमें पहली और दूसरी कारों की अदला-बदली करने की जरूरत है। सीधा समाधान यह है कि पहले मान को दूसरे में और दूसरे को पहले में अपडेट किया जाए:

begin;
  update cars set ord = 2 where name = 'audi';
  update cars set ord = 1 where name = 'bmw';
commit;

लेकिन जब हम इस कोड को चलाते हैं, तो हम बाधा उल्लंघन की उम्मीद करते हैं क्योंकि तालिका में मानों का क्रम अद्वितीय है:

[23305] ERROR: duplicate key value violates unique constraint “uk_cars”
Detail: Key (ord)=(2) already exists.

मैं इसे अलग तरीके से कैसे कर सकता हूं? विकल्प एक: उस ऑर्डर में एक अतिरिक्त मूल्य प्रतिस्थापन जोड़ें जो तालिका में मौजूद नहीं होने की गारंटी है, उदाहरण के लिए "-1"। प्रोग्रामिंग में, इसे "दो वेरिएबल्स के मूल्यों को तीसरे के माध्यम से आदान-प्रदान करना" कहा जाता है। इस पद्धति का एकमात्र दोष अतिरिक्त अद्यतन है।

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

विकल्प तीन: बाधा को स्थगित कर दें ताकि इसे केवल प्रतिबद्धता के समय ही जांचा जा सके:

create table cars
(
  name text constraint pk_cars primary key,
  ord integer not null constraint uk_cars unique deferrable initially deferred
);

चूँकि हमारे प्रारंभिक अनुरोध का तर्क यह सुनिश्चित करता है कि प्रतिबद्धता के समय सभी मान अद्वितीय हैं, यह सफल होगा।

ऊपर चर्चा किया गया उदाहरण, बेशक, बहुत सिंथेटिक है, लेकिन यह विचार को प्रकट करता है। हमारे एप्लिकेशन में, हम तर्क को लागू करने के लिए विलंबित बाधाओं का उपयोग करते हैं जो उन विवादों को हल करने के लिए जिम्मेदार है जब उपयोगकर्ता एक साथ बोर्ड पर साझा विजेट ऑब्जेक्ट के साथ काम करते हैं। ऐसे प्रतिबंधों का उपयोग करने से हम एप्लिकेशन कोड को थोड़ा सरल बना सकते हैं।

सामान्य तौर पर, बाधा के प्रकार के आधार पर, पोस्टग्रेज में उनकी जाँच के लिए ग्रैन्युलैरिटी के तीन स्तर होते हैं: पंक्ति, लेनदेन और अभिव्यक्ति स्तर।

स्रोत: बेग्रीफ्स

CHECK और NOT NULL को हमेशा पंक्ति स्तर पर चेक किया जाता है; अन्य प्रतिबंधों के लिए, जैसा कि तालिका से देखा जा सकता है, अलग-अलग विकल्प हैं। आप और अधिक पढ़ सकते हैं यहां.

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

pg_repack में सुधार

हमने कवर किया है कि विलंबित बाधाएँ क्या हैं, लेकिन वे हमारी समस्या से कैसे संबंधित हैं? आइए उस त्रुटि को याद करें जो हमें पहले मिली थी:

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

यह तब होता है जब डेटा को लॉग टेबल से नई टेबल में कॉपी किया जाता है। यह अजीब लगता है क्योंकि... लॉग तालिका में डेटा स्रोत तालिका में डेटा के साथ प्रतिबद्ध है। यदि वे मूल तालिका की बाधाओं को पूरा करते हैं, तो वे नई तालिका में उन्हीं बाधाओं का उल्लंघन कैसे कर सकते हैं?

जैसा कि यह पता चला है, समस्या की जड़ pg_repack के पिछले चरण में है, जो केवल इंडेक्स बनाता है, लेकिन बाधाएं नहीं: पुरानी तालिका में एक अद्वितीय बाधा थी, और नई तालिका ने इसके बजाय एक अद्वितीय इंडेक्स बनाया।

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

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

तो हमारे पास क्या विचार थे?

स्थगित के समान एक सूचकांक बनाएं

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

यह सुनिश्चित करने के लिए कि चेक हमेशा गैर-विलंबित मोड में हों, हमने मूल विलंबित बाधा के समान एक नया सूचकांक बनाया:

CREATE UNIQUE INDEX CONCURRENTLY uk_tablename__immediate ON tablename (id, index);
-- run pg_repack
DROP INDEX CONCURRENTLY uk_tablename__immediate;

परीक्षण परिवेश में, हमें केवल कुछ अपेक्षित त्रुटियाँ प्राप्त हुईं। सफलता! हमने उत्पादन पर फिर से pg_repack चलाया और एक घंटे के काम में पहले क्लस्टर पर 5 त्रुटियाँ मिलीं। यह एक स्वीकार्य परिणाम है. हालाँकि, पहले से ही दूसरे क्लस्टर पर त्रुटियों की संख्या काफी बढ़ गई और हमें pg_repack को रोकना पड़ा।

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

विचार काम नहीं आया. उस समय, हमने दो अन्य समाधान देखे: विलंबित बाधाओं से छुटकारा पाने के लिए हमारे एप्लिकेशन कोड को फिर से लिखें, या उनके साथ काम करने के लिए pg_repack को "सिखाएं"। हमने दूसरा चुना.

नई तालिका में अनुक्रमणिका को मूल तालिका से विलंबित बाधाओं के साथ बदलें

संशोधन का उद्देश्य स्पष्ट था - यदि मूल तालिका में एक विलंबित बाधा है, तो नई तालिका के लिए आपको ऐसी बाधा बनाने की आवश्यकता है, न कि एक सूचकांक।

अपने परिवर्तनों का परीक्षण करने के लिए, हमने एक सरल परीक्षण लिखा:

आस्थगित बाधा और एक रिकॉर्ड वाली तालिका;
एक लूप में डेटा डालें जो मौजूदा रिकॉर्ड के साथ टकराव करता है;
अद्यतन करें - डेटा में अब टकराव नहीं होगा;
परिवर्तन प्रतिबद्ध करें.

create table test_table
(
  id serial,
  val int,
  constraint uk_test_table__val unique (val) deferrable initially deferred 
);

INSERT INTO test_table (val) VALUES (0);
FOR i IN 1..10000 LOOP
  BEGIN
    INSERT INTO test_table VALUES (0) RETURNING id INTO v_id;
    UPDATE test_table set val = i where id = v_id;
    COMMIT;
  END;
END LOOP;

pg_repack का मूल संस्करण हमेशा पहली प्रविष्टि पर क्रैश हो जाता था, संशोधित संस्करण त्रुटियों के बिना काम करता था। महान।

हम उत्पादन में जाते हैं और लॉग टेबल से डेटा को एक नए में कॉपी करने के उसी चरण में फिर से एक त्रुटि प्राप्त करते हैं:

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

क्लासिक स्थिति: परीक्षण वातावरण में सब कुछ काम करता है, लेकिन उत्पादन में नहीं?!

APPLY_COUNT और दो बैचों का जंक्शन

हमने कोड का शाब्दिक रूप से पंक्ति दर पंक्ति विश्लेषण करना शुरू किया और एक महत्वपूर्ण बिंदु खोजा: डेटा को लॉग तालिका से बैचों में एक नए में स्थानांतरित किया जाता है, APPLY_COUNT स्थिरांक ने बैच के आकार को इंगित किया:

for (;;)
{
num = apply_log(connection, table, APPLY_COUNT);

if (num > MIN_TUPLES_BEFORE_SWITCH)
     continue;  /* there might be still some tuples, repeat. */
...
}

समस्या यह है कि मूल लेनदेन से डेटा, जिसमें कई ऑपरेशन संभावित रूप से बाधा का उल्लंघन कर सकते हैं, स्थानांतरित होने पर, दो बैचों के जंक्शन पर समाप्त हो सकता है - आधे कमांड पहले बैच में प्रतिबद्ध होंगे, और दूसरे आधे क्षण में। और यहां, आपकी किस्मत पर निर्भर करता है: यदि टीमें पहले बैच में कुछ भी उल्लंघन नहीं करती हैं, तो सब कुछ ठीक है, लेकिन यदि वे ऐसा करते हैं, तो एक त्रुटि होती है।

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

FOR i IN 1..10000 LOOP
  BEGIN
    INSERT INTO test_table VALUES (1) RETURNING id INTO v_id;
    UPDATE test_table set val = i where id = v_id;
    UPDATE test_table set val = i where id = v_id; -- one more update
    COMMIT;
  END;
END LOOP;

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

बैचिंग से इंकार

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

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

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

प्रयोग सकारात्मक थे. प्रोडक्शन पर भी लॉन्च. स्पष्टता के लिए, यहां चलने के बाद डेटाबेस में से एक के आकार की एक तस्वीर दी गई है:

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

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

निष्कर्ष

हम अपने अनुभव के आधार पर क्या अनुशंसा कर सकते हैं:

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

स्रोत: www.habr.com

पोस्टग्रेज़: ब्लोट, pg_repack और विलंबित बाधाएँ