लेख का अनुवाद विशेष रूप से पाठ्यक्रम के छात्रों के लिए तैयार किया गया था "डेटाबेस". क्या आप इस दिशा में विकास करने में रुचि रखते हैं? हम आपको आमंत्रित करते हैं खुला दिन, जहां हम कार्यक्रम, ऑनलाइन प्रारूप की विशेषताओं, दक्षताओं और कैरियर की संभावनाओं के बारे में विस्तार से बात करते हैं जो प्रशिक्षण के बाद स्नातकों की प्रतीक्षा करते हैं।

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

मुझे इसकी आवश्यकता क्यों है?

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

समझौता से मिलें

आपको डेटा स्थिरता और प्रदर्शन के बीच समझौता करना होगा। PostgreSQL स्थिरता से दूर चला जाता है क्योंकि डिफ़ॉल्ट कॉन्फ़िगरेशन तब पूर्वानुमानित और अप्रत्याशित आश्चर्य के बिना होता है। अब आइए समझौतों पर नजर डालें।

ट्रेडऑफ़ 1: प्रदर्शन

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

ट्रेडऑफ़ 2: संगति

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

सिंक्रोनस मोड में ऐसा नहीं होता है. यदि लीडर विफल हो जाता है, तो सभी प्रतिकृतियां अपडेट कर दी जाती हैं, क्योंकि लीडर पर किसी भी लेख की पुष्टि प्रतिकृतियों पर की जानी चाहिए। यह एकरूपता है.

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

ट्रेड-ऑफ 3: क्रैश

यह समझना बहुत महत्वपूर्ण है कि विफलता के दौरान क्लस्टर कैसे व्यवहार करता है। ऐसी स्थिति पर विचार करें जहां एक या अधिक प्रतिकृतियां विफल हो जाएं. जब कमिट को एसिंक्रोनस रूप से संसाधित किया जाता है, तो लीडर कार्य करना जारी रखेगा, यानी लापता प्रतिकृतियों की प्रतीक्षा किए बिना, स्वीकार करेगा और लिखने की प्रक्रिया करेगा। जब प्रतिकृतियां क्लस्टर में लौटती हैं, तो वे लीडर से मिल जाती हैं। सिंक्रोनस प्रतिकृति के साथ, यदि प्रतिकृतियां प्रतिक्रिया नहीं देती हैं, तो नेता के पास कोई विकल्प नहीं होगा और वह प्रतिबद्धता की पुष्टि के लिए इंतजार करना जारी रखेगा जब तक कि प्रतिकृति क्लस्टर में वापस न आ जाए और लेखन को स्वीकार और प्रतिबद्ध न कर सके।

प्रति लेनदेन एक कनेक्शन?

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

बेशक, ये सभी निर्णय एप्लिकेशन डेवलपर द्वारा लिए जाते हैं। प्रत्येक दृष्टिकोण का उपयोग कब करना है, इसके बारे में सही निर्णय लेने से आपको अपने क्लस्टर से अधिकतम लाभ उठाने में मदद मिलेगी। यह महत्वपूर्ण है कि डेवलपर कनेक्शन और लेनदेन के लिए SQL स्तर पर उनके बीच स्विच कर सके।

व्यवहार में नियंत्रण सुनिश्चित करना

डिफ़ॉल्ट रूप से, PostgreSQL स्थिरता प्रदान करता है। इसे सर्वर पैरामीटर द्वारा नियंत्रित किया जाता है synchronous_commit. डिफ़ॉल्ट रूप से यह स्थिति में है on, लेकिन इसके तीन अन्य विकल्प हैं: local, remote_write या off.

पैरामीटर सेट करते समय off सभी सिंक्रोनस कमिट रोक दिए गए हैं, यहां तक ​​कि स्थानीय सिस्टम पर भी। स्थानीय पैरामीटर स्थानीय सिस्टम के लिए सिंक्रोनस मोड निर्दिष्ट करता है, लेकिन प्रतिकृतियों पर लिखना एसिंक्रोनस रूप से किया जाता है। Remote_write इससे भी आगे जाता है: प्रतिकृतियों पर लिखना अतुल्यकालिक रूप से किया जाता है, लेकिन तब लौटाया जाता है जब प्रतिकृति ने लेखन को स्वीकार कर लिया है लेकिन इसे डिस्क पर नहीं लिखा है।

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

अब, हम आपको एक क्षण में बताएंगे कि इसे कैसे सेट किया जाए, लेकिन कल्पना करें कि हमने सेट अप किया है synchronous_commit в local सर्वर के लिए. हमें आश्चर्य हुआ कि क्या पैरामीटर को बदलना संभव है synchronous_commit तुरंत, और यह पता चला कि यह न केवल संभव है, बल्कि इसे करने के दो तरीके भी हैं। सबसे पहले अपने कनेक्शन का सत्र इस प्रकार सेट करें:

SET SESSION synchronous_commit TO ON;  
// Your writes go here

