हाईलोड++, मिखाइल ट्युलेनेव (मोंगोडीबी): कारण संगति: सिद्धांत से अभ्यास तक

अगला हाईलोड++ सम्मेलन 6 और 7 अप्रैल, 2020 को सेंट पीटर्सबर्ग में आयोजित किया जाएगा।
विवरण और टिकट по ссылке. हाईलोड++ साइबेरिया 2019। हॉल "क्रास्नोयार्स्क"। 25 जून, 12:00 बजे। थीसिस और प्रदर्शन.

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

मिखाइल ट्युलेनेव (बाद में एमटी के रूप में संदर्भित): - मैं कॉज़ल कंसिस्टेंसी के बारे में बात करूंगा - यह एक ऐसी सुविधा है जिस पर हमने MongoDB में काम किया है। मैं वितरित प्रणालियों के एक समूह में काम करता हूं, हमने यह लगभग दो साल पहले किया था।

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

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

कारण संगति. आइए अवधारणाओं को परिभाषित करें

आरंभ करने के लिए, मैं सामान्य शब्दों में यह कहना चाहता हूं कि कारण संगति क्या है। दो पात्र हैं - लियोनार्ड और पेनी (टीवी श्रृंखला "द बिग बैंग थ्योरी"):

मान लीजिए कि पेनी यूरोप में है और लियोनार्ड उसे एक सरप्राइज पार्टी देना चाहता है। और वह उसे अपनी मित्र सूची से बाहर करने, अपने सभी दोस्तों को फ़ीड पर एक अपडेट भेजने से बेहतर कुछ भी नहीं सोच सकता: "आइए पेनी को खुश करें!" (वह यूरोप में है, जब वह सोती है, तो वह यह सब नहीं देखती और न ही देख सकती है, क्योंकि वह वहां नहीं है)। अंततः, वह इस पोस्ट को हटा देती है, फ़ीड से मिटा देती है और पहुंच बहाल कर देती है ताकि उसे कुछ भी नज़र न आए और कोई घोटाला न हो।
यह सब ठीक है और अच्छा है, लेकिन मान लीजिए कि सिस्टम वितरित है और चीजें थोड़ी गलत हो गईं। उदाहरण के लिए, ऐसा हो सकता है कि पेनी की पहुंच पर प्रतिबंध इस पोस्ट के सामने आने के बाद हुआ हो, यदि घटनाएं कारण और प्रभाव से संबंधित नहीं हैं। दरअसल, यह एक उदाहरण है जब किसी व्यावसायिक कार्य को करने के लिए (इस मामले में) कारण संगति की आवश्यकता होती है।

वास्तव में, ये डेटाबेस के काफी गैर-तुच्छ गुण हैं - बहुत कम लोग इनका समर्थन करते हैं। आइए मॉडलों पर चलते हैं।

संगति मॉडल

डेटाबेस में एक संगति मॉडल वास्तव में क्या है? ये कुछ गारंटी हैं जो एक वितरित प्रणाली देती है कि ग्राहक कौन सा डेटा प्राप्त कर सकता है और किस क्रम में प्राप्त कर सकता है।

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

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

मॉडल सशक्त

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

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

एक और, मजबूत संपत्ति है जो स्पैनर में समर्थित है - जिसे बाहरी संगति कहा जाता है। हम इसके बारे में थोड़ी देर बाद बात करेंगे।

करणीय

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

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

अंतिम

तीसरा मॉडल अंततः संगति है। सभी वितरित सिस्टम बिल्कुल इसी का समर्थन करते हैं, न्यूनतम मॉडल जो बिल्कुल समझ में आता है। इसका मतलब निम्नलिखित है: जब हम डेटा में कुछ बदलाव करते हैं, तो कुछ बिंदु पर वे सुसंगत हो जाते हैं।

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

मैं कुछ तुलनात्मक उदाहरण देना चाहता हूँ:

इन तीरों का क्या मतलब है?

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

सीएपी प्रमेय

जब आप स्थिरता, उपलब्धता शब्द देखते हैं - तो आपके दिमाग में क्या आता है? यह सही है - CAP प्रमेय! अब मैं मिथक को दूर करना चाहता हूं... यह मैं नहीं हूं - यह मार्टिन क्लेपमैन हैं, जिन्होंने एक अद्भुत लेख, एक अद्भुत किताब लिखी है।

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

यह प्रमेय वास्तव में निम्नलिखित मामलों के लिए सिद्ध हुआ था... सबसे पहले, उपलब्धता को शून्य से सैकड़ों तक निरंतर मान के रूप में नहीं माना जाता था (0 - सिस्टम "मृत" है, 100 - तुरंत प्रतिक्रिया करता है; हम इसे इस तरह से विचार करने के आदी हैं) , लेकिन एल्गोरिदम की एक संपत्ति के रूप में, जो गारंटी देता है कि इसके सभी निष्पादन के लिए यह डेटा लौटाता है।

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

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

