NewSQL = NoSQL + ACID

हाल तक, ओडनोकलास्निक में, SQL सर्वर में लगभग 50 टीबी रीयल-टाइम डेटा संग्रहीत किया गया था। ऐसी मात्रा के लिए, SQL DBMS का उपयोग करके तेज़, विश्वसनीय और यहां तक ​​कि विफल-सुरक्षित डेटा केंद्र पहुंच प्रदान करना लगभग असंभव है। आमतौर पर ऐसे मामलों में वे NoSQL रिपॉजिटरी में से एक का उपयोग करते हैं, लेकिन हर चीज को NoSQL में स्थानांतरित नहीं किया जा सकता है: कुछ संस्थाओं को ACST लेनदेन की गारंटी की आवश्यकता होती है।

इसने हमें NewSQL- स्टोरेज का उपयोग करने के लिए प्रेरित किया, अर्थात, एक DBMS जो NoSQL-Systems की गलती को सहनशीलता, मापनीयता और प्रदर्शन प्रदान करता है, लेकिन साथ ही साथ ACID को क्लासिक सिस्टम से परिचित कराने की गारंटी देता है। इस नई कक्षा में कुछ काम करने वाली औद्योगिक प्रणालियाँ हैं, इसलिए हमने ऐसी प्रणाली को स्वयं लागू किया और इसे वाणिज्यिक परिचालन में डाल दिया।

यह कैसे काम करता है और क्या हुआ - कटौती के तहत पढ़ें।

आज, Odnoklassniki के मासिक दर्शक 70 मिलियन से अधिक अद्वितीय आगंतुक हैं। हम दुनिया के पांच सबसे बड़े सोशल नेटवर्क में से हैं, और बीस साइटें हैं जिन पर उपयोगकर्ता सबसे अधिक समय बिताते हैं। इन्फ्रास्ट्रक्चर "ओके" बहुत अधिक भार संभालता है: एक लाख से अधिक HTTP अनुरोधों / मोर्चों के लिए सेकंड। 8000 से अधिक टुकड़ों की मात्रा में सर्वर के बेड़े के हिस्से एक-दूसरे के करीब स्थित हैं - चार मॉस्को डेटा सेंटर में, जो उनके बीच 1 एमएस से कम के नेटवर्क विलंबता की अनुमति देता है।

हम 2010 से कासांद्रा का उपयोग कर रहे हैं, संस्करण 0.6 से शुरू कर रहे हैं। आज, कई दर्जन क्लस्टर परिचालन में हैं। सबसे तेज़ क्लस्टर प्रति सेकंड 4 मिलियन से अधिक संचालन की प्रक्रिया करता है, और सबसे बड़ा 260 टीबी स्टोर करता है।

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

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

तेज करने और एसक्यूएल को गति देने के लिए धन्यवाद:

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

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

SQL समस्याएँ

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

लेकिन मुख्य समस्या है

दोष सहिष्णुता

क्लासिक SQL सर्वर में खराब सहिष्णुता है। मान लीजिए कि आपके पास केवल एक डेटाबेस सर्वर है, और यह हर तीन साल में एक बार विफल होता है। इस समय, साइट 20 मिनट तक काम नहीं करती है, यह स्वीकार्य है। यदि आपके पास 64 सर्वर हैं, तो साइट हर तीन सप्ताह में एक बार काम नहीं करती है। और अगर आपके पास 200 सर्वर हैं, तो साइट हर हफ्ते काम नहीं करती है। यह एक समस्या है।

SQL सर्वर रिज़ॉल्यूशन को बेहतर बनाने के लिए क्या किया जा सकता है? विकिपीडिया हमें एक अत्यधिक सुलभ क्लस्टर बनाने की पेशकश करता है: जहां किसी भी घटक की विफलता के मामले में एक डुप्लिकेट है।

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

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

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

इन सभी समस्याओं के लिए एक मौलिक समाधान की आवश्यकता थी और हम उनके विस्तृत विश्लेषण के लिए आगे बढ़े। यहां हमें SQL सर्वर से मूल रूप से परिचित होने की आवश्यकता है - लेनदेन।

साधारण लेन-देन

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

