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

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

समस्याओं में से एक जो एक व्यक्ति का सामना करना पड़ता है जो एक परियोजना को एक वितरित प्रणाली में स्थानांतरित करना चाहता है या उस पर एक परियोजना शुरू करना चाहता है जो कि उत्पाद चुनना है।

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

यह लेख वितरित प्रणालियों में स्थिरता और एसीआईडी ​​वारंटी पर हमारी सामग्री पर आधारित है।

यह क्या है और इसकी आवश्यकता क्यों है?

" डेटा संगति (कभी-कभी डेटा संगति ) एक दूसरे के साथ डेटा संगति , डेटा अखंडता और आंतरिक स्थिरता है।" ( विकिपीडिया )

संगति का अर्थ है कि किसी भी समय, अनुप्रयोगों को यह सुनिश्चित किया जा सकता है कि वे डेटा के सही, तकनीकी रूप से प्रासंगिक संस्करण के साथ काम कर रहे हैं, और निर्णय लेते समय इस पर भरोसा कर सकते हैं।

वितरित प्रणालियों में, निरंतरता सुनिश्चित करना अधिक कठिन और अधिक महंगा होता जा रहा है, क्योंकि विभिन्न नोड्स के बीच नेटवर्क एक्सचेंज से संबंधित नई चुनौतियों की एक पूरी श्रृंखला उत्पन्न होती है, व्यक्तिगत नोड्स की विफलता की संभावना और - अक्सर - सत्यापन के लिए सेवा कर सकने वाली एकल मेमोरी की कमी।

उदाहरण के लिए, यदि मेरे पास 4 नोड्स की प्रणाली है: ए, बी, सी, और डी, जो बैंकिंग लेनदेन का काम करता है, और नोड्स सी और डी को ए और बी (नेटवर्क समस्याओं के कारण कहते हैं) से अलग किया जाता है, तो यह बहुत संभव है कि मैं अब नहीं हूं। मेरे पास लेनदेन का हिस्सा है। मैं इस स्थिति में कैसे कार्य करूं? अलग-अलग सिस्टम अलग-अलग तरीके अपनाते हैं।


शीर्ष स्तर पर, 2 मुख्य दिशाएं हैं जो कैप प्रमेय में व्यक्त की गई हैं।

" कैप प्रमेय (जिसे ब्रेवर प्रमेय के रूप में भी जाना जाता है ) एक अनुमानी कथन है कि वितरित कंप्यूटिंग के किसी भी कार्यान्वयन में निम्नलिखित तीन गुणों में से दो से अधिक नहीं प्रदान करना संभव है:

• डेटा संगति (इंजी। संगति) - एक समय में सभी कंप्यूटिंग नोड्स में, डेटा एक दूसरे के विपरीत नहीं होता है;
• उपलब्धता (इं। उपलब्धता) - वितरित प्रणाली के लिए कोई भी अनुरोध एक सही प्रतिक्रिया के साथ समाप्त होता है, लेकिन गारंटी के बिना कि सिस्टम मैच के सभी नोड्स के उत्तर;
• विभाजन सहिष्णुता - एक वितरित प्रणाली को कई अलग-अलग वर्गों में विभाजित करने से प्रत्येक अनुभाग से गलत प्रतिक्रिया नहीं होती है। "

( विकिपीडिया )

जब कैप-प्रमेय स्थिरता की बात करता है, तो यह रिकॉर्ड और रीडिंग के रैखिककरण सहित, बल्कि सख्त परिभाषा का अर्थ है, और व्यक्तिगत मूल्यों को लिखते समय केवल स्थिरता को निर्धारित करता है। ( मार्टिन क्लेपमैन )

सीएपी-प्रमेय कहता है कि अगर हम नेटवर्क की समस्याओं के प्रति प्रतिरोधी होना चाहते हैं, तो सामान्य तौर पर हमें यह चुनना होगा कि क्या त्याग करना है: संगति या पहुंच। इस प्रमेय का एक विस्तारित संस्करण भी है - PACELC ( विकिपीडिया ), जो अतिरिक्त रूप से इस तथ्य के बारे में बात करता है कि नेटवर्क समस्याओं की अनुपस्थिति में भी, हमें प्रतिक्रिया की गति और स्थिरता के बीच चयन करना होगा।

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

यह सब इस तथ्य के कारण है कि यह एक विकल्प है जिसका अर्थ है कि हम कुछ बलिदान करते हैं, और हम इसे बलिदान करने के लिए हमेशा तैयार नहीं होते हैं।

अक्सर वितरित सिस्टम में निरंतरता की समस्या को इस स्थिरता को छोड़ कर हल किया जाता है।

लेकिन यह समझना आवश्यक और महत्वपूर्ण है कि इस स्थिरता की अस्वीकृति कब स्वीकार्य है, और जब यह एक महत्वपूर्ण व्यावसायिक आवश्यकता है।

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

यदि मैं सेंसरों से डेटा स्ट्रीम पर एनालिटिक्स करता हूं, तो कई मामलों में मेरे लिए कुछ डेटा खोना और कुछ समय के लिए डाउनसमलिंग प्राप्त करना पूरी तरह से अनचाहा है, खासकर अगर मैं अंत में डेटा देखता हूं।

