NewSQL = NoSQL+ACID

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

यसले हामीलाई NewSQL भण्डारणको प्रयोगमा डोऱ्‍यायो, त्यो हो, एक DBMS जसले दोष सहिष्णुता, स्केलेबिलिटी र NoSQL प्रणालीहरूको कार्यसम्पादन प्रदान गर्दछ, तर एकै समयमा ACID ग्यारेन्टीहरू राख्दा शास्त्रीय प्रणालीहरूसँग परिचित छ। यस नयाँ वर्गका केही काम गर्ने औद्योगिक प्रणालीहरू छन्, त्यसैले हामीले आफैंले यस्तो प्रणाली लागू गर्‍यौं र यसलाई व्यावसायिक रूपमा सञ्चालनमा ल्यायौं।

यो कसरी काम गर्दछ र के भयो - काट अन्तर्गत पढ्नुहोस्।

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

हामी 2010 देखि क्यासान्ड्रा प्रयोग गर्दैछौं, संस्करण 0.6 बाट सुरु हुँदै। आज त्यहाँ दर्जनौं क्लस्टरहरू सञ्चालनमा छन्। सबैभन्दा छिटो क्लस्टरले प्रति सेकेन्ड 4 मिलियन भन्दा बढी सञ्चालनहरू प्रशोधन गर्दछ, र सबैभन्दा ठूलो भण्डार 260 TB।

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

SQL सर्भर नोडहरूमा डाटा वितरण गर्न, हामीले ठाडो र तेर्सो दुवै प्रयोग गर्यौं विभाजन (sharding)। ऐतिहासिक रूपमा, हामीले एक साधारण डाटा शेर्डिङ योजना प्रयोग गर्‍यौं: प्रत्येक इकाई टोकनसँग सम्बन्धित थियो - इकाई आईडीको कार्य। एउटै टोकन भएका संस्थाहरू एउटै SQL सर्भरमा राखिएका थिए। मास्टर-विवरण सम्बन्ध लागू गरिएको थियो ताकि मुख्य र बाल रेकर्डहरूको टोकनहरू सधैं मिल्दो र एउटै सर्भरमा अवस्थित थिए। एक सामाजिक सञ्जालमा, लगभग सबै रेकर्डहरू प्रयोगकर्ताको तर्फबाट उत्पन्न हुन्छन् - जसको अर्थ एक कार्यात्मक उपप्रणाली भित्र सबै प्रयोगकर्ता डेटा एक सर्भरमा भण्डारण गरिन्छ। त्यो हो, एक व्यापार लेनदेन लगभग सधैं एक SQL सर्भरबाट तालिकाहरू समावेश गर्दछ, जसले स्थानीय ACID लेनदेनहरू प्रयोग गरेर डेटा स्थिरता सुनिश्चित गर्न सम्भव बनायो, प्रयोग गर्न आवश्यक बिना। ढिलो र अविश्वसनीय ACID लेनदेन वितरित।

sharding को लागी र SQL को गति को लागी धन्यवाद:

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

यी चरणहरूले हामीलाई 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();

हामी देख्छौं कि व्यापार लेनदेनको लागि सबैभन्दा सामान्य परिदृश्य डाटाबेसबाट एप्लिकेसन सर्भरको मेमोरीमा डाटा पढ्नु, केहि परिवर्तन गर्नुहोस् र डाटाबेसमा नयाँ मानहरू बचत गर्नुहोस्। सामान्यतया यस्तो लेनदेनमा हामी धेरै संस्थाहरू, धेरै तालिकाहरू अपडेट गर्छौं।

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

धेरै समान कोड, एक लेनदेन भित्र विभिन्न व्यापार संस्थाहरू हेरफेर, Odnoklassniki को सम्पूर्ण अस्तित्वमा लेखिएको छ। बाट NoSQL मा माइग्रेसनको अनुभवमा आधारित आकस्मिक स्थिरता हामीलाई थाहा छ कि सबैभन्दा ठूलो चुनौती (र समय लगानी) डेटा स्थिरता कायम राख्न कोड विकास गर्दा आउँछ। त्यसकारण, हामीले नयाँ भण्डारणको लागि मुख्य आवश्यकतालाई एप्लिकेसन तर्कको लागि वास्तविक ACID लेनदेनको प्रावधान मानेका छौं।

अन्य, कम महत्त्वपूर्ण छैन, आवश्यकताहरू थिए:

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

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