1. हम कुंजी द्वारा एल्बम को लॉक करते हैं।
2. फोटो तालिका में एक प्रविष्टि बनाएँ।
3. यदि तस्वीर में सार्वजनिक स्थिति है, तो हम एल्बम में सार्वजनिक फोटो काउंटर को हवा देते हैं, रिकॉर्ड को अपडेट करते हैं और लेनदेन करते हैं।

या छद्म कोड के रूप में:

TX.start("Albums", id); Album album = albums.lock(id); Photo photo = photos.create(…); if (photo.status == PUBLIC ) { album.incPublicPhotosCount(); } album.update(); TX.commit(); 

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

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

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

अन्य समान रूप से महत्वपूर्ण आवश्यकताएं थीं:

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

निर्णय, निर्णय

संभावित समाधानों का विश्लेषण करते हुए, हम दो संभावित वास्तुकला विकल्पों में आए:

सबसे पहले किसी भी SQL सर्वर को लेना और आवश्यक दोष सहिष्णुता, स्केलिंग तंत्र, विफलता क्लस्टर, संघर्ष समाधान और वितरित, विश्वसनीय और तेज़ ACID लेनदेन को लागू करना है। हमने इस विकल्प को अत्यधिक गैर-तुच्छ और समय लेने वाला माना है।

दूसरा विकल्प एक तैयार किए गए NoSQL रिपॉजिटरी को कार्यान्वित स्केलिंग, एक फेलओवर क्लस्टर, संघर्ष रिज़ॉल्यूशन के साथ लेना और लेनदेन और SQL को स्वयं लागू करना है। पहली नज़र में, यहां तक ​​कि SQL को लागू करने का कार्य, ACID लेनदेन का उल्लेख नहीं करना, वर्षों के लिए एक कार्य की तरह दिखता है। लेकिन तब हमें महसूस हुआ कि SQL फीचर सेट जो हम व्यवहार में उपयोग करते हैं वह ANSI SQL से उतना ही दूर है जितना कि Cassandra CQL ANSI SQL से दूर है। CQL पर करीब से नज़र डालने पर, हमें एहसास हुआ कि यह पर्याप्त था जो हमें चाहिए था।

कैसंड्रा और सीक्यूएल

तो, कैसंड्रा के बारे में क्या दिलचस्प है, इसमें क्या क्षमताएं हैं?

सबसे पहले, यहां आप विभिन्न डेटा प्रकारों के समर्थन के साथ तालिकाओं का निर्माण कर सकते हैं, आप प्राथमिक कुंजी पर चयन या अद्यतन कर सकते हैं।

 CREATE TABLE photos (id bigint KEY, owner bigint,…); SELECT * FROM photos WHERE id=?; UPDATE photos SET … WHERE id=?; 

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

जब हम तीन नोड्स की ओर मुड़ते हैं और दो से उत्तर प्राप्त करते हैं, तो इसे अटकल कहा जाता है : अतिरिक्त टिप्पणी के लिए अनुरोध "बंद होने" से पहले ही भेज दिया जाता है।

कैसंड्रा का एक और फायदा बैचैच है - एक ऐसा तंत्र जो आपके द्वारा किए गए परिवर्तनों के पैकेज के पूर्ण आवेदन या पूर्ण गैर-अनुप्रयोग की गारंटी देता है। यह हमें ACID में A को हल करने की अनुमति देता है - बॉक्स से बाहर की परमाणुता।

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

कैसंड्रा में हमें क्या याद आया

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

सी * एक

तो नए C * One DBMS का जन्म हुआ, जिसमें तीन प्रकार के सर्वर नोड शामिल थे:

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

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

ग्राहकों

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

C * वन ट्रांजेक्शन कोऑर्डिनेटर

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

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

अवरुद्ध

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

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

चूंकि हमारे मामले में एसक्यूएल में स्थानीय लेनदेन समूहों द्वारा डेटा पहले से ही वितरित किया गया है, इसलिए स्थानीय समन्वय समूहों को समन्वयकों को सौंपने का निर्णय लिया गया था: एक समन्वयक 0 से 9 तक टोकन के साथ सभी लेनदेन करता है, दूसरा 10 से 19 के टोकन के साथ, और इसी तरह। नतीजतन, समन्वयक उदाहरणों में से प्रत्येक एक लेनदेन समूह मास्टर बन जाता है।

