PostgreSQL के लिए एक इष्टतम वातावरण की स्थापना

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

जब एक नया सर्वर स्थापित किया जाता है, तो PostgreSQL की सेटिंग्स बहुत न्यूनतम होती हैं क्योंकि उन्हें कम से कम संभव हार्डवेयर पर चलाने के लिए डिज़ाइन किया गया है। हालांकि वे बहुत ही कम इष्टतम हैं। यहां, हम नई परियोजनाओं के लिए एक बुनियादी सेटअप पर जाएंगे, और नई परियोजनाओं पर सबसे बेहतर तरीके से चलाने के लिए PostgreSQL को कैसे सेट करें।

होस्टिंग

ऑन-प्रिमाइसेस होस्टिंग

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

बादल

क्लाउड में डेटाबेस होस्ट करना कुछ पहलुओं में अद्भुत हो सकता है, या दूसरों में एक बुरा सपना हो सकता है। जब तक चुना गया क्लाउड प्लेटफ़ॉर्म अत्यधिक अनुकूलित नहीं होता (जिसका अर्थ आमतौर पर उच्च कीमत होता है), उसे उच्च लोड वातावरण में समस्या हो सकती है। क्लाउड सर्वर साझा या समर्पित है या नहीं (एप्लिकेशन के लिए सर्वर से पूर्ण प्रदर्शन की अनुमति देने के लिए समर्पित), साथ ही साथ क्लाउड सर्वर द्वारा प्रदान किए गए आईओपीएस (इनपुट/आउटपुट ऑपरेशंस प्रति सेकेंड) के स्तर पर नज़र रखें। जब (या यदि) एप्लिकेशन इस बिंदु तक बढ़ता है कि अधिकांश डेटा मेमोरी में संग्रहीत नहीं किया जा सकता है, तो डिस्क एक्सेस गति महत्वपूर्ण है।

सामान्य होस्ट सेटअप

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

ऑपरेटिंग सिस्टम चुनना

PostgreSQL को अधिकांश यूनिक्स जैसे ऑपरेटिंग सिस्टम, साथ ही विंडोज़ पर संकलित किया जा सकता है। हालांकि विंडोज़ पर प्रदर्शन यूनिक्स जैसी प्रणाली के बराबर भी नहीं है, इसलिए जब तक कि यह एक छोटी फेंकने वाली परियोजना के लिए न हो, एक स्थापित यूनिक्स जैसी प्रणाली से चिपके रहना ही रास्ता होगा। इस चर्चा के लिए, हम Linux आधारित सिस्टम से चिपके रहेंगे।

पोस्टग्रेएसक्यूएल की मेजबानी के लिए इस्तेमाल किया जाने वाला सबसे ज्यादा इस्तेमाल किया जाने वाला लिनक्स वितरण एक Red Hat आधारित प्रणाली है, जैसे CentOS या वैज्ञानिक लिनक्स, या यहां तक ​​​​कि Red Hat भी। चूंकि Red Hat और CentOS स्थिरता और प्रदर्शन पर ध्यान केंद्रित करते हैं, इसलिए इन परियोजनाओं के पीछे का समुदाय यह सुनिश्चित करने के लिए कड़ी मेहनत करता है कि महत्वपूर्ण अनुप्रयोग, जैसे डेटाबेस, Linux के सबसे सुरक्षित और सबसे विश्वसनीय निर्माण पर हों।

नोट:लिनक्स में कर्नेल संस्करणों की एक श्रृंखला है जो PostgreSQL चलाने के लिए इष्टतम नहीं हैं, इसलिए यदि संभव हो तो उन्हें टालने का अत्यधिक सुझाव दिया जाता है (विशेषकर उन अनुप्रयोगों पर जहां चरम प्रदर्शन अत्यंत महत्वपूर्ण है)। बेंचमार्क ने दिखाया है कि कर्नेल संस्करण 3.4 - 3.10 से प्रति सेकंड लेनदेन की संख्या कम हो जाती है, लेकिन कर्नेल 3.12 में ठीक हो जाता है और काफी सुधार होता है। यह दुर्भाग्य से CentOS 7 का उपयोग करने से रोकता है यदि CentOS मार्ग पर जा रहा है। CentOS 6 अभी भी ऑपरेटिंग सिस्टम का एक मान्य और समर्थित संस्करण है, और 6 के असमर्थित होने से पहले CentOS 8 के रिलीज़ होने की उम्मीद है।

इंस्टॉलेशन

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

सीपीयू

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

शुरू करने के लिए एक अच्छी आधार रेखा एक छोटे से अनुप्रयोग के लिए 4 कोर प्रणाली है। यह मानते हुए कि एप्लिकेशन प्रश्नों को निष्पादित करने और सोने के बीच एक नृत्य करते हैं, एक 4 कोर सिस्टम अतिभारित होने से पहले कुछ दर्जन कनेक्शनों को संभाल सकता है। अधिक कोर जोड़ने से बढ़ते कार्यभार के साथ पैमाने में मदद मिलेगी। बहुत बड़े पोस्टग्रेएसक्यूएल डेटाबेस में सैकड़ों कनेक्शनों की सेवा के लिए 48+ कोर होना असामान्य नहीं है।