सम्भावित समाधानहरूको विश्लेषण गर्दै, हामी दुई सम्भावित वास्तुकला विकल्पहरूमा आएका छौं:

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

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

क्यासान्ड्रा र CQL

त्यसोभए, क्यासान्ड्राको बारेमा के रोचक छ, यसमा के क्षमताहरू छन्?

सर्वप्रथम, यहाँ तपाईँले विभिन्न प्रकारका डेटालाई समर्थन गर्ने तालिकाहरू सिर्जना गर्न सक्नुहुन्छ; तपाईँले प्राथमिक कुञ्जीमा SELECT वा अपडेट गर्न सक्नुहुन्छ।

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

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

हामीले तीनवटा नोडहरूलाई सम्पर्क गर्दा र दुईबाट प्रतिक्रिया प्राप्त गर्ने दृष्टिकोणलाई भनिन्छ अनुमान: अतिरिक्त प्रतिकृतिहरूको लागि अनुरोध पठाइन्छ यो "पत्न" अघि।

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

क्यासान्ड्रामा लेनदेनको सबैभन्दा नजिकको कुरा तथाकथित हो "हल्का लेनदेन"। तर तिनीहरू "वास्तविक" ACID लेनदेनबाट टाढा छन्: वास्तवमा, यो गर्ने अवसर हो कैस हेवीवेट प्याक्सोस प्रोटोकल प्रयोग गरेर सहमतिको प्रयोग गरेर मात्र एउटा रेकर्डबाट डाटामा। त्यसैले, यस्ता लेनदेनको गति कम छ।

हामी क्यासान्ड्रामा के हराइरहेका थियौं

त्यसोभए, हामीले क्यासान्ड्रामा वास्तविक ACID लेनदेनहरू लागू गर्नुपर्‍यो। जसको प्रयोग गरेर हामीले क्लासिक DBMS का दुई अन्य सुविधाजनक सुविधाहरू सजिलै कार्यान्वयन गर्न सक्छौं: लगातार द्रुत अनुक्रमणिकाहरू, जसले हामीलाई प्राथमिक कुञ्जीले मात्र होइन, र मोनोटोनिक स्वत:-बढ्दो ID हरूको नियमित जेनेरेटरबाट डेटा चयनहरू गर्न अनुमति दिन्छ।

सोली

यसरी नयाँ DBMS जन्मियो सोली, तीन प्रकारका सर्भर नोडहरू मिलेर:

• भण्डारण - (लगभग) मानक क्यासान्ड्रा सर्भरहरू स्थानीय डिस्कहरूमा डाटा भण्डारण गर्न जिम्मेवार। डेटाको लोड र भोल्युम बढ्दै जाँदा, तिनीहरूको मात्रा सजिलै दसौं र सयौं मा मापन गर्न सकिन्छ।
• लेनदेन समन्वयकहरू - लेनदेनको कार्यान्वयन सुनिश्चित गर्नुहोस्।
• ग्राहकहरू एप्लिकेसन सर्भरहरू हुन् जसले व्यवसाय सञ्चालनहरू लागू गर्छन् र लेनदेनहरू प्रारम्भ गर्छन्। यस्ता हजारौं ग्राहक हुन सक्छन् ।

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

ग्राहकहरू

मानक ड्राइभरहरूको सट्टा, फ्याट क्लाइन्ट मोड प्रयोग गरिन्छ। यस्तो नोडले डाटा भण्डार गर्दैन, तर अनुरोध कार्यान्वयनको लागि संयोजकको रूपमा काम गर्न सक्छ, अर्थात्, ग्राहक आफैले यसको अनुरोधहरूको संयोजकको रूपमा कार्य गर्दछ: यसले भण्डारण प्रतिकृतिहरू सोध्छ र विवादहरू समाधान गर्दछ। यो न केवल अधिक भरपर्दो र मानक ड्राइभर भन्दा छिटो छ, जसलाई टाढाको संयोजकसँग सञ्चार चाहिन्छ, तर तपाईंलाई अनुरोधहरूको प्रसारण नियन्त्रण गर्न पनि अनुमति दिन्छ। ग्राहकमा खुला लेनदेन बाहिर, रिपोजिटरीहरूमा अनुरोधहरू पठाइन्छ। यदि ग्राहकले लेनदेन खोलेको छ भने, लेनदेन भित्रका सबै अनुरोधहरू लेनदेन समन्वयकलाई पठाइन्छ।

