Yandex Cloud Platform: एलिप्टिक्स के बारे में और जानें

कुछ समय पहले मैंने एलिप्टिक्स के बारे में Hllr के बारे में बात करना शुरू किया - हमारे दोष-सहिष्णु ने कुंजी-मूल्य का भंडारण (वैसे, जीपीएल-लाइसेंस के तहत मुफ्त और वितरित) किया। तब मैंने आम तौर पर एलिप्टिक्स डिवाइस का वर्णन किया: ऑपरेशन के वास्तुकला और बुनियादी सिद्धांतों के बारे में, जिसके कारण सिस्टम की विश्वसनीयता हासिल की जाती है, सिस्टम का विस्तार कैसे किया जा सकता है, और विफलताओं के मामले में यह कैसे व्यवहार करता है।

इस लेख से शुरू करते हुए, आइलेटिक्स में गहराई से गोता लगाने की कोशिश करते हैं: मैं आपको आंतरिक वास्तुकला और विभिन्न समर्थित विशेषताओं के बारे में बताना चाहता हूं।



आज - एलिप्टिक्स के नेटवर्क और सॉफ्टवेयर वास्तुकला और इसकी कुछ विशेषताओं के बारे में। मैं स्थानीय डेटा भंडारण के लिए कैश और हमारे निम्न-स्तरीय पुस्तकालय के बारे में भी विस्तार से बात करूंगा - एब्बल ।

शब्दकोश

शुरू करने के लिए, हम एक दूसरे को बेहतर ढंग से समझने के लिए अवधारणाओं का एक छोटा सा सेट पेश करते हैं:

• नोड - एलिप्टिक्स नेटवर्क में नोड्स में से एक;
• एक समूह DHT रिंगों में से एक है, प्रत्येक नोड समूहों में से एक से संबंधित है;
• आईडी - एलिप्टिक्स में तत्व की अनूठी कुंजी;
• सर्वर - सर्वर नोड;
• ग्राहक - ग्राहक नोड।

नेटवर्क वास्तुकला

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

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

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

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

एलिप्टिक्स नोड्स के बीच संचार के लिए मल्टीप्लेक्सिंग समर्थन के साथ अपने स्वयं के एक्स्टेंसिबल अतुल्यकालिक बाइनरी प्रोटोकॉल का उपयोग करता है। प्रत्येक पैकेट में एक हेडर और संभवतः एक अनुरोध या प्रतिक्रिया का निकाय है।

शीर्षक इंगित करता है:

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

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

क्या अण्डाकार अलग करता है

बड़े नेटवर्क में, नेटवर्क प्रवाह को प्राथमिकता देने से जुड़ी समस्याएं हैं, इसे हल करने के कई तरीके हैं।

सबसे पहले, आप आईपी पैकेट में टीओएस (प्रकार की सेवा) क्षेत्र का उपयोग करके "रंग" कर सकते हैं। इस स्थिति में, आप क्लाइंट से सर्वर और सर्वर के बीच अनुरोधों को प्राथमिकता दे सकते हैं। इसके लिए, एलिप्टिक्स में सर्वर_नेट_प्रियो और क्लाइंट_नेट_प्रियो विकल्प का उपयोग किया जाता है।



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



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

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

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

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

सर्वर आर्किटेक्चर

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



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

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

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

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

1. क्लाइंट कार्य को पूरा करने के लिए सर्वर के लिए एक अनुरोध भेजता है, अनुरोध में आवेदन का नाम, घटना का नाम और बाइनरी डेटा - घटना के तर्क शामिल हैं;
2. सर्वर वांछित अनुप्रयोग के लिए कोकेन के माध्यम से एक अनुरोध भेजता है;
3. कोकीन, यदि आवश्यक हो, तो एप्लिकेशन का एक नया उदाहरण लॉन्च करता है, उनके जीवन समय और भार की निगरानी करता है;
4. आवेदन अनुरोध को संसाधित करता है, यदि आवश्यक हो, तो अन्य अनुप्रयोगों के प्रसंस्करण के लिए संदेश भेजता है (जो अन्य मशीनों पर हो सकता है)। प्रत्येक एप्लिकेशन क्लाइंट को कुछ डेटा भेज सकता है।
5. अंतिम एप्लिकेशन क्लाइंट को कार्य पूरा होने के बारे में सूचित करता है।

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