कारण संगति सबसे मजबूत मॉडल है

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

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

MongoDB आंतरिक रसोई

यह याद करते हुए कि यह दोपहर का भोजन है, हम रसोई की ओर बढ़ते हैं। मैं आपको सिस्टम मॉडल के बारे में बताऊंगा, अर्थात् उन लोगों के लिए MongoDB क्या है जो पहली बार ऐसे डेटाबेस के बारे में सुन रहे हैं।

MongoDB (इसके बाद "MongoDB" के रूप में संदर्भित) एक वितरित प्रणाली है जो क्षैतिज स्केलिंग, यानी शार्डिंग का समर्थन करती है; और प्रत्येक शार्ड के भीतर यह डेटा अतिरेक, यानी प्रतिकृति का भी समर्थन करता है।

MongoDB (रिलेशनल डेटाबेस नहीं) में शेयरिंग स्वचालित संतुलन करती है, यानी, दस्तावेज़ों का प्रत्येक संग्रह (या रिलेशनल डेटा के संदर्भ में "तालिका") टुकड़ों में विभाजित होता है, और सर्वर स्वचालित रूप से उन्हें शार्ड के बीच ले जाता है।

क्वेरी राउटर, जो क्लाइंट के लिए अनुरोध वितरित करता है, कुछ क्लाइंट है जिसके माध्यम से यह काम करता है। यह पहले से ही जानता है कि कहां और कौन सा डेटा स्थित है और सभी अनुरोधों को सही शार्ड पर निर्देशित करता है।

एक अन्य महत्वपूर्ण बिंदु: MongoDB एक एकल मास्टर है। एक प्राथमिक है - यह ऐसे रिकॉर्ड ले सकता है जो इसमें मौजूद कुंजियों का समर्थन करते हैं। आप मल्टी-मास्टर राइट नहीं कर सकते.

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

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

सामग्री कारण संगति

मैंने लगभग 230 लेख गिने जो इस विषय पर प्रकाशित हुए हैं - लेस्ली लैम्पर्ट के। अब मैं अपनी स्मृति से इन सामग्रियों के कुछ अंश आप तक पहुँचाऊँगा।

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

सीमाएं

वहां क्या प्रतिबंध हैं? यह वास्तव में मुख्य बिंदुओं में से एक है, क्योंकि उत्पादन प्रणाली द्वारा लगाए गए प्रतिबंध अकादमिक लेखों में मौजूद प्रतिबंधों से बहुत अलग हैं। वे अक्सर काफी कृत्रिम होते हैं.

• सबसे पहले, "MongoDB" एक एकल मास्टर है, जैसा कि मैंने पहले ही कहा था (यह बहुत सरल बनाता है)।
• हमारा मानना ​​है कि सिस्टम को लगभग 10 हजार शार्डों का समर्थन करना चाहिए। हम ऐसा कोई भी वास्तुशिल्प निर्णय नहीं ले सकते जो स्पष्ट रूप से इस मूल्य को सीमित कर दे।
• हमारे पास एक क्लाउड है, लेकिन हम मानते हैं कि एक व्यक्ति के पास अभी भी अवसर होना चाहिए जब वह बाइनरी डाउनलोड करता है, इसे अपने लैपटॉप पर लॉन्च करता है, और सब कुछ बढ़िया काम करता है।
• हम कुछ ऐसा मानते हैं जिसे अनुसंधान शायद ही कभी मानता है: बाहरी ग्राहक जो चाहें वह कर सकते हैं। MongoDB खुला स्रोत है। तदनुसार, ग्राहक इतने चतुर और क्रोधी हो सकते हैं - वे सब कुछ तोड़ना चाह सकते हैं। हम अनुमान लगाते हैं कि बीजान्टिन फीलर्स की उत्पत्ति हो सकती है।
• बाहरी ग्राहकों के लिए जो परिधि के बाहर हैं, एक महत्वपूर्ण सीमा है: यदि यह सुविधा अक्षम है, तो कोई प्रदर्शन गिरावट नहीं देखी जानी चाहिए।
• एक अन्य बिंदु आम तौर पर शैक्षणिक विरोधी है: पिछले संस्करणों और भविष्य के संस्करणों की अनुकूलता। पुराने ड्राइवरों को नए अपडेट का समर्थन करना चाहिए, और डेटाबेस को पुराने ड्राइवरों का समर्थन करना चाहिए।

सामान्य तौर पर, यह सब प्रतिबंध लगाता है।

