आलसी लोगों के लिए अपग्रेड करें: कैसे PostgreSQL 12 प्रदर्शन में सुधार करता है

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

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

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

(ठीक है, हो सकता है कि इंडेक्स को फिर से बनाया जाए, लेकिन इस रिलीज़ में यह उतना डरावना नहीं है जितना हम इस्तेमाल करते थे।)

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

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

तो PostgreSQL 12 में एक साधारण अपग्रेड आपको कैसे खुश कर सकता है? मैं तुम्हें अभी बताता हूँ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

मुझे अक्सर लगता है कि SQL में नए लोग CTE का उपयोग करना पसंद करते हैं; यदि आप उन्हें एक निश्चित तरीके से लिखते हैं, तो वास्तव में ऐसा लगता है जैसे आप एक अनिवार्य प्रोग्राम लिख रहे हैं। व्यक्तिगत रूप से, मुझे इन प्रश्नों को फिर से लिखना अच्छा लगा बिना सीटीई और उत्पादकता में वृद्धि। अब सब कुछ अलग है.

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

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

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

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

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

PostgreSQL 12 में बाकी नई सुविधाओं के बारे में क्या?

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

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

स्रोत: www.habr.com