C*एक लेनदेन समन्वयक

संयोजक भनेको हामीले C*One को लागि स्क्र्याचबाट लागू गरेको कुरा हो। यो लेनदेन, लक, र लेनदेन लागू हुने क्रम व्यवस्थापन गर्न जिम्मेवार छ।

प्रत्येक सेवा लेनदेनको लागि, संयोजकले टाइमस्ट्याम्प उत्पन्न गर्दछ: प्रत्येक पछिको लेनदेन अघिल्लो लेनदेन भन्दा ठूलो छ। किनकी क्यासान्ड्राको द्वन्द्व समाधान प्रणाली टाइमस्ट्याम्पहरूमा आधारित छ (दुई विवादित रेकर्डहरू, पछिल्लो टाइमस्ट्याम्पको साथ हालको मानिन्छ), विवाद सधैं पछिको लेनदेनको पक्षमा समाधान हुनेछ। यसरी कार्यान्वयन गर्यौं Lamport घडी - वितरण प्रणालीमा विवादहरू समाधान गर्न सस्तो तरिका।

लकहरू

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

गैर-वितरित वातावरणमा यस्तो लकिङ लागू गर्न सरल छ। वितरण प्रणालीमा, त्यहाँ दुई मुख्य विकल्पहरू छन्: या त क्लस्टरमा वितरित लक लागू गर्नुहोस्, वा लेनदेनहरू वितरण गर्नुहोस् ताकि समान अभिलेख समावेश हुने लेनदेनहरू सधैं एउटै संयोजकद्वारा सेवा गरिन्छ।

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

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

संयोजक असफल

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

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

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

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

तर कुन नोडले काम गर्न बन्द गरेको छ भनेर चाँडै बुझ्न पर्याप्त छैन। हामीले यसबारे केही गर्नुपर्छ।

आरक्षण

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

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

यो योजना सार्वभौमिक एल्गोरिथ्म भन्दा बढी भरपर्दो छ, किनकि नयाँ मास्टर सक्रिय गर्न यो पुरानो को विफलता निर्धारण गर्न पर्याप्त छ।

तर अब कुन मास्टरले काम गरिरहेको छ भनेर ग्राहकहरूले कसरी बुझ्लान्? 50 ms मा हजारौं ग्राहकहरूलाई जानकारी पठाउन असम्भव छ। यस्तो स्थिति सम्भव छ जब ग्राहकले लेनदेन खोल्न अनुरोध पठाउँछ, यो मास्टरले काम गरिरहेको छैन भनेर अझै थाहा छैन, र अनुरोधको समय समाप्त हुनेछ। यो हुनबाट रोक्नको लागि, ग्राहकहरूले अनुमानित रूपमा समूह मास्टर र उहाँका दुवै रिजर्भहरू एकैचोटि एक लेनदेन खोल्न अनुरोध पठाउँछन्, तर केवल एक जो यस समयमा सक्रिय मास्टर हो यो अनुरोधलाई जवाफ दिनेछ। ग्राहकले लेनदेन भित्र सबै पछिल्ला संचारहरू सक्रिय मास्टरसँग मात्र गर्नेछ।

ब्याकअप मास्टर्स प्लेसले लेनदेनको लागि अनुरोधहरू प्राप्त गर्यो जुन तिनीहरूको नभएको लेनदेनको कतारमा हुन्छ, जहाँ तिनीहरू केही समयको लागि भण्डारण हुन्छन्। यदि सक्रिय मास्टरको मृत्यु भयो भने, नयाँ मास्टरले आफ्नो लामबाट लेनदेनहरू खोल्न अनुरोधहरू प्रक्रिया गर्दछ र ग्राहकलाई जवाफ दिन्छ। यदि ग्राहकले पहिले नै पुरानो मास्टरसँग लेनदेन खोलेको छ भने, त्यसपछि दोस्रो प्रतिक्रियालाई बेवास्ता गरिन्छ (र, स्पष्ट रूपमा, यस्तो लेनदेन पूरा हुनेछैन र ग्राहकद्वारा दोहोर्याइनेछ)।

लेनदेन कसरी काम गर्दछ

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

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

जब ग्राहकले सक्रिय लेनदेनको भागको रूपमा आफ्नै परिवर्तन गरिएको डाटा अनुरोध गर्दछ, समन्वयकले निम्नानुसार कार्य गर्दछ:

• यदि आईडी पहिले नै लेनदेनमा छ भने, त्यसपछि डाटा मेमोरीबाट लिइन्छ;
• यदि आईडी मेमोरीमा छैन भने, हराएको डाटा भण्डारण नोडहरूबाट पढिन्छ, मेमोरीमा पहिले नै भएकाहरूसँग मिलाएर, र परिणाम ग्राहकलाई दिइन्छ।

यसैले, ग्राहकले आफ्नै परिवर्तनहरू पढ्न सक्छ, तर अन्य ग्राहकहरूले यी परिवर्तनहरू देख्दैनन्, किनभने तिनीहरू केवल संयोजकको मेमोरीमा भण्डार गरिएका छन्; तिनीहरू अझै क्यासान्ड्रा नोडहरूमा छैनन्।

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

र रोलब्याक गर्न, संयोजकले मात्र लेनदेन स्थिति द्वारा कब्जा गरिएको मेमोरी खाली गर्न आवश्यक छ।

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

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

अनुक्रमणिका द्वारा पढाइ

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

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

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

SELECT *
WHERE owner=?
AND modified>?

यस्तो क्वेरी छिटो प्रशोधन गर्नको लागि, क्लासिक SQL DBMS मा तपाईंले स्तम्भहरू (मालिक, परिमार्जित) द्वारा अनुक्रमणिका निर्माण गर्न आवश्यक छ। हामी यो धेरै सजिलै गर्न सक्छौं, किनकि हामीसँग अब ACID ग्यारेन्टीहरू छन्!

C*One मा अनुक्रमणिकाहरू

त्यहाँ तस्बिरहरू भएको स्रोत तालिका छ जसमा रेकर्ड आईडी प्राथमिक कुञ्जी हो।

अनुक्रमणिकाको लागि, C*One ले नयाँ तालिका सिर्जना गर्दछ जुन मूलको प्रतिलिपि हो। कुञ्जी अनुक्रमणिका अभिव्यक्ति जस्तै हो, र यसले स्रोत तालिकाबाट रेकर्डको प्राथमिक कुञ्जी पनि समावेश गर्दछ:

अब "अन्तिम दिनको लागि मालिक" को लागि क्वेरी अर्को तालिकाबाट चयनको रूपमा पुन: लेख्न सकिन्छ:

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

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

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

के भयो

हामीले तीन वर्षअघि C*One विकास गरेका थियौं र यसलाई व्यावसायिक सञ्चालनमा ल्याएका थियौं।

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

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

नयाँ प्रणालीमा माइग्रेट गरेपछि, हामीले प्रतिकृति कारक = 3 - प्रत्येक डेटा केन्द्रमा प्रतिलिपि प्राप्त गर्यौं। प्रणालीमा 63 क्यासान्ड्रा भण्डारण नोडहरू र 6 समन्वयक मेसिनहरू छन्, कुल 69 सर्भरहरूको लागि। तर यी मेसिनहरू धेरै सस्तो छन्, तिनीहरूको कुल लागत SQL प्रणालीको लागतको लगभग 30% हो। एकै समयमा, लोड 30% मा राखिएको छ।

C*One को परिचय संग, विलम्बता पनि घट्यो: SQL मा, लेखन कार्यले लगभग 4,5 ms लियो। C*One मा - लगभग 1,6 ms। लेनदेन अवधि औसतमा 40 ms भन्दा कम छ, कमिट 2 ms मा पूरा हुन्छ, पढ्न र लेखन अवधि औसत 2 ms छ। 99th प्रतिशतक - केवल 3-3,1 ms, टाइमआउटको संख्या 100 गुणाले घटेको छ - सबै अनुमानको व्यापक प्रयोगको कारणले।

अहिले सम्म, धेरै जसो SQL सर्भर नोडहरू खारेज गरिएका छन्; नयाँ उत्पादनहरू केवल C*One प्रयोग गरेर विकास भइरहेका छन्। हामीले हाम्रो क्लाउडमा काम गर्नको लागि C*One लाई अनुकूलित गर्यौं एक बादल, जसले नयाँ क्लस्टरहरूको तैनातीलाई गति दिन, कन्फिगरेसन सरल र स्वचालित सञ्चालन गर्न सम्भव बनायो। स्रोत कोड बिना, यो गर्न धेरै गाह्रो र बोझिल हुनेछ।

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

स्रोत: www.habr.com