कारण संगति घटक

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

पूर्ण निर्भरता ट्रैकिंग

इसकी आवश्यकता क्यों है? ताकि जब डेटा दोहराया जाए, तो प्रत्येक रिकॉर्ड, प्रत्येक डेटा परिवर्तन में यह जानकारी हो कि यह किन परिवर्तनों पर निर्भर करता है। सबसे पहला और सरल परिवर्तन तब होता है जब रिकॉर्ड वाले प्रत्येक संदेश में पिछले संदेशों के बारे में जानकारी होती है:

इस उदाहरण में, घुंघराले कोष्ठक में संख्या रिकॉर्ड संख्या है। कभी-कभी मूल्यों वाले ये रिकॉर्ड पूरी तरह से स्थानांतरित भी कर दिए जाते हैं, कभी-कभी कुछ संस्करण भी स्थानांतरित कर दिए जाते हैं। लब्बोलुआब यह है कि प्रत्येक परिवर्तन में पिछले परिवर्तन के बारे में जानकारी होती है (स्पष्ट रूप से यह सब अपने भीतर समाहित होता है)।

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

स्पष्ट निर्भरता ट्रैकिंग

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

वह देखती है कि रिकॉर्ड 5 रिकॉर्ड 1, 2, 3, 4 पर निर्भर करता है - तदनुसार, वह पेनी के एक्सेस निर्णय द्वारा किए गए परिवर्तनों तक ग्राहक की पहुंच प्राप्त करने से पहले इंतजार करती है, जब पिछले सभी परिवर्तन पहले ही डेटाबेस से गुजर चुके होते हैं।

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

लामपोर्ट घड़ी

वे बहुत बूढ़े हैं. लैमपोर्ट क्लॉक का अर्थ है कि इन निर्भरताओं को एक स्केलर फ़ंक्शन में बदल दिया जाता है, जिसे लैमपोर्ट क्लॉक कहा जाता है।

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

मैंने इसे स्पष्ट करने के लिए उस बड़े टुकड़े को दो भागों में विभाजित किया: मित्र एक नोड में रह सकते हैं, जिसमें संग्रह का एक टुकड़ा होता है, और फ़ीड दूसरे नोड में रह सकता है, जिसमें इस संग्रह का एक टुकड़ा होता है। क्या यह स्पष्ट है कि वे लाइन से बाहर कैसे निकल सकते हैं? पहली फ़ीड कहेगी: "प्रतिकृति", और फिर मित्र। यदि सिस्टम किसी प्रकार की गारंटी नहीं देता है कि फ़ीड तब ​​तक नहीं दिखाई जाएगी जब तक कि मित्र संग्रह में मित्र निर्भरताएँ भी वितरित नहीं हो जातीं, तो हमारे पास बिल्कुल वही स्थिति होगी जिसका मैंने उल्लेख किया था।

आप देखें कि फ़ीड पर काउंटर टाइम तार्किक रूप से कैसे बढ़ता है:

तो इस लैमपोर्ट क्लॉक और कॉज़ल कंसिस्टेंसी (लैम्पपोर्ट क्लॉक के माध्यम से समझाया गया) की मुख्य संपत्ति यह है: यदि हमारे पास इवेंट ए और बी हैं, और इवेंट बी इवेंट ए* पर निर्भर करता है, तो इसका मतलब यह है कि इवेंट ए का लॉजिकलटाइम इससे कम है इवेंट बी से लॉजिकलटाइम।

* कभी-कभी वे यह भी कहते हैं कि A, B से पहले घटित हुआ, अर्थात A, B से पहले घटित हुआ - यह एक निश्चित संबंध है जो सामान्य रूप से घटित घटनाओं के पूरे सेट को आंशिक रूप से आदेश देता है।

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

वेक्टर घड़ी

लैमपोर्ट घड़ी का तार्किक विकास वेक्टर घड़ी है। वे इस मायने में भिन्न हैं कि यहां मौजूद प्रत्येक नोड की अपनी अलग घड़ी होती है, और वे एक वेक्टर के रूप में प्रसारित होते हैं।
इस मामले में, आप देखते हैं कि वेक्टर का शून्यवां सूचकांक फ़ीड के लिए जिम्मेदार है, और वेक्टर का पहला सूचकांक फ्रेंड्स (इनमें से प्रत्येक नोड) के लिए है। और अब वे बढ़ेंगे: लिखते समय "फ़ीड" का शून्य सूचकांक बढ़ता है - 1, 2, 3:

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

