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

पहला, थोड़ा सिद्धांत।

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

शेयरिंग को दो प्रकारों में विभाजित किया गया है: पर्वतमाला द्वारा पैनापन और हैश द्वारा शार्किंग।

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

हैश के साथ साझा करना सरल है: क्लस्टर में प्रत्येक रिकॉर्ड से हम एक हैश फ़ंक्शन पर विचार करते हैं, हम एक भौतिक नोड के लिए हैश फ़ंक्शन के समान मान के साथ प्रविष्टियाँ जोड़ते हैं।

मैं हैश शेरिंग का उपयोग करके क्षैतिज स्केलिंग के बारे में बात करूंगा।

पिछला कार्यान्वयन

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

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}) 

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

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

टारनटूल शर्ड की एक और विशेषता यह थी कि जब प्रतिकृति सेट में कुछ नोड्स विफल हो जाते हैं, तो यह खराब रीड एक्सेसिबिलिटी दिखाता है ।

नया समाधान

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



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

 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}) 

हम इसके लिए इतने उत्सुक क्यों हैं? यदि हमारे पास क्लासिक शार्किंग है, तो डेटा उन सभी भौतिक भंडारणों में रेंग सकता है जो हमारे पास हैं। बैंक के साथ उदाहरण में, जब एक ग्राहक के सभी खातों का अनुरोध किया जाता है, तो आपको सभी नोड्स की ओर मुड़ना होगा। यह ओ (एन) को पढ़ने में कठिनाई का पता लगाता है, जहां एन भौतिक भंडार की संख्या है। धीमी गति से।

bucket id द्वारा बाल्टीम और इलाके के लिए धन्यवाद bucket id हम हमेशा क्लस्टर अनुरोध की परवाह किए बिना एक अनुरोध में एक नोड से डेटा पढ़ सकते हैं।



आपको bucket id गणना करने की आवश्यकता है और स्वयं समान मान निर्दिष्ट करें। किसी के लिए, यह एक फायदा है, किसी के लिए नुकसान है। मैं इसे एक फायदा मानता हूं कि आप खुद bucket id गणना के लिए फ़ंक्शन चुन सकते हैं।

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

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

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

के उपयोग

मान लीजिए कि हमने bucket id लिए एक फ़ंक्शन चुना और क्लस्टर में इतना डेटा डाला कि कोई और जगह नहीं थी। अब हम नोड्स जोड़ना चाहते हैं, और इसलिए कि डेटा स्वयं उनके पास चले गए। VShard में, यह निम्नानुसार किया जाता है। सबसे पहले, उन पर नए नोड्स और टारनटूल लॉन्च करें, और फिर VShard कॉन्फ़िगरेशन को अपडेट करें। यह सभी क्लस्टर सदस्यों, सभी प्रतिकृतियों, प्रतिकृति सेटों, मास्टर्स, असाइन किए गए यूआरआई और बहुत कुछ का वर्णन करता है। हम कॉन्फ़िगरेशन में नए नोड्स जोड़ते हैं, और VShard.storage.cfg फ़ंक्शन का उपयोग करते VShard.storage.cfg , 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 को नोड्स में से एक पर बुलाया जाता है, तो पुनर्संतुलन प्रक्रिया जाग जाती है। यह एक विश्लेषणात्मक प्रक्रिया है जो एक क्लस्टर में सही संतुलन की गणना करती है। वह सभी भौतिक नोड्स में जाता है, पूछता है कि किसके पास कितनी बाल्टी है, और वितरण को औसत करने के लिए अपने आंदोलन के लिए मार्ग बनाता है। रिबेलर भीड़-भाड़ वाले मार्गों पर मार्ग भेजता है, और वे बाल्टी भेजना शुरू करते हैं। कुछ समय बाद, क्लस्टर संतुलित हो जाता है।

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

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



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

एटॉमिक बकेट ट्रांसफर

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

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

आपके प्रश्न हो सकते हैं:

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

VShard.router

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

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



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

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

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

अस्थिरता पढ़ें

याद रखें कि शुरू में हमें कौन सी समस्याएँ थीं:

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

पिछली समस्या को स्वचालित रीड फ़ेलओवर सबसिस्टम का उपयोग करके VShard.router द्वारा हल किया जाता है।

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



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

यह विन्यास में कैसा दिखता है:



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

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

रिकॉर्डिंग अस्थिरता

जब से हम रीड फेलओवर के बारे में बात कर रहे हैं, विज़ार्ड बदलते समय फेलओवर के बारे में क्या लिखें? यहां, वीएसएचआरडी इतनी रसीली नहीं है: एक नए मास्टर का चुनाव इसमें लागू नहीं होता है, आपको इसे स्वयं करना होगा। जब हमने किसी तरह इसे चुना, तो यह आवश्यक है कि यह उदाहरण अब मास्टर के अधिकार को संभाल ले। हम master = false को निर्दिष्ट करके कॉन्फ़िगरेशन को अपडेट करते हैं master = false पुराने मास्टर के लिए master = false , और नए के लिए master = true , इसे 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>'] 

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

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

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

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

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'] 

पहला खंड प्रतिकृति है। , : , replica set' , , , replica set' bucket' , .

Bucket bucket', ; bucket' ; , replica set'.

Alert, , , failover, bucket'.

, .

VShard?

— bucket'. int32_max ? bucket' — 30 16 . bucket', . bucket', bucket'. , .

— - bucket id . , - , bucket — . , bucket' , VShard bucket'. -, bucket' bucket, -. .

सारांश

Vshard :

• ;
• ;
• ;
• read failover;
• bucket'.

VShard . - . — . , . .

— lock-free bucket' . , bucket' . , .

— . : - , , ? .