ट्यूनिंग युक्तियाँ: हाइपर-थ्रेडिंग उपलब्ध होने पर भी, हाइपर-थ्रेडिंग अक्षम होने पर प्रति सेकंड लेन-देन आम तौर पर अधिक होता है। डेटाबेस क्वेरी के लिए जो बहुत जटिल नहीं हैं, लेकिन आवृत्ति में अधिक हैं, तेज़ कोर की तुलना में अधिक कोर अधिक महत्वपूर्ण हैं।

स्मृति

PostgreSQL के समग्र प्रदर्शन के लिए मेमोरी एक अत्यंत महत्वपूर्ण पहलू है। मेमोरी के संदर्भ में PostgreSQL के लिए मुख्य सेटिंग शेयर्ड_बफ़र्स है, जो डेटा कैशिंग के लिए सीधे PostgreSQL सर्वर को आवंटित मेमोरी का एक हिस्सा है। आवश्यक डेटा की मेमोरी में रहने की संभावना जितनी अधिक होगी, क्वेरीज़ उतनी ही तेज़ी से वापस आती हैं, और तेज़ क्वेरीज़ का अर्थ है एक अधिक कुशल CPU कोर सेटअप जैसा कि पिछले अनुभाग में चर्चा की गई है।

क्वेरी को, कभी-कभी, क्लाइंट को डेटा वापस करने से पहले डेटा पर सॉर्टिंग ऑपरेशन करने के लिए मेमोरी की आवश्यकता होती है। यह या तो अतिरिक्त एड-हॉक मेमोरी (shared_buffers से अलग) या डिस्क पर अस्थायी फ़ाइलों का उपयोग करता है, जो बहुत धीमी होती है।

ट्यूनिंग युक्तियाँ: Shared_buffers सेट करने के लिए एक मूल प्रारंभिक बिंदु इसे उपलब्ध सिस्टम रैम के मान के 1/4 वें स्थान पर सेट करना है। यह ऑपरेटिंग सिस्टम को डेटा की अपनी कैशिंग करने की अनुमति देता है, साथ ही डेटाबेस के अलावा किसी भी चल रही प्रक्रिया को भी करता है।

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

'फ्री' कमांड (जैसे 'फ्री-एच') का उपयोग करके, प्रभावी_कैश_साइज को फ्री और कैश्ड मेमोरी के योग पर सेट करें। इससे क्वेरी प्लानर को पता चलता है कि OS कैशिंग का स्तर उपलब्ध हो सकता है, और बेहतर क्वेरी प्लान चला सकता है।

डिस्क

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

डिस्क में कुछ तैयारी संभावित प्रदर्शन को तुरंत सुधारने में मदद कर सकती है, साथ ही भविष्य में विकास के लिए डेटाबेस सिस्टम का प्रमाण दे सकती है।

• डिस्क अलग करें

  PostgreSQL का एक नया इंस्टालेशन सिस्टम पर उपलब्ध मुख्य (और संभवतः केवल) ड्राइव पर कहीं न कहीं क्लस्टर की डेटा निर्देशिका बनाएगा।

  अधिक ड्राइव का उपयोग करने वाला एक मूल सेटअप एक अलग ड्राइव (या RAID के माध्यम से ड्राइव का सेट) जोड़ना होगा। इसे मुख्य ऑपरेटिंग सिस्टम से भिन्न I/O चैनल पर संचालित सभी डेटाबेस संबंधी डेटा स्थानांतरण होने का लाभ है। यह डेटाबेस को ऑपरेटिंग सिस्टम में कहीं और समस्याओं और त्रुटियों के कारण अपर्याप्त स्थान के डर के बिना बढ़ने की अनुमति देता है।

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

• RAID का उपयोग करना

  डेटाबेस ड्राइव के लिए RAID सेट करना न केवल डेटा हानि से बचाता है, यह सही RAID कॉन्फ़िगरेशन का उपयोग करने पर प्रदर्शन में सुधार भी कर सकता है। RAID 1 या 10 को आम तौर पर सबसे अच्छा माना जाता है, और 10 समता और समग्र गति प्रदान करता है। RAID 5, हालांकि, उच्च स्तर की अतिरेक होने के कारण, कई डिस्क के आसपास डेटा फैलाने के तरीके के कारण महत्वपूर्ण प्रदर्शन में कमी आती है। डेटा वृद्धि के लिए पर्याप्त स्थान के साथ उपलब्ध सर्वोत्तम विकल्प की योजना बनाएं, और यह एक ऐसा कॉन्फ़िगरेशन होगा जिसे अक्सर बदलने की आवश्यकता नहीं होगी, यदि बिल्कुल भी।

