न्यूएसक्यूएल = नोएसक्यूएल+एसिड

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

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

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

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

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

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

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

शार्डिंग और SQL को तेज़ करने के लिए धन्यवाद:

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

इन चरणों ने हमें 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();

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

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

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

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

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

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

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

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

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

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

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

सबसे पहले, यहां आप विभिन्न डेटा प्रकारों का समर्थन करने वाली तालिकाएँ बना सकते हैं; आप प्राथमिक कुंजी पर SELECT या UPDATE कर सकते हैं।

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

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

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

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

कैसंड्रा में लेन-देन की सबसे निकटतम चीज़ तथाकथित "हल्के लेनदेन". लेकिन वे "वास्तविक" ACID लेनदेन से बहुत दूर हैं: वास्तव में, यह करने का एक अवसर है कैस हेवीवेट पैक्सोस प्रोटोकॉल का उपयोग करके सर्वसम्मति का उपयोग करते हुए, केवल एक रिकॉर्ड से डेटा पर। इसलिए, ऐसे लेनदेन की गति कम है।

कैसेंड्रा में हम क्या खो रहे थे

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

सी*एक

इस प्रकार एक नये DBMS का जन्म हुआ सी*एक, तीन प्रकार के सर्वर नोड्स से युक्त:

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

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

ग्राहक

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

सी*वन लेनदेन समन्वयक

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

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

ताले

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

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

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

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

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

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

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

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

दिल की धड़कन के संदेश उच्च आवृत्ति पर, प्रति सेकंड लगभग 20 बार, 50 एमएस की अवधि के साथ भेजे जाते हैं। जावा में, कचरा संग्रहकर्ता के कारण होने वाले रुकावटों की तुलनीय लंबाई के कारण 50 एमएस के भीतर एप्लिकेशन प्रतिक्रिया की गारंटी देना मुश्किल है। हम G1 कचरा संग्राहक का उपयोग करके इस प्रतिक्रिया समय को प्राप्त करने में सक्षम थे, जो हमें GC ठहराव की अवधि के लिए एक लक्ष्य निर्दिष्ट करने की अनुमति देता है। हालाँकि, कभी-कभी, बहुत ही कम, कलेक्टर 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 गारंटी है!

सी*वन में सूचकांक

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

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

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

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

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

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

क्या हुआ

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

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

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

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

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

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

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

स्रोत: www.habr.com