आलसी उन्नयन: PostgreSQL 12 प्रदर्शन को कैसे बेहतर बनाता है

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

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

लेकिन PostgreSQL 12 इस तक सीमित नहीं है: नई सुविधाओं और सुधारों के साथ, एप्लिकेशन बेहतर काम करेंगे, और आपको बस अपग्रेड करने की आवश्यकता है!

(खैर, शायद सूचकांकों का पुनर्निर्माण भी हो सकता है, लेकिन इस रिलीज में यह उतना डरावना नहीं है जितना हम करते थे।)

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

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

और कैसे PostgreSQL 12 के लिए एक सरल उन्नयन आपको खुश करता है? अभी बताता हूँ।

प्रमुख अनुक्रमण सुधार

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

हम सिर्फ CREATE INDEX ON some_table (some_column) उपयोग करते हैं, और PostgreSQL इंडेक्स को अपडेट रखने के लिए एक बड़ा काम करता है, जबकि हम लगातार CREATE INDEX ON some_table (some_column) , अपडेट करते हैं और वैल्यूज को डिलीट करते हैं। सब कुछ अपने आप से काम करता है, जैसे कि जादू से।

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

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

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

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

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

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

विभाजन - बड़ा, बेहतर, तेज़

PostgreSQL 10 ने घोषणात्मक विभाजन शुरू किया। PostgreSQL 11 ने इसे उपयोग करना बहुत आसान बना दिया। PostgreSQL 12 में, आप वर्गों के पैमाने बदल सकते हैं।

PostgreSQL 12 में, विभाजन प्रणाली का प्रदर्शन बहुत बेहतर है, खासकर अगर तालिका में हजारों अनुभाग हैं। उदाहरण के लिए, यदि कोई क्वेरी किसी तालिका में केवल कुछ अनुभागों को प्रभावित करती है, जहां उनमें से हजारों हैं, तो यह बहुत तेजी से चलेगा। न केवल इन प्रकार के प्रश्नों के लिए प्रदर्शन में सुधार किया गया है। आप यह भी देखेंगे कि कई विभाजनों के साथ तालिकाओं में INSERT संचालन कैसे तेज हुआ है।

COPY का उपयोग करके डेटा लिखना - वैसे, यह डेटा लोड करने का एक शानदार तरीका है और यहाँ JSON प्राप्त करने का एक उदाहरण है - PostgreSQL 12 में विभाजन तालिका में भी अधिक कुशल हो गया है। COPY के साथ, सब कुछ इतना तेज़ था, लेकिन PostgreSQL 12 में यह उड़ता है।

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

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

प्रश्नों के साथ बहुत बेहतर हैं

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

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

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

इसके अलावा, PostgreSQL 12 SQL के निष्पादन को अनुकूलित करता है, आपको कुछ भी करने की आवश्यकता नहीं है। और यद्यपि अब, शायद, मुझे इस तरह के प्रश्नों को अनुकूलित करने की आवश्यकता नहीं होगी, यह बहुत अच्छा है कि PostgreSQL क्वेरी अनुकूलन पर काम करना जारी रखे।

जस्ट-इन-टाइम (JIT) - अब डिफ़ॉल्ट

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

चूंकि JIT को डिफ़ॉल्ट रूप से PostgreSQL 12 में शामिल किया गया है, इसलिए प्रदर्शन अपने आप ही सुधर जाएगा, लेकिन मैं PostgreSQL 11 में एप्लिकेशन का परीक्षण करने की सलाह देता हूं, जहां JIT अभी क्वेरी प्रदर्शन को मापने के लिए प्रकट हुई है और देखें कि क्या आपको कुछ भी ट्यून करने की आवश्यकता है।

लेकिन PostgreSQL 12 की अन्य नई विशेषताओं के बारे में क्या?

PostgreSQL में कई नए नए फीचर्स हैं, जिसमें clientcert=verify-full लिए मल्टी-फैक्टर ऑथेंटिकेशन के साथ मानक SQL / JSON रूट एक्सप्रेशन का उपयोग करके JSON डेटा की जांच करने की क्षमता से clientcert=verify-full कॉलम और बहुत कुछ बनाया गया है। एक अलग पोस्ट के लिए पर्याप्त है।

PostgreSQL 10 की तरह, PostgreSQL 12 अपग्रेड के ठीक बाद समग्र प्रदर्शन में सुधार करेगा। बेशक, आपके पास अपना रास्ता हो सकता है - सुधार चालू करने से पहले कार्य प्रणाली में समान शर्तों के तहत आवेदन का परीक्षण करें, जैसा कि मैंने PostgreSQL 10 के साथ किया था। यहां तक ​​कि अगर PostgreSQL 12 पहले से ही मेरी अपेक्षा से अधिक स्थिर है, तो आवेदन की गुणवत्ता का परीक्षण करने के लिए आलसी न हों, उत्पादन में उन्हें जारी करने से पहले।