यदि हमारे पास 10 हजार टुकड़े हैं, तो हम 10 हजार घटकों को स्थानांतरित नहीं कर सकते, भले ही हम इसे संपीड़ित करें या कुछ और लेकर आएं - पेलोड अभी भी इस पूरे वेक्टर की मात्रा से कई गुना छोटा होगा। इसलिए, अपने दिल और दाँत पीसते हुए, हमने इस दृष्टिकोण को छोड़ दिया और दूसरे पर चले गए।

स्पैनर ट्रूटाइम। परमाणु घड़ी

मैंने कहा कि स्पैनर के बारे में एक कहानी होगी। यह एक बढ़िया चीज़ है, सीधे XNUMXवीं सदी की: परमाणु घड़ियाँ, जीपीएस सिंक्रोनाइज़ेशन।

क्या विचार है? "स्पैनर" एक Google प्रणाली है जो हाल ही में लोगों के लिए भी उपलब्ध हो गई है (उन्होंने इसमें SQL जोड़ा है)। वहां प्रत्येक लेन-देन पर कुछ समय की मोहर लगी होती है। चूंकि समय सिंक्रनाइज़ है*, प्रत्येक घटना को एक विशिष्ट समय सौंपा जा सकता है - परमाणु घड़ियों में एक प्रतीक्षा समय होता है, जिसके बाद एक अलग समय "घटित होने" की गारंटी होती है।

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

* लैम्पर्ट घड़ियों के साथ यह मुख्य समस्या है - वे वितरित सिस्टम पर कभी भी समकालिक नहीं होती हैं। वे अलग-अलग हो सकते हैं; एनटीपी के साथ भी, वे अभी भी बहुत अच्छी तरह से काम नहीं करते हैं। "स्पैनर" में एक परमाणु घड़ी है और ऐसा लगता है कि सिंक्रनाइज़ेशन माइक्रोसेकंड है।

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

हाइब्रिड घड़ी

यह वास्तव में मोंगोडीबी में कॉज़ल स्थिरता सुनिश्चित करते समय टिक करता है। वे कैसे संकर हैं? हाइब्रिड एक अदिश मान है, लेकिन इसके दो घटक हैं:

• पहला यूनिक्स युग है ("कंप्यूटर दुनिया की शुरुआत के बाद से कितने सेकंड बीत चुके हैं")।
• दूसरा कुछ वृद्धि है, एक 32-बिट अहस्ताक्षरित इंट भी।

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

यह MongoDB के लिए क्यों महत्वपूर्ण है? क्योंकि यह आपको एक निश्चित समय पर कुछ प्रकार के बैकअप रेस्तरां बनाने की अनुमति देता है, अर्थात, घटना को समय के अनुसार अनुक्रमित किया जाता है। यह तब महत्वपूर्ण है जब कुछ घटनाओं की आवश्यकता होती है; किसी डेटाबेस के लिए, घटनाएँ डेटाबेस में परिवर्तन हैं जो समय के निश्चित अंतराल पर घटित होती हैं।

मैं आपको सबसे महत्वपूर्ण कारण केवल आपको बताऊंगा (कृपया, किसी को मत बताना)! हमने ऐसा इसलिए किया क्योंकि MongoDB OpLog में व्यवस्थित, अनुक्रमित डेटा इसी तरह दिखता है। OpLog एक डेटा संरचना है जिसमें डेटाबेस में बिल्कुल सभी परिवर्तन शामिल होते हैं: वे पहले OpLog पर जाते हैं, और फिर उन्हें स्टोरेज पर ही लागू किया जाता है जब यह एक प्रतिकृति तिथि या शार्ड होता है।

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

घड़ी तुल्यकालन

वैज्ञानिक साहित्य में कई तुल्यकालन विधियाँ वर्णित हैं। मैं सिंक्रनाइज़ेशन के बारे में बात कर रहा हूं जब हमारे पास दो अलग-अलग टुकड़े होते हैं। यदि एक प्रतिकृति सेट है, तो किसी भी सिंक्रनाइज़ेशन की कोई आवश्यकता नहीं है: यह एक "एकल मास्टर" है; हमारे पास एक OpLog है, जिसमें सभी परिवर्तन आते हैं - इस मामले में, सब कुछ पहले से ही "Oplog" में क्रमिक रूप से ऑर्डर किया गया है। लेकिन अगर हमारे पास दो अलग-अलग टुकड़े हैं, तो समय सिंक्रनाइज़ेशन यहां महत्वपूर्ण है। यहीं पर वेक्टर घड़ी ने अधिक मदद की! लेकिन वे हमारे पास नहीं हैं.

दूसरा उपयुक्त है - यह "दिल की धड़कन" है। समय की प्रत्येक इकाई में होने वाले कुछ संकेतों का आदान-प्रदान संभव है। लेकिन दिल की धड़कनें बहुत धीमी हैं, हम अपने ग्राहक को विलंबता प्रदान नहीं कर सकते।