फिर ताले को समन्वयक की स्मृति में एक बैंलेस हैशपॉप के रूप में लागू किया जा सकता है।

समन्वयक विफलताओं

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

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



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

दिल की धड़कन संदेश उच्च आवृत्ति पर, प्रति सेकंड लगभग 20 बार, 50 एमएस की अवधि के साथ भेजे जाते हैं। जावा में, कचरा कलेक्टर द्वारा उत्पन्न विराम की तुलनात्मक लंबाई के कारण 50 एमएस की एक आवेदन प्रतिक्रिया की गारंटी देना मुश्किल है। हम G1 कचरा संग्राहक का उपयोग करके ऐसी प्रतिक्रिया समय प्राप्त करने में सक्षम थे, जो हमें GC Gauses की अवधि के लिए लक्ष्य निर्दिष्ट करने की अनुमति देता है। हालांकि, कभी-कभी, शायद ही कभी, कलेक्टर का ठहराव 50 एमएस से आगे निकल जाता है, जिससे विफलता का गलत पता चल सकता है। इसे रोकने के लिए, समन्वयक दूरस्थ नोड की विफलता की रिपोर्ट नहीं करता है जब पहला धड़कन संदेश इससे गायब हो जाता है, केवल अगर कई लगातार गायब हो जाते हैं। तो हम 200 एमएस में समन्वयक के नोड विफलता का पता लगाने में कामयाब रहे।

लेकिन यह जल्दी से समझना पर्याप्त नहीं है कि किस नोड ने काम करना बंद कर दिया है। आपको इसके बारे में कुछ करने की जरूरत है।

आरक्षण

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



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

सार्वभौमिक एल्गोरिथम की तुलना में ऐसी योजना अधिक विश्वसनीय है, क्योंकि एक नए मास्टर को सक्रिय करने के लिए यह पुराने की विफलता के तथ्य को निर्धारित करने के लिए पर्याप्त है।

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

बैकअप मास्टर्स अजन्मे लेनदेन की कतार में गैर-स्वयं के लेनदेन के लिए अनुरोध प्राप्त करते हैं, जहां वे कुछ समय के लिए संग्रहीत होते हैं। यदि सक्रिय मास्टर की मृत्यु हो जाती है, तो नए मास्टर अपनी कतार से लेनदेन खोलने के लिए अनुरोध करते हैं और ग्राहक को जवाब देते हैं। यदि ग्राहक पहले से ही पुराने मास्टर के साथ लेन-देन खोलने में कामयाब रहा है, तो दूसरी प्रतिक्रिया को अनदेखा किया जाता है (और, जाहिर है, इस तरह के लेनदेन को पूरा नहीं किया जाएगा और ग्राहक द्वारा दोहराया जाएगा)।

लेन-देन कैसे काम करता है

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



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



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

• यदि आईडी पहले से ही लेनदेन में है, तो डेटा मेमोरी से लिया जाता है;
• यदि मेमोरी में कोई आईडी नहीं है, तो लापता डेटा को स्टोरेज नोड्स से पढ़ा जाता है, जो पहले से ही मेमोरी में हैं, और परिणाम क्लाइंट को वापस कर दिया जाता है।

इस प्रकार, ग्राहक अपने स्वयं के परिवर्तनों को पढ़ सकते हैं, जबकि अन्य ग्राहक इन परिवर्तनों को नहीं देखते हैं, क्योंकि वे केवल समन्वयक की स्मृति में संग्रहीत हैं, वे अभी तक कैसंड्रा नोड्स में नहीं हैं।



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



और समन्वयक को वापस रोल करने के लिए, यह लेन-देन की स्थिति द्वारा कब्जा की गई मेमोरी को मुक्त करने के लिए पर्याप्त है।

उपरोक्त सुधारों के परिणामस्वरूप, हमने ACID के सिद्धांतों को लागू किया:

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

सूचकांक पढ़ना

एक साधारण तालिका लें:

 CREATE TABLE photos ( id bigint primary key, owner bigint, modified timestamp, …) 

