टेबल ब्लोट? नहीं, मैंने सुना नहीं ...

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


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

सफाई प्रक्रिया, ऑटोवैक्यूम या वैक्यूम, पूरी तरह से खाली पन्नों को हटाकर तालिका के आकार को कम कर सकते हैं, लेकिन केवल अगर वे तालिका के बहुत अंत में हैं। जितना संभव हो सके टेबल को कम से कम करने के लिए PostgreSQL में VACUUM FULL या CLUSTER होता है, लेकिन इन दोनों तरीकों के लिए टेबल पर भारी और लंबे तालों की स्थापना की आवश्यकता होती है, जो हमेशा सही समाधान नहीं होता है।

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

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

इसकी मुख्य विशेषताएं:

• पर्ल> = 5.8.8 को छोड़कर किसी भी निर्भरता की आवश्यकता नहीं है, अर्थात आप बस सर्वर पर pgcompactor की प्रतिलिपि बना सकते हैं और इसके साथ काम कर सकते हैं;
• DBD :: Pg, DBD :: PgPP एडेप्टर या मानक psql उपयोगिता के माध्यम से भी काम करता है अगर पहले दो सर्वर पर नहीं हैं;
• स्कीमा, डेटाबेस, या संपूर्ण क्लस्टर के भीतर दोनों व्यक्तिगत तालिकाओं और सभी तालिकाओं का प्रसंस्करण;
• प्रसंस्करण से डेटाबेस, स्कीमा या तालिकाओं को बाहर करने की क्षमता;
• मुद्रास्फीति प्रभाव और केवल उन तालिकाओं के प्रसंस्करण का विश्लेषण जिसमें यह मौजूद है; अधिक सटीक गणना के लिए, यह pgstattuple एक्सटेंशन स्थापित करने के लिए अनुशंसित है;
• मुद्रास्फीति के प्रभाव से सूचकांकों का विश्लेषण और पुनर्निर्माण;
• सूजन के प्रभाव के साथ अद्वितीय बाधाओं और प्राथमिक कुंजी का विश्लेषण और पुनर्निर्माण;
• वृद्धिशील उपयोग यानी आप कुछ भी नुकसान पहुँचाए बिना संपीड़न प्रक्रिया को रोक सकते हैं;
• वर्तमान डेटाबेस लोड के लिए गतिशील समायोजन, ताकि उपयोगकर्ता प्रश्नों के प्रदर्शन को प्रभावित न करें (स्टार्टअप पर समायोजित करने की क्षमता के साथ);
• डेटाबेस ऑब्जेक्ट्स के पुनर्निर्माण के लिए एक तैयार DDL के साथ प्रशासकों को सिफारिशें, जो स्वचालित रूप से पुनर्निर्माण नहीं की जा सकती हैं।

उपयोग के मामलों की एक जोड़ी:
सूचकांक के अनिवार्य पुनर्निर्माण के साथ पूरे क्लस्टर पर लॉन्च:
# pgcompactor --all --reindex

एक अलग टेबल पर लॉन्च (अनुक्रमणिका के पुनर्निर्माण के साथ):
# pgcompactor --reindex --dbname जियोडेटा-टेबल शहरों --verbose जानकारी> pgcompactor.log 2> & 1

काम का परिणाम:
टेबल का आकार 9.2GB से घटकर 5.6GB हो गया है। सभी सूचकांकों का कुल आकार 7.5GB से घटकर 2.8GB हो गया


प्रोजेक्ट URL: github.com/PostgreSQL-Consulting/pgcompacttable

उनके काम के लिए उपयोगिता के लेखकों के लिए बहुत धन्यवाद! यह वास्तव में उपयोगी उपकरण है।

आपका ध्यान के लिए धन्यवाद!