लेकिन अगर मैं बैंकिंग प्रणाली बनाता हूं, तो मेरे व्यवसाय के लिए नकद लेनदेन की स्थिरता महत्वपूर्ण है। यदि मैंने इस तथ्य के कारण ग्राहक के ऋण पर जुर्माना लगाया कि मैं समय पर किए गए भुगतान को नहीं देख रहा हूं, हालांकि वह सिस्टम में था, यह बहुत बुरा है। साथ ही साथ यदि क्लाइंट मेरे क्रेडिट कार्ड से कई बार सारे पैसे निकाल सकता है, क्योंकि मुझे लेन-देन के समय नेटवर्क की समस्या थी, और निकासी की जानकारी मेरे क्लस्टर का हिस्सा नहीं थी।

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

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

यह बेहतर है अगर ऑनलाइन स्टोर की टोकरी कहती है "बाद में प्रयास करें, एक वितरित DBMS उपलब्ध नहीं है" की तुलना में अगर यह सफलता पर रिपोर्ट करता है और आदेश को भूल जाता है। सफलता पर एक बीट की तुलना में बैंक की सेवाओं की अनुपलब्धता के कारण लेनदेन में इनकार करना बेहतर है और फिर बैंक के साथ कार्यवाही इस तथ्य के कारण कि वह भूल गया कि आपने ऋण का भुगतान किया था।

अंत में, अगर हम विस्तारित, PACELC प्रमेय को देखते हैं, तो हम समझते हैं कि सिस्टम के नियमित संचालन के मामले में भी, स्थिरता का चयन करते हुए, हम कम विलंबता का त्याग कर सकते हैं, जिससे अधिकतम प्रदर्शन का संभावित निम्न स्तर प्राप्त हो सकता है।

इसलिए, इस सवाल का जवाब देना "यह आवश्यक क्यों है?": यह आवश्यक है कि आपके कार्य के लिए अप-टू-डेट, सुसंगत डेटा और महत्वपूर्ण है, तो विकल्प आपको घटना की अवधि या उसके निचले प्रदर्शन के लिए सेवा की अस्थायी अनुपलब्धता से अधिक महत्वपूर्ण नुकसान लाएगा।

यह कैसे प्रदान करें?

तदनुसार, आपको जो पहला निर्णय लेने की आवश्यकता है, वह वह है जहां आप कैप प्रमेय में हैं, आप किसी घटना के मामले में स्थिरता या उपलब्धता चाहते हैं।

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

यदि यह आपके लिए पर्याप्त नहीं है, तो हम पूरी तरह से वितरित ACID लेनदेन की अवधारणा को अपनाना शुरू करते हैं।

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

ये प्रतिबंध अक्सर किसी कारण से किए गए थे: या तो कार्यान्वयन को सरल बनाने के लिए, या, उदाहरण के लिए, प्रदर्शन में सुधार करने के लिए, या कुछ और के लिए। वे बड़ी संख्या में मामलों के लिए पर्याप्त हैं, इसलिए आपको उन्हें अपने दम पर विचार नहीं करना चाहिए।

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

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

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

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

दूसरा दृष्टिकोण स्केलिंग में बहुत अधिक स्वतंत्रता देता है, और, बदले में, दो-चरण ( विकिपीडिया ) और तीन-चरण ( विकिपीडिया ) प्रतिबद्ध प्रोटोकॉल में विभाजित है।

उदाहरण के लिए, अपाचे इग्नाइट का उपयोग करने वाले दो-चरण प्रतिबद्ध पर विचार करें।



प्रतिबद्ध प्रक्रिया 2 चरणों में विभाजित है: तैयार और प्रतिबद्ध।

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

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

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

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

निष्कर्ष

मुख्य निष्कर्ष: वितरित भंडारण प्रणाली एक काफी विकसित बाजार है, और इस पर उत्पाद उच्च डेटा स्थिरता प्रदान कर सकते हैं।

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

जब आप चुनते हैं कि आपको क्या चाहिए, तो आपको अपने मामले की जरूरतों को ध्यान में रखना चाहिए और अच्छी तरह से समझना चाहिए कि आप क्या बलिदान और समझौता करना चाहते हैं, क्योंकि मुफ्त में कुछ भी नहीं होता है, और एक को चुनना, आप सबसे अधिक संभावना है कि किसी और चीज को मना कर देंगे।

इस तरफ से उत्पादों का मूल्यांकन करते समय, यह निम्नलिखित पर ध्यान देने योग्य है:

• जहां वे कैप-प्रमेय में हैं;
• क्या वे वितरित ACID लेनदेन का समर्थन करते हैं?
• वे वितरित लेनदेन पर क्या प्रतिबंध लगाते हैं (उदाहरण के लिए, केवल एक विभाजन के भीतर, आदि);
• वितरित लेनदेन का उपयोग करने की सुविधा और दक्षता, अन्य उत्पाद घटकों में उनका एकीकरण।