कैश

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



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

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

कुल मिलाकर, कैश को 4 डेटा संरचनाओं का समर्थन करने की आवश्यकता है - LRU सूचियों (SLRU में प्रति पृष्ठ सूची), कुंजियों द्वारा खोज करने के लिए एक द्विआधारी वृक्ष, टाइमआउट के लिए प्राथमिकताओं के साथ एक कतार और डिस्क के साथ सिंक के लिए प्राथमिकताओं के साथ एक कतार। हालांकि, आखिरी 3 संरचनाएं कार्टेशियन पेड़ के ऊपर काफी अच्छी तरह से रखी गई हैं - कुंजियों के ऊपर बाइनरी ट्री और "घटनाओं" के ऊपर ढेर, जहां "घटना" सिंक या क्षय करने के लिए कुंजी का समय है। लेकिन एक ही समय में, मानक अभ्यास के विपरीत, जब ढेर पर यादृच्छिक भार के कारण संतुलन हासिल किया जाता है, तो हमारा पेड़ "यादृच्छिक" कुंजियों के कारण संतुलित होता है। और हमारे साथ कुंजियों को इस तथ्य के कारण यादृच्छिक माना जा सकता है कि वे Sha512 फ़ंक्शन द्वारा क्रिप्टोग्राफ़िक हैशिंग के परिणाम हैं।

बैकएंड

अंत में, मैं संक्षेप में हमारे मुख्य बैकेंड के बारे में बात करूंगा - एबलोब । एलिप्टिक्स के पूरे इतिहास में, कई अलग-अलग पुस्तकालयों का परीक्षण किया गया है, उदाहरण के लिए, Google LevelDB, टोक्यो / क्योटो कैबिनेट, ओरेकल बर्कलेबीडी, फ़ाइल सिस्टम। हमारे कार्यों के लिए, Eblob मध्यम (एक किलोबाइट से अधिक) और बड़े (गीगाबाइट के दसियों) डेटा संस्करणों को संग्रहीत करने के लिए सबसे अच्छी स्थानीय प्रणाली बन गई।

तो, Eblob हमारे निम्न-स्तरीय ओपन सोर्स एपेंड-ओनली लाइब्रेरी है, जिसमें डेटा को ब्लॉब्स में संग्रहीत करने के लिए है।

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



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

उस बूँद की खोज करने के लिए जिसमें कुंजी निहित है, कई तरकीबों का उपयोग किया जाता है:

• स्मृति में अभी तक छंटनी नहीं की गई सभी सूचकांक;
• सॉर्ट किए गए ब्लब्स के द्वारा, प्रत्येक ब्लूम के लिए एक ब्लूम फ़िल्टर बनाया जाता है और बूँद में प्रत्येक 40 (डिफ़ॉल्ट) कुंजियों के लिए एक पेड़ बनाया जाता है।
  
  • अगर ब्लूम फ़िल्टर कहता है कि कुंजी डिस्क पर हो सकती है, तो जिस रेंज में अनुरोधित कुंजी मिलनी चाहिए वह बाइनरी ट्री में खोजी गई है।
  • पाया सीमा से संबंधित सूचकांक फ़ाइल का एक टुकड़ा डिस्क से पढ़ा जाता है, फिर उस पर एक द्विआधारी खोज किया जाता है।
  • यदि इंडेक्स फ़ाइल में कुंजी पाई जाती है, तो सटीक निर्देशांक के लिए पहले से ही एक बड़े ब्लॉब में एक अनुरोध किया जाता है।
  
  

निष्कर्ष

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