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

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

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

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

समझौता पूरा करें

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

समझौता 1: प्रदर्शन

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

समझौता 2: संगति

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

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

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

समझौता 3: विफलताओं

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

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

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

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

व्यवहार में नियंत्रण प्रदान करना

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

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

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

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

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

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

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

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

डेटाबेस से जुड़े क्लाइंट के प्रति सकारात्मक प्रतिक्रिया देने से पहले सभी लेनदेन के कमिट की पुष्टि अब प्रतिकृतियों से की जाएगी।

PostgreSQL सेटअप

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

 synchronous_commit = local synchronous_standby_names='*' 

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

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

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

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

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

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