उसके पास एक आईडी (प्राथमिक कुंजी), मालिक और परिवर्तन की तारीख है। आपको एक बहुत ही सरल अनुरोध करने की आवश्यकता है - "अंतिम दिन" के लिए परिवर्तन की तारीख के साथ मालिक की जानकारी का चयन करें।

 SELECT * WHERE owner=? AND modified>? 

इस तरह की क्वेरी के लिए जल्दी से काम करने के लिए, क्लासिक SQL DBMS में आपको कॉलम (स्वामी, संशोधित) द्वारा एक इंडेक्स बनाने की आवश्यकता होती है। हम इसे काफी सरलता से कर सकते हैं, क्योंकि अब हमारे पास ACID की गारंटी है!

सी * वन में संकेत

तस्वीरों के साथ एक स्रोत तालिका है, जिसमें रिकॉर्ड आईडी प्राथमिक कुंजी है।



सी * इंडेक्स के लिए, एक एक नई तालिका बनाता है, जो मूल की एक प्रति है। कुंजी सूचकांक की अभिव्यक्ति से मेल खाती है, और इसमें स्रोत तालिका से रिकॉर्ड की प्राथमिक कुंजी भी शामिल है:



अब "अंतिम दिन के लिए मालिक" के अनुरोध को एक अन्य तालिका से चयन के रूप में फिर से लिखा जा सकता है:

 SELECT * FROM i1_test WHERE owner=? AND modified>? 

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

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

क्या हुआ?

हमने सी * एक तीन साल पहले विकसित किया और इसे वाणिज्यिक परिचालन में डाल दिया।

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

जब हमने प्रतिकृति कारक = 1 के साथ SQL का उपयोग किया (लेकिन RAID 10 में), तो Microsoft SQL Server (प्लस 11 बैकअप) के साथ 32 मेटा के अत्यधिक सुलभ क्लस्टर पर फोटो मेटा-जानकारी संग्रहीत की गई थी। यह भी बैकअप भंडारण के लिए 10 सर्वर आवंटित किया। कुल 50 महंगी कारें। उसी समय, सिस्टम ने आरक्षित के बिना, रेटेड लोड पर काम किया।

नई प्रणाली में माइग्रेट करने के बाद, हमें प्रतिकृति कारक = 3 मिला - प्रत्येक डेटा सेंटर में एक प्रति। इस प्रणाली में ६३ सर्वरों के साथ ६३ कैसेंड्रा स्टोरेज नोड्स और ६ समन्वयक मशीनें हैं। लेकिन ये मशीनें बहुत सस्ती हैं, उनकी कुल लागत SQL में सिस्टम की लागत का लगभग 30% है। इस मामले में, लोड 30% रखा गया है।

सी * वन की शुरुआत के साथ, देरी में भी कमी आई: एसक्यूएल में, लेखन ऑपरेशन में लगभग 4.5 एमएस लिया गया। सी * वन में - लगभग 1.6 एमएस। लेन-देन की अवधि औसतन 40 एमएस से कम है, यह प्रतिबद्धता 2 एमएस में की जाती है, पढ़ने और लिखने की अवधि औसतन 2 एमएस है। 99 वाँ प्रतिशत - केवल 3-3.1 एमएस, समयबाह्य की संख्या में 100 गुना की कमी आई - यह सब अटकलों के व्यापक उपयोग के कारण है।

आज तक, अधिकांश SQL सर्वर नोड्स का विमोचन किया गया है, नए उत्पादों को केवल C * One का उपयोग करके विकसित किया गया है। हमने अपने वन-क्लाउड में काम करने के लिए सी * वन को अनुकूलित किया , जिसने हमें नए समूहों की तैनाती में तेजी लाने, कॉन्फ़िगरेशन को आसान बनाने और ऑपरेशन को स्वचालित करने की अनुमति दी। स्रोत कोड के बिना, यह और अधिक कठिन और बैसाखी बनाना होगा।

अब हम अपनी अन्य भंडारण सुविधाओं को क्लाउड में स्थानांतरित करने पर काम कर रहे हैं - लेकिन यह पूरी तरह से अलग कहानी है।