निस्संदेह, सच्चा समय एक अद्भुत चीज़ है। लेकिन, फिर से, यह शायद भविष्य है... हालाँकि यह पहले से ही एटलस में किया जा सकता है, वहाँ पहले से ही तेज़ "अमेज़ॅन" टाइम सिंक्रोनाइज़र मौजूद हैं। लेकिन यह हर किसी के लिए उपलब्ध नहीं होगा.

गपशप तब होती है जब सभी संदेशों में समय शामिल होता है। यह लगभग वही है जो हम उपयोग करते हैं। नोड्स के बीच प्रत्येक संदेश, एक ड्राइवर, एक डेटा नोड राउटर, MongoDB के लिए बिल्कुल सब कुछ एक प्रकार का तत्व है, एक डेटाबेस घटक जिसमें एक घड़ी होती है जो चलती है। इनका तात्पर्य सर्वत्र संकर काल से है, संचरित होता है। 64 बिट्स? यह अनुमति देता है, यह संभव है।

यह सब एक साथ कैसे काम करता है?

यहां मैं इसे थोड़ा आसान बनाने के लिए एक प्रतिकृति सेट देख रहा हूं। प्राथमिक और माध्यमिक हैं। सेकेंडरी प्रतिकृति बनाता है और हमेशा प्राथमिक के साथ पूरी तरह से सिंक्रनाइज़ नहीं होता है।

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

उसके रिकॉर्डिंग करने के बाद, एक महत्वपूर्ण क्षण आता है। घड़ी "MongoDB" में है और केवल "Oplog" पर लिखने की स्थिति में ही बढ़ाई जाती है। यह वह घटना है जो सिस्टम की स्थिति को बदल देती है। बिल्कुल सभी क्लासिक लेखों में, एक घटना तब मानी जाती है जब कोई संदेश एक नोड से टकराता है: संदेश आ गया है, जिसका अर्थ है कि सिस्टम ने अपनी स्थिति बदल दी है।

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

वह मान जो पहले से ही "ओप्लॉग" में लिखा गया है, वापस कर दिया गया है - हम जानते हैं कि "ओप्लॉग" में पहले से ही यह मान शामिल है, और इसका समय 12 है। अब, मान लीजिए, पढ़ना दूसरे नोड (माध्यमिक) से शुरू होता है, और यह बाद में क्लस्टरटाइम को प्रसारित करता है संदेश। वह कहता है: "मुझे वह सब कुछ चाहिए जो कम से कम 12 बजे के बाद या बारह बजे के दौरान हुआ" (ऊपर चित्र देखें)।

इसे ही कॉज़ल ए कंसिस्टेंट (सीएटी) कहा जाता है। सिद्धांत रूप में ऐसी अवधारणा है कि यह समय का कोई टुकड़ा है, जो अपने आप में सुसंगत है। इस मामले में, हम कह सकते हैं कि यह सिस्टम की वह स्थिति है जो समय 12 पर देखी गई थी।

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

यह सब लगभग इसी तरह काम करता है। लगभग।

"लगभग" का क्या मतलब है? चलिए मान लेते हैं कि कोई ऐसा व्यक्ति है जिसने पढ़ा और समझा है कि यह सब कैसे काम करता है। मुझे एहसास हुआ कि हर बार जब क्लस्टरटाइम होता है, तो यह आंतरिक तार्किक घड़ी को अपडेट करता है, और फिर अगली प्रविष्टि एक से बढ़ जाती है। यह फ़ंक्शन 20 पंक्तियाँ लेता है. मान लीजिए कि यह व्यक्ति सबसे बड़ी 64-बिट संख्या, शून्य से एक, प्रसारित करता है।

"माइनस वन" क्यों? क्योंकि आंतरिक घड़ी को इस मूल्य में प्रतिस्थापित किया जाएगा (जाहिर है, यह सबसे बड़ा संभव है और वर्तमान समय से अधिक है), तो "ओप्लॉग" में एक प्रविष्टि होगी, और घड़ी को एक और इकाई द्वारा बढ़ाया जाएगा - और वहां पहले से ही होगा अधिकतम मान हो (वहाँ बस सभी इकाइयाँ हैं, जाने के लिए कहीं और नहीं है), अनसेंट इनट्स)।

यह स्पष्ट है कि इसके बाद सिस्टम किसी भी चीज़ के लिए बिल्कुल दुर्गम हो जाता है। इसे केवल उतारना और साफ करना ही संभव है - इसमें बहुत सारा मैनुअल काम होता है। पूर्ण उपलब्धता:

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

हमारा तरीका क्लस्टरटाइम पर हस्ताक्षर करना है

