लेखको अनुवाद पाठ्यक्रमका विद्यार्थीहरूको लागि विशेष गरी तयार गरिएको थियो "डाटाबेस"। यस दिशामा विकास गर्न इच्छुक हुनुहुन्छ? हामी तपाईंलाई निमन्त्रणा गर्दछौं खुल्ला दिन, जहाँ हामी कार्यक्रमको बारेमा विस्तृत रूपमा कुरा गर्छौं, अनलाइन ढाँचाका सुविधाहरू, दक्षताहरू र क्यारियर सम्भावनाहरू जुन प्रशिक्षण पछि स्नातकहरू पर्खिरहेका छन्।

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

मलाई किन चाहिन्छ?

क्लस्टरले कसरी व्यवहार गर्नुपर्छ भन्ने कुरा तपाईंको आवेदनमा निर्भर हुन्छ। उदाहरणका लागि, बिल भुक्तानी एप लिनुहोस्। तपाईलाई क्लस्टरमा XNUMX% स्थिरता चाहिन्छ, त्यसैले तपाईले सिंक्रोनस कमिटहरू सक्षम गर्नुपर्नेछ ताकि तपाईको डाटाबेसले सबै परिवर्तनहरू हुनको लागि पर्खन्छ। यद्यपि, यदि तपाईंको एप्लिकेसन द्रुत-बढ्दो सामाजिक सञ्जाल हो भने, तपाईंले सम्भवतः XNUMX% स्थिरता भन्दा छिटो प्रतिक्रियालाई प्राथमिकता दिनुहुनेछ। यो प्राप्त गर्न, तपाईं आफ्नो क्लस्टरमा एसिन्क्रोनस कमिटहरू प्रयोग गर्न सक्नुहुन्छ।

सम्झौता भेट्नुहोस्

तपाईंले डेटा स्थिरता र कार्यसम्पादनको बीचमा ट्रेडअफ बनाउनु पर्छ। PostgreSQL स्थिरताबाट टाढा जान्छ किनभने पूर्वनिर्धारित कन्फिगरेसन त्यसपछि अनुमानित र अप्रत्याशित आश्चर्य बिना हुन्छ। अब सम्झौताहरू हेरौं।

ट्रेडअफ १: प्रदर्शन

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

Tradeoff 2: स्थिरता

यी दुई दृष्टिकोणमा नेता असफल भएमा परिणाम पनि फरक हुनेछ। यदि काम एसिन्क्रोनस रूपमा प्रदर्शन गरिएको छ भने, यदि यस्तो त्रुटि हुन्छ भने, सबै रेकर्डहरू प्रतिकृतिहरू द्वारा प्रतिबद्ध हुनेछैनन्। कति घाटा होला ? अनुप्रयोग आफै र प्रतिकृति को दक्षता मा निर्भर गर्दछ। कम्पोज प्रतिकृतिले प्रतिकृतिलाई नेता बन्नबाट रोक्छ यदि यसमा जानकारीको मात्रा लिडरको भन्दा १ MB कम छ, अर्थात्, एसिन्क्रोनस सञ्चालनको क्रममा 1 MB सम्मको रेकर्डहरू सम्भावित रूपमा हराउन सक्छ।

यो सिंक्रोनस मोडमा हुँदैन। यदि नेता असफल भएमा, सबै प्रतिकृतिहरू अद्यावधिक हुन्छन्, किनकि नेतामा पुष्टि गरिएको कुनै पनि लेख प्रतिकृतिहरूमा पुष्टि हुनुपर्छ। यो एकरूपता हो।

सिंक्रोनस व्यवहारले एक बिलिङ अनुप्रयोगमा अर्थ दिन्छ जहाँ स्थिरता र प्रदर्शन बीचको ट्रेड-अफमा स्थिरताको स्पष्ट फाइदा हुन्छ। यस्तो अनुप्रयोगको लागि सबैभन्दा महत्त्वपूर्ण कुरा वैध डाटा हो। अब एक सामाजिक सञ्जालको बारेमा सोच्नुहोस् जसमा मुख्य कार्य भनेको जतिसक्दो चाँडो अनुरोधहरूको जवाफ दिएर प्रयोगकर्ताको ध्यान राख्नु हो। यस अवस्थामा, कम नेटवर्क हप्सको साथ प्रदर्शन र कमिटहरूको लागि कम प्रतीक्षा प्राथमिकता हुनेछ। जे होस्, प्रदर्शन र स्थिरता बीचको ट्रेडअफ तपाईले सोच्नु पर्ने मात्र होइन।

ट्रेड-अफ 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