PostgreSQL ओपन-सोर्सRDBMS स्पेस में बेजोड़ सुविधाओं के उत्कृष्ट सेट के साथ आता है। यह सीखना और उपयोग करना ज्यादातर आसान है, खासकर एप्लिकेशन डेवलपर्स के लिए। हालाँकि, कुछ भाग, ठीक है, बस आसान नहीं है। उन्हें सेटअप करने और सही होने के लिए कार्य की आवश्यकता होती है, और आमतौर पर मिशन-क्रिटिकल भी होते हैं।
कनेक्शन प्रबंधन
PostgreSQL ने एक नई प्रक्रिया शुरू की, जिसे बैकएंड प्रक्रिया . कहा जाता है , प्रत्येक कनेक्शन को संभालने के लिए। यह अन्य तुलनीय सर्वर सॉफ़्टवेयर में पाए जाने वाले आधुनिक, इवेंटलूप/थ्रेडपूल आधारित कनेक्शन हैंडलिंग आर्किटेक्चर के विपरीत है। एक पूरी प्रक्रिया को स्पॉन करने में अधिक समय और संसाधन लगता है, और उन अनुप्रयोगों में बढ़ी हुई क्वेरी विलंबता के रूप में प्रकट होता है जहां कनेक्शन उच्च दर पर खोले और बंद किए जाते हैं।
अधिकांश परिनियोजन में, किसी न किसी स्तर पर कनेक्शन की पूलिंग की आवश्यकता होती है। एप्लिकेशन स्तर पर, यह आपकी प्रोग्रामिंग भाषा/लाइब्रेरी सुविधाओं का उपयोग कर सकता है। उदाहरण के लिए sql/DB.SetMaxIdleConns का उपयोग एकल गो एप्लिकेशन के भीतर कनेक्शन पुन:उपयोग को बढ़ाने के लिए किया जा सकता है।
हालांकि अक्सर, आपको तीसरे पक्ष के कनेक्शन पूलिंग या लोड बैलेंसिंग समाधान का उपयोग करना होगा। कनेक्शन पूलर अपस्ट्रीम पोस्टग्रेज सर्वर के लिए निष्क्रिय कनेक्शन का एक पूल बनाए रखते हैं, जो आने वाले क्लाइंट कनेक्शन के लिए असाइन और प्रॉक्सी किए जाते हैं। वे आम तौर पर क्लाइंट द्वारा भेजे गए SQL को लेन-देन की सीमाओं और डेटा-संशोधित DML को लेन-देन-स्तर कनेक्शन पूलिंग जैसी सुविधाओं को लागू करने और प्रतिकृतियां पढ़ने के लिए पार्स करते हैं।
PgBouncer एक लोकप्रिय, हल्का, सिंगल-बाइनरीकनेक्शन पूलर है और अक्सर उसी सिस्टम में PostgreSQL के साथ चलाया जाता है।
PgPool, PgBouncer की तुलना में अधिक बहुमुखी है। उदाहरण के लिए यह लोड संतुलन और प्रतिकृति भी कर सकता है।
कनेक्शन पूलिंग हालांकि सिरदर्द का अपना सेट लाता है। सबसे पहले, यह एक अतिरिक्त गतिशील हिस्सा है जिसे आपके परिनियोजन में बनाए रखा गया है। यदि आपके पास अलग-अलग क्रेडेंशियल्स या प्रमाणीकरण तंत्रों का उपयोग करने वाले क्लाइंट हैं, तो अपऑथेंटिकेशन सेट करना भी एक दर्द है। कुछ कनेक्शन-स्तरीय सुविधाएँ जैसे LISTEN/NOTIFY, तैयार स्टेटमेंट, अस्थायी टेबल और इसी तरह काम करने के लिए अतिरिक्त कॉन्फ़िगरेशन या क्लाइंट-साइडचेंज की आवश्यकता हो सकती है।
शून्य डाउनटाइम अपग्रेड
छोटे संस्करणों (13.x -> 13.y) के बीच PostgreSQL को अपग्रेड करने में नए पैकेज की स्थापना और सर्वर प्रक्रिया को पुनरारंभ करना शामिल है। सर्वर प्रक्रिया को फिर से शुरू करते समय सभी जुड़े हुए ग्राहकों को अनिवार्य रूप से बाधित कर दिया जाएगा, यह अभी भी एक उचित सवाल है, यह देखते हुए कि डाउनटाइम एक सेवा पुनरारंभ की अवधि के लिए बाध्य है।
हालांकि, प्रमुख (12.x -> 13.y) संस्करणों के बीच अपग्रेड करना बहुत बड़ी बात है। आमतौर पर, जितना अधिक डेटा होता है, प्रक्रिया उतनी ही अधिक दर्दनाक होती है।
सबसे सरल तरीका, जो केवल कम मात्रा में डेटा (जैसे दसियों जीबी) के लिए काम करता है, पुराने संस्करण से डेटा को डंप करना और इसे नए संस्करण सर्वर में पुनर्स्थापित करना है। दूसरा विकल्प pg_upgrad का उपयोग करना है, जिसके लिए एक ऑर्केस्ट्रेटेड डांस की आवश्यकता होती है। Postgres के दोनों संस्करणों के बायनेरिज़ को शामिल करना।
किसी भी स्थिति में, डेटाबेस काफी समय के लिए बंद हो जाएगा।
आदर्श रूप से, एक नए संस्करण सर्वर को दोहराना संभव होना चाहिए, और नए संस्करण सर्वर को प्राथमिक के रूप में बढ़ावा देना चाहिए। हालांकि, एक अलग प्रमुख संस्करण के साथ एक स्टैंडबाय सर्वर के लिए स्ट्रीमिंग प्रतिकृति करना संभव नहीं है। तार्किक प्रतिकृति, जबकि यह नौकरी के लिए अच्छी तरह से अनुकूल दिखती है, इसमें कुछ गॉचा हैं जिन्हें पूर्ण प्रतिकृति सुनिश्चित करने के लिए चारों ओर काम करने की आवश्यकता है।
Postgres के लिए अधिकांश HA समाधान स्ट्रीमिंग प्रतिकृति पर निर्भर करते हैं, और इसलिए आप एक बार में एक क्लस्टर में नोड्स को अपग्रेड नहीं कर सकते हैं।
कला की वर्तमान स्थिति तार्किक प्रतिकृति का उपयोग करने के लिए होगी, जबकि तार्किक प्रतिकृति की सीमाओं के आसपास काम करते हुए, और संभवत:उन प्रतिबंधित सुविधाओं को शामिल करना जो कि उन्नयन चरण के दौरान अनुप्रयोगों (जैसे डीडीएल) का उपयोग कर सकते हैं।
उच्च उपलब्धता
PostgreSQL एक HA समाधान के निर्माण के लिए आवश्यक सभी निम्न-स्तरीय सुविधाओं के साथ आता है:फीडबैक के साथ प्रतिकृति, कैस्केडिंग प्रतिकृति, सिंक्रोनस प्रतिकृति, स्टैंडबाय, हॉट स्टैंडबाय, स्टैंडबाय प्रमोशन आदि। हालांकि, यह वास्तव में बॉक्स से बाहर एचए समाधान प्रदान नहीं करता है। स्वास्थ्य की निगरानी के लिए कोई ढांचा या उपकरण नहीं हैं और स्वचालित रूप से स्टैंडबाय में विफल हो जाते हैं। मल्टी-नोड एचए क्लस्टर की कोई धारणा नहीं है।
उच्च उपलब्धता पोस्टग्रेज़ परिनियोजन बनाने के लिए आपको एक तृतीय-पक्ष समाधान सेटअप और चलाना होगा। वर्तमान पसंदीदा हैंpg_auto_failoverand Patroni। जबकि पेट्रोनी ज़ूकीपर या आदि जैसे मौजूदा उच्च-उपलब्ध कॉन्फ़िगरेशन स्टोर पर निर्भर है, pg_auto_failover एक के बिना भी कर सकता है।
उत्पादन में इनमें से किसी एक का मूल्यांकन, परिनियोजन और परीक्षण करने में समय और प्रयास लगता है। मॉनिटरिंग, अलर्टिंग और ऑप्स प्लेबुक्स को सेटअप और मेंटेन करना होता है।
ब्लोट प्रबंधन
पोस्टग्रेएसक्यूएल के एमवीसीसी आर्किटेक्चर का मतलब है कि कोई भी डेटा कभी भी ओवरराइट नहीं किया जाता है - एक पंक्ति को संशोधित करने से केवल पंक्ति का एक नया संस्करण टूडिस्क लिखा जाता है। एक पंक्ति को हटाने का मतलब केवल यह रिकॉर्ड करना है कि पंक्ति भविष्य के लेन-देन के लिए अदृश्य है। जब एक पंक्ति संस्करण किसी भी चल रहे या भविष्य के लेन-देन से पहुंच योग्य नहीं है, तो यह अब किसी काम का नहीं है, और इसे "ब्लोट" कहा जाता है। इस ब्लोट को कचरा इकट्ठा करने की प्रक्रिया को "वैक्यूम" कहा जाता है।
ब्लोट अनुप्रयोगों के लिए अदृश्य है, और पूरी तरह से डीबीए का सिरदर्द बन जाता है। अद्यतन-भारी तालिकाओं के लिए, ब्लोट की निगरानी और प्रबंधन एक गैर-तुच्छ मुद्दा है। ऑटोवैक्यूम प्रक्रिया बहुत मदद करती है, लेकिन इसकी थ्रेसहोल्ड को वैश्विक या प्रति- तालिका स्तर सुनिश्चित करने के लिए तालिका आकार अनियंत्रित रूप से बड़े नहीं होते हैं।
इंडेक्स भी ब्लोट से प्रभावित होते हैं, और ऑटोवैक्यूम यहां मदद नहीं करता है। पंक्तियों को हटाने और अनुक्रमित स्तंभों के अद्यतन से अनुक्रमणिका में मृत प्रविष्टियाँ होती हैं। इंडेक्स किए गए कॉलम में अपडेट के साथ भारी वर्कलोड लगातार बढ़ते और अक्षम इंडेक्स को जन्म दे सकता है। इंडेक्स के लिए वैक्यूम के बराबर नहीं है। एकमात्र उपाय यह है कि REINDEX का उपयोग करके पूरे इंडेक्स को फिर से बनाया जाए या टेबल पर VACUUM FULL का उपयोग किया जाए।
प्रति तालिका एक मान के अलावा (pg_stat_all_tables.n_dead_tup), Postgres तालिका में ब्लोट का अनुमान लगाने के तरीके में कुछ भी नहीं देता है, और इंडेक्स के लिए कुछ भी नहीं। सबसे व्यावहारिक तरीका अभी भी check_postgres से डरावनी दिखने वाली क्वेरी को निष्पादित करना है।
pgmetrics check_postgres से क्वेरी को शामिल करता है, और JSON और CSV प्रारूप आउटपुट का उत्पादन कर सकता है जिसमें सभी टेबल और इंडेक्स के लिए आकार और ब्लोट जानकारी शामिल है; जिसे मॉनिटरिंग या ऑटोमेशन टूल में फीड किया जा सकता है।
pg_repack VACUUM FULL का एक लोकप्रिय विकल्प है - यह वही काम कर सकता है लेकिन बिना ताले के। यदि आपको नियमित रूप से VACUUM FULL करने के लिए मजबूर किया जाता है, तो यह एक आवश्यक जाँच उपकरण है।
पोस्टग्रेज़ के लिए ज़ीप नया स्टोरेज इंजन है जो वर्षों से विकास में है, जो इन-प्लेस अपडेट के माध्यम से ब्लोट को कम करने का वादा करता है।
क्वेरी प्लान मैनेजमेंट
Core PostgreSQL इस स्थान में केवल दो प्राथमिक उपकरण प्रदान करता है:
- pg_stat_statements क्वेरी एनालिटिक्स के लिए एक्सटेंशन - यह क्वेरी प्लानिंग और निष्पादन समय, डिस्क और मेमोरी उपयोग का कुल और औसत देता है
- auto_explain एक्सटेंशन, जो क्वेरी निष्पादन योजनाओं को पोस्टग्रेज लॉग डेस्टिनेशन में प्रिंट कर सकता है
जबकि pg_stat_statements द्वारा प्रदान किए गए आँकड़े auto_explain का उपयोग करके प्राप्त करने के लिए पर्याप्त हैं लॉग फ़ाइलों में योजनाओं को लागू करने के लिए और फिर उन्हें निकालने के लिए वास्तव में एक हैक से अधिक नहीं है, विशेष रूप से वाणिज्यिक प्रतियोगियों की तुलना में पोस्टग्रेज के लिए, जो योजना इतिहास, आधारभूत और प्रबंधन सुविधाओं की पेशकश करते हैं।
Postgres के साथ कला की वर्तमान स्थिति लॉग फ़ाइल forquery योजनाओं को माइन करना और उन्हें कहीं और स्टोर करना है। लेकिन शायद सबसे अधिक बाधा समस्या pg_stat_statements से संबंधित विश्लेषण के साथ क्वेरी योजना को संबद्ध करने में सक्षम नहीं है। जिस तरह से pgDash ऐसा करता है, वह pg_stat_statements औरauto_explain आउटपुट से दोनों SQL क्वेरी टेक्स्ट को पार्स करना है, pg_stat_statements द्वारा किए गए मैंगलिंग के लिए समायोजित करना है, और दोनों का मिलान करने का प्रयास करना है। इसके लिए एक पूर्ण PostgreSQL-बोली SQL पार्सर की आवश्यकता है।
वर्तमान में कोर पोस्टग्रेएसक्यूएल में बेसलाइनिंग, योजना चयन के लिए नीतियां निर्धारित करना आदि संभव नहीं हैं।
वहाँ कुछ एक्सटेंशन हैं जो मूल रूप से pg_stat_statements के बेहतर संस्करण हैं, लेकिन तीसरे पक्ष के एक्सटेंशन का उपयोग करने में शामिल अतिरिक्त कदम इसे अधिकांश लोगों के लिए एक चुनौती बनाते हैं, खासकर यदि वे एक प्रबंधित पोस्टग्रेज प्रदाता का उपयोग कर रहे हैं।
ट्यूनिंग
PostgreSQL में ट्यूनिंग विकल्पों की अधिकता है, जो कि अंडर-कॉन्फ़िगर-बाय-डिफॉल्टशेयर्ड_बफ़र्ससेटिंग से शुरू होता है। कुछ को समझना और सेट करना आसान है, जैसे विभिन्न कार्यों के लिए समानांतर श्रमिकों की संख्या (max_worker_processes, max_parallel_* आदि)। अन्य क्षेत्र थोड़ा अस्पष्ट है (wal_compression, random_page_cost आदि) लेकिन आम तौर पर फायदेमंद। हालांकि, सबसे अधिक परेशान करने वाले वे हैं जिन्हें कार्यभार के बारे में मात्रात्मक जानकारी की आवश्यकता होती है।
उदाहरण के लिए, यदि work_mem बहुत कम है, प्रश्न अस्थायी डिस्क फ़ाइलों का उपयोग कर सकते हैं; यदि बहुत अधिक है, और एक साथ पर्याप्त प्रश्न हैं, तो पोस्टग्रेज बैकएंडप्रोसेस ओओएम-मारे जा सकते हैं। तो आप कैसे पता लगाते हैं कि इसे किस नंबर पर सेट करना है?
व्यावहारिक रूप से, विशेष रूप से ओएलटीपी वर्कलोड और वेब-एप्लिकेशन वर्कलोड के साथ, यह अनुमान लगाना असंभव है कि प्रश्नों के लिए पीक मेमोरी डिमांड क्या होगी। आपकी सबसे अच्छी शर्त यह है कि इसे एक उचित मूल्य निर्धारित किया जाए, फिर प्रश्नों की निगरानी करके देखें कि क्या उनमें से कोई work_mem के उच्च मूल्य से लाभान्वित हो सकता है।
और आप वह कैसे करते हैं? आपको एक्सटेंशन auto_explain प्राप्त करना होगा प्रत्येक क्वेरी की क्वेरी निष्पादन योजनाओं को लॉग करने के लिए, पोस्टग्रेज़ की लॉग फ़ाइलों से उन्हें निकालें, यह देखने के लिए प्रत्येक क्वेरी योजना की जांच करें कि क्या यह डिस्क-आधारित बाहरी मर्ज या हानिपूर्ण हीप ब्लॉक के साथ बिटमैप हीप स्कैन का उपयोग करता है।
असंभव नहीं, बस कठिन।
