वीशर्ड - टारेंटूल में क्षैतिज स्केलिंग

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

पहले कुछ बुनियादी ज्ञान।

स्केलिंग दो प्रकार की होती है: क्षैतिज और ऊर्ध्वाधर। और क्षैतिज स्केलिंग के दो प्रकार हैं: प्रतिकृति और पैनापन। प्रतिकृति कम्प्यूटेशनल स्केलिंग सुनिश्चित करती है जबकि डेटा स्केलिंग के लिए शार्किंग का उपयोग किया जाता है।

शेयरिंग को भी दो प्रकारों में विभाजित किया गया है: श्रेणी-आधारित शार्किंग और हैश-आधारित शार्किंग।

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

हैश-आधारित शार्किंग कम जटिल है: एक हैश फ़ंक्शन की गणना क्लस्टर में प्रत्येक रिकॉर्ड के लिए की जाती है; समान हैश फ़ंक्शन के साथ रिकॉर्ड समान भौतिक नोड को आवंटित किए जाते हैं।

मैं हैश-आधारित शेरिंग का उपयोग करके क्षैतिज स्केलिंग पर ध्यान केंद्रित करूंगा।

पुराने कार्यान्वयन

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

function shard_function(primary_key) return guava(crc32(primary_key), shard_count) end 

लेकिन अंततः टारनटूल शर्ड नए कार्यों से निपटने में असमर्थ हो गए।

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

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

 format = {{'id', 'unsigned'}, {'email', 'string'}} box.schema.create_space('customer', {format = format}) format = {{'id', 'unsigned'}, {'customer_id', 'unsigned'}, {'balance', 'number'}} box.schema.create_space('account', {format = format}) 

ऊपर के उदाहरण में, खातों और ग्राहक के आईडी फ़ील्ड असंगत हो सकते हैं। वे खाते के customer_id फ़ील्ड और ग्राहक के id फ़ील्ड से जुड़े होते हैं। वही आईडी फ़ील्ड खाता प्राथमिक कुंजी की विशिष्टता बाधा का उल्लंघन करेगी। और शार्द किसी अन्य तरीके से शार्पिंग नहीं कर सकता।

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

टारनटुल शर्ड के साथ एक और मुद्दा एक प्रतिकृति सेट में नोड विफलता के मामले में रीड्स की कम उपलब्धता थी।

नया समाधान

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



हम एक बाल्टी में डेटा कैसे डालते हैं? आइए हमारे बैंक ग्राहक के लिए तालिका में एक नया बकेट आईडी फ़ील्ड जोड़ें। यदि संबंधित डेटा के लिए यह फ़ील्ड मान समान है, तो सभी रिकॉर्ड एक बाल्टी में होंगे। लाभ यह है कि हम एक ही बाल्टी आईडी के साथ अलग-अलग स्थानों में रिकॉर्ड कर सकते हैं, और यहां तक ​​कि विभिन्न इंजनों में भी। बकेट आईडी के आधार पर डेटा स्थानीयता को भंडारण विधि की परवाह किए बिना गारंटी दी जाती है।

 format = {{'id', 'unsigned'}, {'email', 'string'}, {'bucket_id', 'unsigned'}} box.schema.create_space('customer', {format = format}) format = {{'id', 'unsigned'}, {'customer_id', 'unsigned'}, {'balance', 'number'}, {'bucket_id', 'unsigned'}} box.schema.create_space('account', {format = format}) 

यह इतना महत्वपूर्ण क्यों है? पारंपरिक शारडिंग का उपयोग करते समय, डेटा विभिन्न मौजूदा भौतिक भंडार तक विस्तारित होगा। हमारे बैंक उदाहरण के लिए, किसी दिए गए ग्राहक के लिए सभी खातों का अनुरोध करते समय हमें प्रत्येक नोड से संपर्क करना होगा। तो हमें एक जटिलता O (N) पढ़ने को मिलती है, जहाँ N भौतिक भंडार की संख्या है। यह मंद-मंद मंद है।

बाल्टी आईडी द्वारा बाल्टियों और स्थानीयता का उपयोग करना एक नोड से एक अनुरोध का उपयोग करके आवश्यक डेटा को पढ़ना संभव बनाता है - क्लस्टर आकार की परवाह किए बिना।



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

बाल्टी के साथ पारंपरिक शार्किंग और वर्चुअल शार्किंग के बीच मुख्य अंतर क्या है?

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

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

प्रयोग