इस प्रकार यह संदेश में प्रसारित होता है (नीले पाठ से पहले)। लेकिन हमने एक हस्ताक्षर (नीला पाठ) भी बनाना शुरू किया:

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

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

यदि हम हस्ताक्षरों की निरंतर पीढ़ी को छोड़ देते हैं, तो यह किसी सुविधा के अभाव में भी सिस्टम को धीमा कर देगा, जो हमारे दृष्टिकोण और आवश्यकताओं को पूरा नहीं करता है। तो हम क्या करते?

इसे जल्दी करो!

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

ऐसा हस्ताक्षर प्राप्त करके, हम सिस्टम को (अपेक्षाकृत) 65 हजार गुना तेज कर देते हैं। यह बहुत अच्छा काम करता है: जब हमने प्रयोग किए, तो क्रमिक अद्यतन होने पर समय वास्तव में 10 हजार गुना कम हो गया। यह स्पष्ट है कि जब वे मतभेद में होते हैं, तो यह काम नहीं करता है। लेकिन अधिकांश व्यावहारिक मामलों में यह काम करता है। हस्ताक्षर के साथ रेंज हस्ताक्षर के संयोजन ने सुरक्षा समस्या को हल कर दिया।

हमने क्या सीखा?

इससे हमने जो सबक सीखा:

• हमें सामग्री, कहानियाँ, लेख पढ़ने की ज़रूरत है, क्योंकि हमारे पास बहुत सारी दिलचस्प चीज़ें हैं। जब हम किसी फीचर पर काम करते हैं (खासकर अब, जब हमने लेनदेन आदि किया था), तो हमें पढ़ने और समझने की जरूरत है। इसमें समय लगता है, लेकिन यह वास्तव में बहुत उपयोगी है क्योंकि यह स्पष्ट करता है कि हम कहाँ हैं। ऐसा प्रतीत होता है कि हम कुछ भी नया लेकर नहीं आये - हमने केवल सामग्रियाँ लीं।

  सामान्य तौर पर, जब कोई अकादमिक सम्मेलन होता है (उदाहरण के लिए सिग्मोन) तो सोच में एक निश्चित अंतर होता है - हर कोई नए विचारों पर ध्यान केंद्रित करता है। हमारे एल्गोरिदम के बारे में नया क्या है? यहां कोई खास नवीनता नहीं है. नवीनता इस बात में निहित है कि हमने मौजूदा दृष्टिकोणों को एक साथ कैसे मिश्रित किया। इसलिए, पहली बात लैम्पर्ट से शुरू करके क्लासिक्स पढ़ना है।

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

  यहाँ बिल्कुल कुछ भी नया नहीं है! लेकिन जैसे ही हमने यह सब एक साथ मिलाया... यह कहने के समान है कि ओलिवियर सलाद नुस्खा बकवास है, क्योंकि अंडे, मेयोनेज़ और खीरे का आविष्कार पहले ही हो चुका है... यह उसी कहानी के बारे में है।

मैं इसी के साथ समाप्त करूंगा. धन्यवाद!

सवाल

दर्शकों से प्रश्न (बाद में बी के रूप में संदर्भित): - रिपोर्ट के लिए धन्यवाद, मिखाइल! समय के बारे में विषय दिलचस्प है. आप गपशप का उपयोग कर रहे हैं. उन्होंने कहा कि सबका अपना-अपना समय होता है, हर कोई अपना स्थानीय समय जानता है. जैसा कि मैं इसे समझता हूं, हमारे पास एक ड्राइवर है - ड्राइवरों के साथ कई ग्राहक हो सकते हैं, क्वेरी-प्लानर भी, शार्ड भी... और अगर हमारे पास अचानक कोई विसंगति होती है तो सिस्टम क्या करता है: कोई निर्णय लेता है कि यह एक के लिए है एक मिनट आगे, कोई एक मिनट पीछे? हम कहाँ ख़त्म होंगे?

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

में: - मैं जानना चाहता था कि वे कैसे सिंक्रनाइज़ होते हैं और एक तार्किक समय चुनते हैं?

एमटी: - सिंक्रनाइज़ करना बहुत आसान है। शार्ड, जब आफ्टरक्लस्टरटाइम उसके पास आता है और उसे "ओप्लॉग" में समय नहीं मिलता है, तो वह स्वीकृत नहीं होने की पहल करता है। यानी वह अपने समय को अपने हाथों से इस मान तक बढ़ाता है। इसका मतलब यह है कि इसमें इस अनुरोध से मेल खाने वाला कोई ईवेंट नहीं है। वह इस घटना को कृत्रिम रूप से बनाता है और इस प्रकार कारण संगत बन जाता है।

