आळशींसाठी अपग्रेड करा: PostgreSQL 12 कार्यप्रदर्शन कसे सुधारते

पोस्टग्रेस्क्यूएल 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 बी-ट्री इंडेक्सेसचे कार्यप्रदर्शन मोठ्या प्रमाणात सुधारते, आणि TPC-C सारख्या बेंचमार्कसह प्रयोगांनी असे दाखवले आहे की आता सरासरी 40% कमी जागा वापरली जाते. आता आम्ही केवळ बी-ट्री इंडेक्स (म्हणजे लेखन ऑपरेशन्स) राखण्यातच कमी वेळ घालवतो, परंतु डेटा पुनर्प्राप्त करण्यात देखील कमी वेळ घालवतो, कारण निर्देशांक खूपच लहान आहेत.

ऍप्लिकेशन्स जे सक्रियपणे त्यांचे टेबल अपडेट करतात - सामान्यत: OLTP ऍप्लिकेशन्स (रिअल-टाइम व्यवहार प्रक्रिया) - डिस्क वापरेल आणि विनंत्या अधिक कार्यक्षमतेने प्रक्रिया करेल. अधिक डिस्क स्पेस, पायाभूत सुविधा अपग्रेड न करता डेटाबेसमध्ये अधिक जागा वाढवावी लागेल.

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

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

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

विभाजन - मोठे, चांगले, जलद

PostgreSQL 10 सादर केले घोषणात्मक विभाजन. PostgreSQL 11 मध्ये ते वापरणे खूप सोपे झाले आहे. PostgreSQL 12 मध्ये तुम्ही विभागांचे स्केल बदलू शकता.

PostgreSQL 12 मध्ये, विभाजन प्रणालीचे कार्यप्रदर्शन लक्षणीयरित्या चांगले झाले आहे, विशेषत: टेबलमध्ये हजारो विभाजने असल्यास. उदाहरणार्थ, जर एखादी क्वेरी हजारो असलेल्या टेबलमधील काही विभाजनांवर परिणाम करत असेल, तर ते अधिक वेगाने कार्यान्वित होईल. केवळ या प्रकारच्या क्वेरीसाठी कार्यप्रदर्शन सुधारले जात नाही. एकाधिक विभाजने असलेल्या टेबलवर INSERT ऑपरेशन्स किती वेगवान आहेत हे देखील तुमच्या लक्षात येईल.

वापरून डेटा रेकॉर्डिंग कॉपी करा - तसे, हा एक चांगला मार्ग आहे मोठ्या प्रमाणात डेटा डाउनलोड आणि येथे एक उदाहरण आहे JSON प्राप्त करत आहे — PostgreSQL 12 मधील विभाजित तक्ते देखील अधिक कार्यक्षम बनले आहेत. कॉपी सह सर्व काही आधीच वेगवान होते, परंतु PostgreSQL 12 मध्ये ते पूर्णपणे उडते.

या फायद्यांमुळे धन्यवाद, PostgreSQL तुम्हाला आणखी मोठे डेटा संच संचयित करण्यास आणि ते पुनर्प्राप्त करणे सोपे करते. आणि तुमच्याकडून कोणतेही प्रयत्न नाहीत. ॲप्लिकेशनमध्ये अनेक विभाजने असल्यास, जसे की रेकॉर्डिंग टाइम सीरीज डेटा, एक साधा अपग्रेड त्याच्या कार्यक्षमतेत लक्षणीय सुधारणा करेल.

ही एक "अपग्रेड आणि एन्जॉय" सुधारणा नसली तरी, PostgreSQL 12 तुम्हाला परकीय की तयार करण्यास परवानगी देते जे विभाजन केलेल्या टेबल्सचा संदर्भ देते, ज्यामुळे विभाजन कार्य करण्यास आनंद होतो.

प्रश्नांसह बरेच चांगले झाले

जेव्हा बिल्ट-इन कॉमन टेबल एक्सप्रेशनसाठी पॅच लागू केला होता (उर्फ CTE, उर्फ ​​प्रश्नांसह), मी याबद्दल लेख लिहिण्याची प्रतीक्षा करू शकत नाही PostgreSQL सह अनुप्रयोग विकसक किती आनंदी होते. हे अशा वैशिष्ट्यांपैकी एक आहे जे अनुप्रयोगास गती देईल. जोपर्यंत, अर्थातच, तुम्ही CTE वापरता.