मान लीजिए कि हमने अपनी बकेट आईडी के लिए एक फ़ंक्शन का चयन किया है और क्लस्टर में इतने डेटा अपलोड किए हैं कि कोई जगह नहीं बची है। अब हम कुछ नोड्स जोड़ना चाहते हैं और स्वचालित रूप से उनके लिए डेटा स्थानांतरित करना चाहते हैं। वीएसहार्ड में हम ऐसा करते हैं: सबसे पहले, हम नए नोड्स शुरू करते हैं और वहां टारनटूल चलाते हैं, फिर हम अपने वीचर्ड कॉन्फ़िगरेशन को अपडेट करते हैं। इसमें हर क्लस्टर घटक, हर प्रतिकृति, प्रतिकृति सेट, मास्टर्स, असाइन किए गए यूआरआई और बहुत कुछ पर जानकारी शामिल है। अब हम अपने नए नोड्स को कॉन्फ़िगरेशन फ़ाइल में जोड़ते हैं, और इसे VShard.storage.cfg का उपयोग करके सभी क्लस्टर नोड्स पर लागू करते हैं।

 function create_user(email) local customer_id = next_id() local bucket_id = crc32(customer_id) box.space.customer:insert(customer_id, email, bucket_id) end function add_account(customer_id) local id = next_id() local bucket_id = crc32(customer_id) box.space.account:insert(id, customer_id, 0, bucket_id) end 

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



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

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

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

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



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

परमाणु बाल्टी प्रवास

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

कुछ मेटाडेटा भौतिक रूप से डिस्क पर संग्रहीत होती है जो प्रत्येक बाल्टी से जुड़ी होती है। ऊपर वर्णित सभी चरणों को डिस्क पर संग्रहीत किया जाता है, और कोई फर्क नहीं पड़ता कि भंडारण के लिए क्या होता है, बाल्टी राज्य स्वचालित रूप से बहाल हो जाएगा।

आपके कुछ निम्न प्रश्न हो सकते हैं:

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

VShard.router

VShard में दो सबमॉड्यूल होते हैं: VShard.storage और VShard.router। हम एक ही उदाहरण पर स्वतंत्र रूप से इन्हें बना और स्केल कर सकते हैं। क्लस्टर का अनुरोध करते समय, हम नहीं जानते कि एक दी गई बाल्टी कहां है, और VShard.router इसे बाल्टी आईडी द्वारा हमारे लिए खोज करेगा।

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



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

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

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

फेलओवर पढ़ें

आइए हमारी प्रारंभिक समस्याओं को याद करें:

• कोई डेटा स्थानीयता नहीं। बाल्टी के माध्यम से हल किया।
• पुनर्वसन प्रक्रिया नीचे की ओर झुकती है और सब कुछ वापस पकड़ती है। हमने बाल्टी के माध्यम से परमाणु डेटा हस्तांतरण को लागू किया और शार्द फ़ंक्शन पुनर्गणना से छुटकारा पा लिया।
• फेलओवर पढ़ें।

अंतिम अंक वीएसहार्ड.उटर द्वारा संबोधित किया गया है, जो स्वचालित रीड फ़ेलओवर सबसिस्टम द्वारा समर्थित है।

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



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

कॉन्फ़िगरेशन में ऐसा दिखता है:



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

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

फेलओवर लिखो

हम पहले ही फेलओवर के बारे में बात कर चुके हैं। मास्टर को बदलते समय विफलता के बारे में क्या लिखें? वीएसहार्ड में, चित्र पहले की तरह रसीला नहीं है: मास्टर चयन लागू नहीं किया गया है, इसलिए हमें इसे स्वयं करना होगा। जब हमने किसी तरह से एक मास्टर निर्दिष्ट किया है, तो निर्दिष्ट उदाहरण को अब मास्टर के रूप में लिया जाना चाहिए। फिर हम मास्टर को निर्दिष्ट करके कॉन्फ़िगरेशन को अपडेट करते हैं = पुराने मास्टर के लिए गलत है, और मास्टर = नए के लिए सच है, कॉन्फ़िगरेशन को VShard.storage.cfg के माध्यम से लागू करें और प्रत्येक भंडारण के साथ साझा करें। बाकी सब कुछ अपने आप हो जाता है। पुराना मास्टर लिखित अनुरोधों को स्वीकार करना बंद कर देता है और नए के साथ सिंक्रनाइज़ेशन शुरू करता है, क्योंकि ऐसे डेटा हो सकते हैं जो पुराने मास्टर पर पहले ही लागू हो चुके हैं लेकिन नए पर नहीं। उसके बाद, नया मास्टर प्रभारी है और अनुरोधों को स्वीकार करना शुरू कर देता है, और पुराने मास्टर एक प्रतिकृति है। यह है कि कैसे लिखते हैं असफलता VShard में काम करता है।

 replicas = new_cfg.sharding[uud].replicas replicas[old_master_uuid].master = false replicas[new_master_uuid].master = true vshard.storage.cfg(new_cfg) 