• SSD का उपयोग करना

  सॉलिड स्टेट ड्राइव प्रदर्शन के लिए अद्भुत हैं, और यदि वे बजट को पूरा करते हैं, तो एंटरप्राइज़ एसएसडी भारी डेटा प्रोसेसिंग वर्कलोड को रात और दिन तेज कर सकता है। छोटे से मध्यम कार्यभार वाले छोटे से मध्यम डेटाबेस अधिक हो सकते हैं, लेकिन बड़े अनुप्रयोगों पर सबसे छोटी प्रतिशत वृद्धि के लिए लड़ते समय, एसएसडी वह चांदी की गोली हो सकती है।

ट्यूनिंग युक्तियाँ: एक ऐसा ड्राइव सेटअप चुनें जो मौजूदा एप्लिकेशन के लिए सबसे अच्छा हो और जिसमें डेटा बढ़ने के साथ-साथ बढ़ने के लिए पर्याप्त जगह हो।

यदि SSD का उपयोग कर रहे हैं, तो random_page_cost को 1.5 या 2 पर सेट करना (डिफ़ॉल्ट 4 है) क्वेरी प्लानर के लिए फायदेमंद होगा, क्योंकि रैंडम डेटा फ़ेचिंग स्पिनिंग डिस्क पर देखे जाने की तुलना में बहुत तेज़ है।

प्रारंभिक कॉन्फ़िगरेशन सेटिंग

पहली बार PostgreSQL की स्थापना करते समय, कुछ मुट्ठी भर कॉन्फ़िगरेशन सेटिंग्स होती हैं जिन्हें होस्ट की शक्ति के आधार पर आसानी से बदला जा सकता है। जैसा कि एप्लिकेशन समय के साथ डेटाबेस से पूछताछ करता है, एप्लिकेशन की जरूरतों के आधार पर विशिष्ट ट्यूनिंग की जा सकती है। हालांकि यह एक अलग ट्यूनिंग ब्लॉग का विषय होगा।

मेमोरी सेटिंग

shared_buffers:सिस्टम मेमोरी के 1/4 भाग पर सेट करें। अगर सिस्टम में कुल मेमोरी का 1GB से कम है, तो सिस्टम की कुल मेमोरी के ~ 1/8वें हिस्से पर सेट करें

work_mem:डिफ़ॉल्ट 4MB है, और प्रश्न में आवेदन के लिए भी काफी हो सकता है। लेकिन अगर अस्थायी फ़ाइलें अक्सर बनाई जा रही हैं, और वे फ़ाइलें काफी छोटी हैं (दसियों मेगाबाइट्स), तो यह इस सेटिंग को ऊपर उठाने लायक हो सकती है। एक रूढ़िवादी प्रवेश स्तर सेटिंग (1/4 सिस्टम मेमोरी / max_connections) हो सकती है। यह सेटिंग डेटाबेस के वास्तविक व्यवहार और प्रश्नों की आवृत्ति पर अत्यधिक निर्भर करती है, इसलिए इसे केवल सावधानी के साथ बढ़ाया जाना चाहिए। यदि समस्याएँ आती हैं, तो इसे वापस पिछले स्तरों तक कम करने के लिए तैयार रहें।

प्रभावी_कैश_साइज:'फ्री' कमांड द्वारा रिपोर्ट की गई फ्री और कैश्ड मेमोरी के योग पर सेट करें।

चेकपॉइंट सेटिंग

PostgreSQL 9.4 और उससे नीचे के लिए:
checkpoint_segments:आगे लिखें लॉग सिस्टम देने के लिए कई चेकपॉइंट सेगमेंट (प्रत्येक में 16 मेगाबाइट)। डिफ़ॉल्ट 3 है, और इसे छोटे डेटाबेस के लिए भी सुरक्षित रूप से 64 तक बढ़ाया जा सकता है।

PostgreSQL 9.5 और इसके बाद के संस्करण के लिए:
max_wal_size:इसने checkpoint_segments को एक सेटिंग के रूप में बदल दिया। डिफ़ॉल्ट 1GB है, और आगे बदलाव की आवश्यकता होने तक यहां रह सकता है।

सुरक्षा

सुनो_एड्रेस:​​यह सेटिंग निर्धारित करती है कि कनेक्शन को सुनने के लिए कौन से व्यक्तिगत आईपी पते / नेटवर्क कार्ड हैं। एक साधारण सेटअप में, संभवतः केवल एक ही होगा, जबकि अधिक उन्नत नेटवर्क में एकाधिक नेटवर्क से कनेक्ट करने के लिए एकाधिक कार्ड हो सकते हैं। * का अर्थ है सब कुछ सुनना। हालाँकि, यदि डेटाबेस तक पहुँचने वाले एप्लिकेशन को उसी होस्ट पर डेटाबेस के रूप में रहना है, तो इसे 'लोकलहोस्ट' के रूप में रखना पर्याप्त है।

लॉगिंग

कुछ बुनियादी लॉगिंग सेटिंग्स जो लॉग को ओवरलोड नहीं करेंगी, वे इस प्रकार हैं।

log_checkpoints = on
log_connections = on
log_disconnections = on
log_temp_files = 0