अल्छीका लागि अपग्रेड गर्नुहोस्: कसरी PostgreSQL 12 ले प्रदर्शन सुधार गर्दछ

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

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

तर PostgreSQL 12 त्यहाँ रोकिदैन: नयाँ सुविधाहरू र सुधारहरूको साथ, अनुप्रयोगहरूले राम्रो प्रदर्शन गर्नेछ, र तपाईले गर्नु पर्ने भनेको अपग्रेड हो!

(ठीक छ, हुनसक्छ अनुक्रमणिकाहरू पुन: निर्माण गर्नुहोस्, तर यस विमोचनमा यो डरलाग्दो छैन जस्तो कि हामीले प्रयोग गरेका छौं।)

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

सहमत हुनुहोस्, अपग्रेड पछि तुरुन्तै अनुप्रयोगहरूले राम्रोसँग काम गर्दा यो सुविधाजनक हुन्छ। र हामी प्रयोगकर्ताहरूलाई खुसी पार्न धेरै प्रयास गर्छौं, किनकि PostgreSQL सँग तिनीहरूमध्ये धेरै छन्।

त्यसोभए कसरी PostgreSQL 12 मा एक साधारण स्तरवृद्धिले तपाईंलाई खुशी बनाउन सक्छ? अब म भन्छु।

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

अनुक्रमणिका बिना, डाटाबेस टाढा जान सक्दैन। तपाईं कसरी छिटो जानकारी पाउन सक्नुहुन्छ? PostgreSQL को आधारभूत अनुक्रमणिका प्रणाली भनिन्छ B- रुख। यस प्रकारको सूचकांक भण्डारण प्रणालीहरूको लागि अनुकूलित छ।

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

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

PostgreSQL 12 ले B-tree indexes को कार्यसम्पादनमा धेरै सुधार गर्छ, र TPC-C जस्ता बेन्चमार्कहरूका प्रयोगहरूले औसतमा 40% कम ठाउँ प्रयोग भएको देखाएको छ। अब हामी B-tree अनुक्रमणिकाहरू (अर्थात, लेखन कार्यहरूमा) कायम राख्न मात्र नभई डेटा पुन: प्राप्त गर्नमा पनि कम समय खर्च गर्छौं, किनभने अनुक्रमणिकाहरू धेरै सानो छन्।

अनुप्रयोगहरू जसले सक्रिय रूपमा तिनीहरूको तालिकाहरू अद्यावधिक गर्दछ - सामान्यतया OLTP अनुप्रयोगहरू (वास्तविक समय लेनदेन प्रशोधन) - धेरै कुशलतापूर्वक डिस्क र प्रक्रिया अनुरोधहरू प्रयोग गर्नेछ। जति धेरै डिस्क स्पेस हुन्छ, डाटाबेसले पूर्वाधारको स्तरवृद्धि नगरिकन त्यति नै बढी ठाउँ बढाउनुपर्छ।

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

PostgreSQL 12 मा अनुक्रमणिका पूर्वाधारमा अन्य सुधारहरू छन्। अर्को कुरा जहाँ केही जादू थियो - अगाडि लेख्नुहोस्, उर्फ ​​WAL (लेख्न-अगाडि लग)। लेख्ने-अगाडि लगले असफलता र प्रतिकृतिको अवस्थामा PostgreSQL मा प्रत्येक लेनदेन रेकर्ड गर्दछ। अनुप्रयोगहरूले यसलाई अभिलेखको लागि प्रयोग गर्दछ र पोइन्ट-इन-टाइम रिकभरी। अवश्य पनि, लेखन-अगाडि लग डिस्कमा लेखिएको छ, जसले कार्यसम्पादनलाई असर गर्न सक्छ।

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

विभाजन - ठूलो, राम्रो, छिटो

PostgreSQL 10 पेश गरियो घोषणात्मक विभाजन। PostgreSQL 11 मा यो प्रयोग गर्न धेरै सजिलो भएको छ। PostgreSQL 12 मा तपाईले खण्डहरूको स्केल परिवर्तन गर्न सक्नुहुन्छ।

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

रेकर्डिङ डाटा प्रयोग गर्दै कापी - वैसे, यो एक राम्रो तरिका हो बल्क डाटा डाउनलोड र यहाँ एउटा उदाहरण हो JSON प्राप्त गर्दै — PostgreSQL 12 मा विभाजन गरिएको तालिकाहरू पनि थप प्रभावकारी भएका छन्। COPY को साथ सबै कुरा पहिले नै छिटो थियो, तर PostgreSQL 12 मा यो बिल्कुल उड्छ।

यी फाइदाहरूको लागि धन्यवाद, PostgreSQL ले तपाईंलाई अझ ठूला डाटा सेटहरू भण्डारण गर्न र तिनीहरूलाई पुन: प्राप्त गर्न सजिलो बनाउन अनुमति दिन्छ। र तपाईंको तर्फबाट कुनै प्रयास छैन। यदि अनुप्रयोगसँग धेरै विभाजनहरू छन्, जस्तै रेकर्डिङ समय श्रृंखला डेटा, एक साधारण अपग्रेडले यसको कार्यसम्पादनमा उल्लेखनीय सुधार गर्नेछ।

यद्यपि यो वास्तवमा "अपग्रेड र रमाइलो" सुधार होइन, PostgreSQL 12 ले तपाईंलाई विभाजन गरिएको तालिकाहरू सन्दर्भ गर्ने विदेशी कुञ्जीहरू सिर्जना गर्न अनुमति दिन्छ, विभाजनलाई काम गर्न रमाइलो बनाउँछ।

प्रश्नहरूको साथ धेरै राम्रो भयो

कहिले एउटा प्याच बिल्ट-इन साझा तालिका अभिव्यक्तिहरूको लागि लागू गरिएको थियो (उर्फ CTE, aka WITH queries), म यस बारे लेख लेख्न पर्खिन सक्दिन PostgreSQL सँग अनुप्रयोग विकासकर्ताहरू कत्ति खुसी थिए। यो ती सुविधाहरू मध्ये एक हो जसले अनुप्रयोगलाई गति दिन्छ। जबसम्म, अवश्य पनि, तपाइँ CTE प्रयोग गर्नुहुन्छ।

मैले प्रायः SQL मा नयाँ व्यक्तिहरूलाई CTEs प्रयोग गर्न मन पराएको पाउँछु; यदि तपाईंले तिनीहरूलाई कुनै निश्चित तरिकाले लेख्नुभयो भने, यो साँच्चै लाग्छ कि तपाईंले एउटा अनिवार्य कार्यक्रम लेख्दै हुनुहुन्छ। व्यक्तिगत रूपमा, मलाई वरिपरि प्राप्त गर्न यी प्रश्नहरू पुन: लेख्न मन पर्यो बिना CTE र उत्पादकता वृद्धि। अब सबै कुरा फरक छ।

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

यसबाहेक, PostgreSQL 12 ले SQL कार्यान्वयन आफैलाई अनुकूलन गर्दछ, तपाईले केहि नगरी नै। र यद्यपि मलाई अब त्यस्ता प्रश्नहरू अप्टिमाइज गर्न आवश्यक पर्दैन, यो राम्रो छ कि PostgreSQL ले क्वेरी अप्टिमाइजेसनमा काम गर्न जारी राख्छ।

जस्ट-इन-टाइम (JIT) - अब पूर्वनिर्धारित

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

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

PostgreSQL 12 मा बाँकी नयाँ सुविधाहरूको बारेमा के हुन्छ?

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

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

स्रोत: www.habr.com