हम इन विभिन्न घटनाओं को कैसे ट्रैक करते हैं?

VShard.storage.info और VShard.router.info पर्याप्त हैं।

VShard.storage.info कई खंडों में जानकारी प्रदर्शित करता है।

 vshard.storage.info() --- - replicasets: <replicaset_2>: uuid: <replicaset_2> master: uri: storage@127.0.0.1:3303 <replicaset_1>: uuid: <replicaset_1> master: missing bucket: receiving: 0 active: 0 total: 0 garbage: 0 pinned: 0 sending: 0 status: 2 replication: status: slave Alerts: - ['MISSING_MASTER', 'Master is not configured for ''replicaset <replicaset_1>'] 

पहला खंड प्रतिकृति के लिए है। यहां आप प्रतिकृति सेट की स्थिति देख सकते हैं जहां फ़ंक्शन कहा जा रहा है: इसकी प्रतिकृति अंतराल, इसके उपलब्ध और अनुपलब्ध कनेक्शन, इसके मास्टर कॉन्फ़िगरेशन, आदि।

बाल्टी सेक्शन में, आप वास्तविक समय में वर्तमान प्रतिकृति सेट से / में माइग्रेट होने वाली बाल्टियों की संख्या, नियमित मोड में काम करने वाली बाल्टी की संख्या, कचरे के रूप में चिह्नित बाल्टी की संख्या और पिन की गई बाल्टी की संख्या देख सकते हैं।

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

और अंतिम खंड (q: यह "स्थिति" है?) एक प्रकाश है जो लाल हो जाता है जब सब कुछ गलत हो जाता है। यह शून्य से तीन की संख्या है, जिससे अधिक संख्या बदतर है।

VShard.router.info में समान खंड हैं, लेकिन उनका अर्थ कुछ अलग है।

 vshard.router.info() --- - replicasets: <replicaset_2>: replica: &0 status: available uri: storage@127.0.0.1:3303 uuid: 1e02ae8a-afc0-4e91-ba34-843a356b8ed7 bucket: available_rw: 500 uuid: <replicaset_2> master: *0 <replicaset_1>: replica: &1 status: available uri: storage@127.0.0.1:3301 uuid: 8a274925-a26d-47fc-9e1b-af88ce939412 bucket: available_rw: 400 uuid: <replicaset_1> master: *1 bucket: unreachable: 0 available_ro: 800 unknown: 200 available_rw: 700 status: 1 alerts: - ['UNKNOWN_BUCKETS', '200 buckets are not discovered'] 

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

बकेट सेक्शन में रीड-राइट और रीड-ओनली बकेट्स की कुल संख्या प्रदर्शित होती है जो वर्तमान में इस राउटर के लिए उपलब्ध हैं; एक अज्ञात स्थान के साथ बाल्टी की संख्या; और एक ज्ञात स्थान के साथ बाल्टी की संख्या लेकिन आवश्यक प्रतिकृति सेट के कनेक्शन के बिना।

अलर्ट अनुभाग मुख्य रूप से कनेक्शन, विफलता घटनाओं और अज्ञात बाल्टी का वर्णन करता है।

अंत में, सरल स्थिति भी है? शून्य से तीन तक संकेतक।

आपको वीशर्ड का उपयोग करने की क्या आवश्यकता है?

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

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

सारांश

वीचर्ड सुनिश्चित करता है:

• डेटा स्थानीयता
• परमाणु पुनरुत्थान
• उच्च क्लस्टर लचीलापन
• स्वचालित पढ़ने में विफलता
• कई बाल्टी नियंत्रक।

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

दूसरा कार्य लॉक-फ्री बकेट माइग्रेशन है । एक एल्गोरिथ्म पहले से ही लागू किया गया है जो प्रवास के दौरान भी बाल्टी को अनब्लॉक रखने में मदद करता है। प्रवास के दस्तावेज के लिए बाल्टी को अंत में केवल अवरुद्ध किया जाएगा।

तीसरा कार्य कॉन्फ़िगरेशन का परमाणु अनुप्रयोग है । कॉन्फ़िगरेशन को अलग से लागू करना सुविधाजनक या परमाणु नहीं है क्योंकि कुछ संग्रहण अनुपलब्ध हो सकते हैं, और यदि कॉन्फ़िगरेशन लागू नहीं है, तो हम आगे क्या करते हैं? यही कारण है कि हम स्वत: कॉन्फ़िगरेशन हस्तांतरण के लिए एक तंत्र पर काम कर रहे हैं।