में: – क्या होगा यदि इसके बाद कुछ अन्य घटनाएँ उसके पास आएँ जो नेटवर्क में कहीं खो गई हों?

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

में: - मेरे पास कतारों के संबंध में कई प्रश्न हैं। कारण संगति यह मानती है कि क्रियाओं की एक विशिष्ट कतार है जिसे निष्पादित करने की आवश्यकता है। यदि हमारा कोई पैकेज गायब हो जाए तो क्या होगा? यहां 10वीं, 11वीं आती है... 12वीं गायब हो गई है, और बाकी सभी लोग इसके सच होने का इंतजार कर रहे हैं। और अचानक हमारी कार खराब हो गई, हम कुछ नहीं कर सकते। क्या कतार की कोई अधिकतम लंबाई है जो निष्पादित होने से पहले जमा हो जाती है? जब कोई एक राज्य खो जाता है तो कौन सी घातक विफलता घटित होती है? इसके अलावा, अगर हम लिख लें कि कोई पिछली स्थिति है, तो क्या हमें किसी तरह उससे शुरुआत करनी चाहिए? लेकिन उन्होंने उसे दूर नहीं धकेला!

एमटी: – यह भी एक बढ़िया सवाल है! हम क्या कर रहे हैं? MongoDB में कोरम लिखने, कोरम पढ़ने की अवधारणा है। किन मामलों में कोई संदेश खो सकता है? जब कोई लिखना कोरम नहीं है या जब पढ़ा गया कोरम नहीं है (किसी प्रकार का कचरा भी चिपक सकता है)।
कारण संगति के संबंध में, एक बड़ा प्रायोगिक परीक्षण किया गया, जिसका परिणाम यह हुआ कि जब लिखना और पढ़ना गैर-कोरम होता है, तो कारण संगति का उल्लंघन होता है। बिल्कुल वही जो आप कहते हैं!

हमारी सलाह: कॉसल कंसिस्टेंसी का उपयोग करते समय कम से कम कोरम रीडिंग का उपयोग करें। इस मामले में, कुछ भी नहीं खोएगा, भले ही कोरम रिकॉर्ड खो जाए... यह एक ऑर्थोगोनल स्थिति है: यदि उपयोगकर्ता नहीं चाहता है कि डेटा खो जाए, तो उसे कोरम रिकॉर्ड का उपयोग करने की आवश्यकता है। कारण संगति स्थायित्व की गारंटी नहीं देती। स्थायित्व की गारंटी प्रतिकृति और प्रतिकृति से जुड़ी मशीनरी द्वारा दी जाती है।

में: - जब हम एक ऐसा उदाहरण बनाते हैं जो हमारे लिए शार्डिंग करता है (क्रमशः मास्टर नहीं, बल्कि स्लेव), तो यह अपनी मशीन के यूनिक्स समय या "मास्टर" के समय पर निर्भर करता है; क्या यह पहली बार या समय-समय पर सिंक होता है?

एमटी: - मैं अब स्पष्ट करूंगा। शार्ड (अर्थात क्षैतिज विभाजन) - वहां हमेशा एक प्राथमिक होता है। और एक टुकड़े का एक "मास्टर" हो सकता है और उसकी प्रतिकृतियां भी हो सकती हैं। लेकिन शार्ड हमेशा रिकॉर्डिंग का समर्थन करता है, क्योंकि इसे कुछ डोमेन का समर्थन करना चाहिए (शार्क में प्राथमिक है)।

में: - तो सब कुछ पूरी तरह से "मालिक" पर निर्भर करता है? क्या मास्टर टाइम का हमेशा उपयोग किया जाता है?

एमटी: - हाँ। आप लाक्षणिक रूप से कह सकते हैं: घड़ी टिक-टिक कर रही है जब "मास्टर" में, "ओपलॉग" में कोई प्रविष्टि होती है।

में: - हमारे पास एक ग्राहक है जो जुड़ता है और उसे समय के बारे में कुछ भी जानने की आवश्यकता नहीं है?

एमटी: – आपको कुछ भी जानने की ज़रूरत नहीं है! यदि हम इस बारे में बात करें कि यह क्लाइंट पर कैसे काम करता है: जब क्लाइंट कॉज़ल कंसिस्टेंसी का उपयोग करना चाहता है, तो उसे एक सत्र खोलने की आवश्यकता होती है। अब सब कुछ मौजूद है: सत्र में लेन-देन, और अधिकार पुनः प्राप्त करना... एक सत्र क्लाइंट के साथ होने वाली तार्किक घटनाओं का क्रम है।

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