सत्र में बाद के सभी लेखन कनेक्टेड क्लाइंट को सकारात्मक परिणाम देने से पहले प्रतिकृतियों पर लिखे गए लेखन को स्वीकार करेंगे। जब तक आप निश्चित रूप से सेटिंग नहीं बदलते synchronous_commit दोबारा। आप भाग को छोड़ सकते हैं SESSION कमांड में क्योंकि यह डिफ़ॉल्ट मान में होगा।

दूसरी विधि तब अच्छी होती है जब आप केवल यह सुनिश्चित करना चाहते हैं कि आपको एकल लेनदेन के लिए समकालिक प्रतिकृति मिले। कई NoSQL जेनरेशन डेटाबेस में लेनदेन की अवधारणा मौजूद नहीं है, लेकिन PostgreSQL में यह मौजूद है। इस स्थिति में आप लेनदेन शुरू करते हैं और फिर सेट करते हैं synchronous_commit в on लेन-देन के लिए प्रविष्टि निष्पादित करने से पहले। COMMIT किसी भी पैरामीटर मान का उपयोग करके लेनदेन करेगा synchronous_commit, जो उस समय सेट किया गया था, हालांकि यह सुनिश्चित करने के लिए वेरिएबल को अग्रिम रूप से सेट करना सबसे अच्छा है कि अन्य डेवलपर्स समझें कि राइट्स एसिंक्रोनस नहीं हैं।

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Your writes go here
COMMIT;  

इससे पहले कि डेटाबेस कनेक्टेड क्लाइंट को सकारात्मक प्रतिक्रिया दे, सभी लेन-देन प्रतिबद्धताओं की प्रतिकृतियों में लिखी गई पुष्टि की जाएगी।

PostgreSQL को कॉन्फ़िगर करना

इससे पहले, हमने एक PostgreSQL प्रणाली की कल्पना की थी synchronous_commit, में स्थापित local. सर्वर साइड पर इसे यथार्थवादी बनाने के लिए, आपको दो सर्वर कॉन्फ़िगरेशन विकल्प सेट करने की आवश्यकता होगी। एक और पैरामीटर synchronous_standby_names जब अपने आप में आ जायेगा synchronous_commit में होगा on. यह निर्धारित करता है कि कौन सी प्रतिकृतियां सिंक्रोनस कमिट के लिए योग्य हैं, और हम इसे सेट करेंगे *, जिसका मतलब यह होगा कि सभी प्रतिकृतियां शामिल हैं। ये मान आमतौर पर कॉन्फ़िगर किए जाते हैं विन्यास फाइल जोड़कर:

synchronous_commit = local  
synchronous_standby_names='*'

पैरामीटर सेट करके synchronous_commit अर्थ में local, हम एक ऐसा सिस्टम बनाते हैं जहां स्थानीय डिस्क सिंक्रोनस रहती हैं, लेकिन नेटवर्क रेप्लिका कमिट डिफ़ॉल्ट रूप से एसिंक्रोनस होती हैं। जब तक, निश्चित रूप से, हम इन प्रतिबद्धताओं को समकालिक बनाने का निर्णय नहीं लेते, जैसा कि ऊपर दिखाया गया है।

यदि आप विकास का अनुसरण कर रहे हैं राज्यपाल परियोजना, आपने हाल के कुछ बदलावों पर गौर किया होगा (1, 2), जिसने गवर्नर उपयोगकर्ताओं को इन मापदंडों का परीक्षण करने और उनकी स्थिरता की निगरानी करने की अनुमति दी।

कुछ और शब्द...

ठीक एक सप्ताह पहले, मैंने आपको बताया होगा कि PostgreSQL को इतनी सूक्ष्मता से ठीक करना असंभव है। तभी कंपोज़ प्लेटफ़ॉर्म टीम के एक सदस्य कर्ट ने जोर देकर कहा कि ऐसा अवसर मौजूद है। उन्होंने मेरी आपत्तियों को शांत किया और PostgreSQL दस्तावेज़ में पाया निम्नलिखित:

इस सेटिंग को किसी भी समय बदला जा सकता है. किसी भी लेन-देन का व्यवहार प्रतिबद्धता के समय प्रभावी सेटिंग द्वारा निर्धारित होता है। इसलिए, कुछ लेनदेन के लिए समकालिक रूप से और अन्य के लिए अतुल्यकालिक रूप से प्रतिबद्ध होना संभव और उपयोगी है। उदाहरण के लिए, किसी को मजबूर करना multistatement जब पैरामीटर का डिफ़ॉल्ट मान विपरीत हो, तो अतुल्यकालिक रूप से लेनदेन करने के लिए सेट करें SET LOCAL synchronous_commit TO OFF एक लेन-देन में.

कॉन्फ़िगरेशन फ़ाइल में इस छोटे से संशोधन के साथ, हमने उपयोगकर्ताओं को उनकी स्थिरता और प्रदर्शन पर नियंत्रण दिया।

स्रोत: www.habr.com