मला असे आढळते की SQL मध्ये नवशिक्यांना CTEs वापरणे आवडते; जर तुम्ही त्यांना विशिष्ट पद्धतीने लिहित असाल, तर असे वाटते की तुम्ही एक अनिवार्य प्रोग्राम लिहित आहात. व्यक्तिशः, मला या प्रश्नांचा शोध घेण्यासाठी पुन्हा लिहायला आवडले न CTE आणि उत्पादकता वाढवा. आता सर्व काही वेगळे आहे.

PostgreSQL 12 तुम्हाला साइड इफेक्ट्सशिवाय विशिष्ट प्रकारचे CTE इनलाइन करण्याची परवानगी देते (SELECT), जे विनंतीच्या शेवटी एकदाच वापरले जाते. मी पुन्हा लिहिलेल्या CTE प्रश्नांचा मागोवा ठेवल्यास, त्यांपैकी बहुतेक या श्रेणीत येतात. हे विकसकांना स्पष्ट कोड लिहिण्यास मदत करते जे आता द्रुतपणे चालते.

शिवाय, PostgreSQL 12 तुम्हाला काहीही न करता, SQL अंमलबजावणी स्वतःच अनुकूल करते. आणि जरी मला आता अशा क्वेरी ऑप्टिमाइझ करण्याची आवश्यकता नसली तरी, पोस्टग्रेएसक्यूएल क्वेरी ऑप्टिमायझेशनवर कार्य करत आहे हे छान आहे.

जस्ट-इन-टाइम (JIT) - आता डीफॉल्ट

समर्थनासह PostgreSQL 12 प्रणालींवर एलएलव्हीएम डीफॉल्टनुसार JIT संकलन सक्षम केले आहे. सर्व प्रथम, आपल्याला समर्थन मिळेल JIT काही अंतर्गत ऑपरेशन्ससाठी, आणि दुसरे म्हणजे, निवडक याद्यांमधील अभिव्यक्ती (सर्वात सोपे उदाहरण x + y) असलेल्या क्वेरी (जे तुमच्याकडे SELECT नंतर आहे), एकत्रित, व्हेअर क्लॉजसह अभिव्यक्ती आणि इतर कामगिरी सुधारण्यासाठी JIT वापरू शकतात.

पोस्टग्रेएसक्यूएल 12 मध्ये डीफॉल्टनुसार जेआयटी सक्षम असल्याने, कार्यप्रदर्शन स्वतःच सुधारेल, परंतु क्वेरी कार्यप्रदर्शन मोजण्यासाठी आणि तुम्हाला काही ट्यून करण्याची आवश्यकता आहे का ते पाहण्यासाठी मी पोस्टग्रेएसक्यूएल 11 मधील अनुप्रयोगाची चाचणी करण्याची शिफारस करतो, ज्याने JIT सादर केला.

PostgreSQL 12 मधील उर्वरित नवीन वैशिष्ट्यांचे काय?

PostgreSQL 12 मध्ये एक टन नवीन वैशिष्ट्ये आहेत, मानक SQL/JSON मार्ग अभिव्यक्ती वापरून JSON डेटा तपासण्याच्या क्षमतेपासून ते पॅरामीटरसह बहु-घटक प्रमाणीकरणापर्यंत clientcert=verify-full, स्तंभ आणि बरेच काही तयार केले. वेगळ्या पोस्टसाठी पुरेसे आहे.

PostgreSQL 10 प्रमाणे, PostgreSQL 12 अपग्रेड नंतर लगेचच एकूण कामगिरी सुधारेल. तुमचा, अर्थातच, तुमचा स्वतःचा मार्ग असू शकतो - सुधारणा सक्षम करण्यापूर्वी उत्पादन प्रणालीवर समान परिस्थितीत अनुप्रयोगाची चाचणी घ्या, जसे मी PostgreSQL 10 सोबत केले. PostgreSQL 12 माझ्या अपेक्षेपेक्षा आधीच अधिक स्थिर असले तरीही, चाचणी करण्यात आळशी होऊ नका. ऍप्लिकेशन्स उत्पादनात सोडण्यापूर्वी त्यांना पूर्णपणे तपासा.

स्त्रोत: www.habr.com