ग्राहक को बिल्कुल कुछ भी जानने की आवश्यकता नहीं है! यह उसके लिए पूरी तरह से अपारदर्शी है. यदि लोग इन सुविधाओं का उपयोग करते हैं, तो वे क्या कर सकते हैं? सबसे पहले, आप सुरक्षित रूप से सेकंडरी पढ़ सकते हैं: आप प्राथमिक को लिख सकते हैं और भौगोलिक रूप से प्रतिकृति सेकंडरी से पढ़ सकते हैं और सुनिश्चित कर सकते हैं कि यह काम करता है। साथ ही, प्राथमिक पर रिकॉर्ड किए गए सत्रों को माध्यमिक में भी स्थानांतरित किया जा सकता है, यानी आप एक सत्र नहीं, बल्कि कई का उपयोग कर सकते हैं।

में: - कंप्यूट विज्ञान की एक नई परत - सीआरडीटी (संघर्ष-मुक्त प्रतिकृति डेटा प्रकार) डेटा प्रकार - दृढ़ता से अंतिम स्थिरता के विषय से संबंधित है। क्या आपने इस प्रकार के डेटा को डेटाबेस में एकीकृत करने पर विचार किया है और आप इसके बारे में क्या कह सकते हैं?

एमटी: - अच्छा प्रश्न! सीआरडीटी लेखन संघर्षों के लिए समझ में आता है: MongoDB में, एकल मास्टर।

में: - मेरे पास डेवोप्स से एक प्रश्न है। वास्तविक दुनिया में, ऐसी जेसुइटिकल स्थितियां होती हैं जब बीजान्टिन विफलता होती है, और संरक्षित परिधि के अंदर दुष्ट लोग प्रोटोकॉल में घुसपैठ करना शुरू कर देते हैं, एक विशेष तरीके से शिल्प पैकेज भेजते हैं?

एमटी: – परिधि के अंदर दुष्ट लोग ट्रोजन हॉर्स की तरह हैं! परिधि के अंदर दुष्ट लोग बहुत सारे बुरे काम कर सकते हैं।

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

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

अधिकारों के आधार पर, उपयोगकर्ता जो नुकसान पहुंचा सकते हैं वह चूहा हो सकता है, या हाथी हो सकता है। यह स्पष्ट है कि पूर्ण अधिकार वाला उपयोगकर्ता कुछ भी कर सकता है। सीमित अधिकारों वाला उपयोगकर्ता काफी कम नुकसान पहुंचा सकता है। खास तौर पर यह सिस्टम को तोड़ नहीं सकता.

में: - संरक्षित परिधि में, किसी ने सर्वर को पूरी तरह से नष्ट करने के लिए सर्वर के लिए अप्रत्याशित प्रोटोकॉल बनाने की कोशिश की, और यदि आप भाग्यशाली हैं, तो संपूर्ण क्लस्टर... क्या इसे कभी "अच्छा" मिलता है?

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

में: - रिपोर्ट के लिए धन्यवाद. सर्गेई (यांडेक्स)। मोंग में एक स्थिरांक है जो रेप्लिका सेट में मतदान करने वाले सदस्यों की संख्या को सीमित करता है, और यह स्थिरांक 7 (सात) है। यह स्थिरांक क्यों है? यह किसी प्रकार का पैरामीटर क्यों नहीं है?

एमटी: - हमारे पास 40 नोड्स वाले रेप्लिका सेट हैं। हमेशा बहुमत होता है. मैं नहीं जानता कि कौन सा संस्करण...

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

एमटी: - यह पहले से ही रिपोर्ट के दायरे से थोड़ा परे है। यह एक सामान्य प्रश्न है. शायद मैं आपको इसके बारे में बाद में बता सकूं.

कुछ विज्ञापन 🙂

हमारे साथ रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक रोचक सामग्री देखना चाहते हैं? आदेश देकर या मित्रों को अनुशंसा करके हमारा समर्थन करें, डेवलपर्स के लिए क्लाउड VPS $4.99 से शुरू, प्रवेश स्तर के सर्वरों का एक अनूठा एनालॉग, जिसका आविष्कार हमने आपके लिए किया था: VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps के बारे में पूरी सच्चाई $19 से या सर्वर कैसे साझा करें? (RAID1 और RAID10 के साथ उपलब्ध, 24 कोर तक और 40GB DDR4 तक)।

एम्स्टर्डम में इक्विनिक्स टियर IV डेटा सेंटर में Dell R730xd 2x सस्ता है? केवल यहां 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 टीवी $199 से नीदरलैंड में! डेल R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 से! के बारे में पढ़ा इन्फ्रास्ट्रक्चर कॉर्प का निर्माण कैसे करें। एक पैसा के लिए 730 यूरो मूल्य के डेल R5xd E2650-4 v9000 सर्वर के उपयोग के साथ वर्ग?

स्रोत: www.habr.com