NewSQL = NoSQL+ACID

अलीकडे पर्यंत, Odnoklassniki ने SQL सर्व्हरमध्ये रिअल टाइममध्ये प्रक्रिया केलेला सुमारे 50 TB डेटा संग्रहित केला होता. अशा व्हॉल्यूमसाठी, SQL DBMS वापरून जलद आणि विश्वासार्ह आणि डेटा सेंटर अयशस्वी-सहनशील प्रवेश प्रदान करणे जवळजवळ अशक्य आहे. सामान्यतः, अशा प्रकरणांमध्ये, NoSQL स्टोरेजपैकी एक वापरले जाते, परंतु सर्व काही NoSQL मध्ये हस्तांतरित केले जाऊ शकत नाही: काही संस्थांना ACID व्यवहार हमी आवश्यक असते.

यामुळे आम्हाला NewSQL स्टोरेजचा वापर करण्यास प्रवृत्त केले, म्हणजेच एक DBMS जो फॉल्ट टॉलरन्स, स्केलेबिलिटी आणि NoSQL सिस्टीमची कार्यक्षमता प्रदान करतो, परंतु त्याच वेळी शास्त्रीय प्रणालींशी परिचित असलेली ACID हमी राखून ठेवतो. या नवीन वर्गाच्या काही कार्यरत औद्योगिक प्रणाली आहेत, म्हणून आम्ही स्वतः अशी प्रणाली लागू केली आणि ती व्यावसायिक कार्यात आणली.

ते कसे कार्य करते आणि काय झाले - कट अंतर्गत वाचा.

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

आम्ही 2010 पासून कॅसॅन्ड्रा वापरत आहोत, आवृत्ती 0.6 पासून सुरू होते. आज अनेक डझन क्लस्टर कार्यरत आहेत. सर्वात वेगवान क्लस्टर प्रति सेकंद 4 दशलक्ष ऑपरेशन्सवर प्रक्रिया करतो आणि सर्वात मोठा 260 TB स्टोअर करतो.

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

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

शार्डिंग आणि एसक्यूएलची गती वाढवल्याबद्दल धन्यवाद:

• आम्ही परदेशी की मर्यादा वापरत नाही, कारण घटक आयडी शार्ड करताना दुसर्‍या सर्व्हरवर असू शकतो.
• DBMS CPU वर अतिरिक्त भार असल्यामुळे आम्ही संचयित प्रक्रिया आणि ट्रिगर वापरत नाही.
• वरील सर्व गोष्टींमुळे आणि डिस्कवरून अनेक यादृच्छिक वाचनांमुळे आम्ही जॉइन वापरत नाही.
• व्यवहाराच्या बाहेर, डेडलॉक कमी करण्यासाठी आम्ही रीड अनकमिटेड आयसोलेशन स्तर वापरतो.
• आम्ही फक्त लहान व्यवहार करतो (सरासरी 100 ms पेक्षा कमी).
• डेडलॉकच्या मोठ्या संख्येमुळे आम्ही बहु-पंक्ती अद्यतन आणि हटवा वापरत नाही - आम्ही एका वेळी फक्त एक रेकॉर्ड अद्यतनित करतो.
• आम्ही नेहमी फक्त अनुक्रमणिकेवर क्वेरी करतो - आमच्यासाठी संपूर्ण टेबल स्कॅन योजना असलेली क्वेरी म्हणजे डेटाबेस ओव्हरलोड करणे आणि ते अयशस्वी होणे.

या चरणांमुळे आम्हाला एसक्यूएल सर्व्हरमधून जवळजवळ जास्तीत जास्त कामगिरी पिळून काढता आली. तथापि, समस्या अधिकाधिक असंख्य होत गेल्या. त्यांच्याकडे पाहू.

SQL सह समस्या

• आम्ही स्व-लिखित शार्डिंग वापरले असल्याने, नवीन शार्ड्स जोडणे प्रशासकांद्वारे व्यक्तिचलितपणे केले गेले. या सर्व वेळी, स्केलेबल डेटा प्रतिकृती विनंत्या सेवा देत नव्हत्या.
• सारणीतील नोंदींची संख्या जसजशी वाढत जाते, तसतसे समाविष्ट करण्याचा आणि बदलाचा वेग कमी होतो; विद्यमान सारणीमध्ये अनुक्रमणिका जोडताना, गती एका घटकाने कमी होते; निर्देशांकांची निर्मिती आणि पुनर्निर्मिती डाउनटाइमसह होते.
• उत्पादनामध्ये SQL सर्व्हरसाठी थोड्या प्रमाणात Windows असणे पायाभूत सुविधांचे व्यवस्थापन कठीण करते

पण मुख्य समस्या आहे

चुकीची सहनशीलता

क्लासिक SQL सर्व्हरमध्ये खराब दोष सहिष्णुता आहे. समजा तुमच्याकडे फक्त एक डेटाबेस सर्व्हर आहे आणि तो दर तीन वर्षांनी एकदा अयशस्वी होतो. या वेळी साइट 20 मिनिटांसाठी खाली आहे, जी स्वीकार्य आहे. तुमच्याकडे 64 सर्व्हर असल्यास, दर तीन आठवड्यांनी एकदा साइट डाउन होते. आणि आपल्याकडे 200 सर्व्हर असल्यास, साइट दर आठवड्याला कार्य करत नाही. ही समस्या आहे.

SQL सर्व्हरची फॉल्ट टॉलरन्स सुधारण्यासाठी काय केले जाऊ शकते? विकिपीडिया आम्हाला तयार करण्यासाठी आमंत्रित करतो अत्यंत उपलब्ध क्लस्टर: जेथे कोणतेही घटक अयशस्वी झाल्यास तेथे एक बॅकअप आहे.

यासाठी महागड्या उपकरणांचा ताफा आवश्यक आहे: असंख्य डुप्लिकेशन्स, ऑप्टिकल फायबर, शेअर्ड स्टोरेज आणि रिझर्व्हचा समावेश विश्वासार्हपणे कार्य करत नाही: सुमारे 10% स्विचिंग मुख्य नोडच्या मागे असलेल्या ट्रेनप्रमाणे बॅकअप नोडच्या अपयशाने संपतात.

परंतु अशा अत्यंत उपलब्ध क्लस्टरचा मुख्य तोटा म्हणजे शून्य उपलब्धता आहे जर ते स्थित असलेले डेटा सेंटर अयशस्वी झाले. ओड्नोक्लास्निकीमध्ये चार डेटा सेंटर आहेत आणि त्यापैकी एकामध्ये पूर्ण अपयशी झाल्यास आम्हाला ऑपरेशन सुनिश्चित करण्याची आवश्यकता आहे.

यासाठी आपण वापरू शकतो मल्टी-मास्टर 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 ला काही अन्य मूल्यावर बदलणे आणि संबंधित काउंटर बंद करणे. साहजिकच, जर हे ऑपरेशन ऍप्लिकेशनच्या अणुत्वाची हमी न देता आणि स्पर्धात्मक बदलांच्या पृथक्करणाशिवाय घडले तर, जसे की आम्ल, नंतर परिणाम आवश्यक असणार नाही - एकतर फोटो काउंटर चुकीचे मूल्य दर्शवेल, किंवा सर्व फोटो नियंत्रणासाठी पाठवले जाणार नाहीत.

ओड्नोक्लास्निकीच्या संपूर्ण अस्तित्वात अनेक समान कोड, एका व्यवहारात विविध व्यवसाय संस्था हाताळत आहेत. पासून NoSQL कडे स्थलांतर करण्याच्या अनुभवावर आधारित घटनात्मक सुसंगतता आम्हाला माहित आहे की डेटाची सातत्य राखण्यासाठी कोड विकसित करण्यापासून सर्वात मोठे आव्हान (आणि वेळेची गुंतवणूक) येते. म्हणून, आम्ही नवीन स्टोरेजसाठी ऍप्लिकेशन लॉजिकसाठी वास्तविक ACID व्यवहारांसाठी तरतूद करणे ही मुख्य आवश्यकता मानली.

इतर, कमी महत्त्वाच्या नाहीत, आवश्यकता होत्या:

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

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

संभाव्य उपायांचे विश्लेषण करून, आम्ही दोन संभाव्य आर्किटेक्चर निवडींवर आलो:

पहिला म्हणजे कोणताही SQL सर्व्हर घेणे आणि आवश्यक फॉल्ट टॉलरन्स, स्केलिंग यंत्रणा, फेलओव्हर क्लस्टर, संघर्ष निराकरण आणि वितरित, विश्वासार्ह आणि जलद ACID व्यवहार लागू करणे. आम्ही हा पर्याय अतिशय क्षुल्लक आणि श्रम-केंद्रित म्हणून रेट केला आहे.

दुसरा पर्याय म्हणजे अंमलात आणलेल्या स्केलिंगसह रेडीमेड NoSQL स्टोरेज घेणे, फेलओव्हर क्लस्टर, विरोधाभास सोडवणे आणि स्वतः व्यवहार आणि SQL लागू करणे. पहिल्या दृष्टीक्षेपात, एसीआयडी व्यवहारांचा उल्लेख न करता SQL लागू करण्याचे कार्य देखील वर्षानुवर्षे जातील असे दिसते. पण नंतर आम्हाला समजले की आम्ही व्यवहारात वापरत असलेला SQL वैशिष्ट्य संच ANSI SQL पेक्षा खूप दूर आहे Cassandra CQL ANSI SQL पासून लांब. CQL कडे अधिक बारकाईने पाहिल्यावर, आम्हाला जाणवले की ते आम्हाला आवश्यक असलेल्या अगदी जवळ आहे.

Cassandra आणि CQL

तर, कॅसॅन्ड्राबद्दल काय मनोरंजक आहे, त्यात कोणती क्षमता आहे?

प्रथम, येथे तुम्ही विविध डेटा प्रकारांना सपोर्ट करणारे तक्ते तयार करू शकता; तुम्ही प्राथमिक की वर SELECT किंवा UPDATE करू शकता.

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

प्रतिकृती डेटा सुसंगतता सुनिश्चित करण्यासाठी, Cassandra वापरते कोरम दृष्टिकोन. सर्वात सोप्या बाबतीत, याचा अर्थ असा की जेव्हा एकाच पंक्तीच्या तीन प्रतिकृती क्लस्टरच्या वेगवेगळ्या नोड्सवर ठेवल्या जातात, तेव्हा बहुतेक नोड्सने (म्हणजे तीनपैकी दोन) या लेखन ऑपरेशनच्या यशस्वीतेची पुष्टी केली असल्यास लेखन यशस्वी मानले जाते. . पंक्ती डेटा सुसंगत मानला जातो जर, वाचताना, बहुसंख्य नोड्स पोल केले गेले आणि त्यांची पुष्टी केली गेली. अशा प्रकारे, तीन प्रतिकृतींसह, एक नोड अयशस्वी झाल्यास पूर्ण आणि त्वरित डेटा सुसंगततेची हमी दिली जाते. या दृष्टिकोनामुळे आम्हाला आणखी विश्वासार्ह योजना अंमलात आणता आली: नेहमी सर्व तीन प्रतिकृतींना विनंत्या पाठवा, दोन वेगवान प्रतिक्रियेची प्रतीक्षा करा. या प्रकरणात तिसऱ्या प्रतिकृतीचा उशीरा प्रतिसाद टाकून दिला जातो. प्रतिसाद देण्यास उशीर झालेल्या नोडमध्ये गंभीर समस्या असू शकतात - ब्रेक, JVM मध्ये कचरा गोळा करणे, लिनक्स कर्नलमध्ये थेट मेमरी पुन्हा दावा करणे, हार्डवेअर अपयश, नेटवर्कवरून डिस्कनेक्शन. तथापि, याचा कोणत्याही प्रकारे क्लायंटच्या ऑपरेशन्स किंवा डेटावर परिणाम होत नाही.

जेव्हा आपण तीन नोड्सशी संपर्क साधतो आणि दोनकडून प्रतिसाद प्राप्त करतो तेव्हा दृष्टीकोन म्हणतात अटकळ: अतिरिक्त प्रतिकृतींसाठी विनंती "पडण्याआधीच" पाठविली जाते.

कॅसॅन्ड्राचा आणखी एक फायदा म्हणजे बॅचलॉग, ही एक यंत्रणा जी तुम्ही करत असलेल्या बदलांची बॅच एकतर पूर्णपणे लागू केली आहे किंवा अजिबात लागू केलेली नाही याची खात्री करते. हे आम्हाला ACID मधील A सोडविण्यास अनुमती देते - बॉक्सच्या बाहेर अणू.

कॅसांड्रामधील व्यवहारांची सर्वात जवळची गोष्ट म्हणजे तथाकथित “हलके व्यवहार" परंतु ते “वास्तविक” ACID व्यवहारांपासून दूर आहेत: खरं तर, ही एक संधी आहे सीएएस हेवीवेट पॉक्सोस प्रोटोकॉल वापरून एकमत वापरून केवळ एका रेकॉर्डवरील डेटावर. त्यामुळे अशा व्यवहारांचा वेग कमी असतो.

कसंड्रामध्ये आम्ही काय गमावत होतो

त्यामुळे, आम्हाला कॅसांड्रामध्ये वास्तविक ACID व्यवहार लागू करावे लागले. ज्याचा वापर करून आम्ही क्लासिक DBMS ची इतर दोन सोयीस्कर वैशिष्ट्ये सहजपणे अंमलात आणू शकतो: सातत्यपूर्ण वेगवान अनुक्रमणिका, ज्यामुळे आम्हाला केवळ प्राथमिक की द्वारे डेटा निवड करणे शक्य होणार नाही आणि मोनोटोनिक स्वयं-वाढीव आयडीचे नियमित जनरेटर.

सुळका

अशा प्रकारे नवीन डीबीएमएसचा जन्म झाला सुळका, तीन प्रकारच्या सर्व्हर नोड्सचा समावेश आहे:

• स्टोरेज - (जवळजवळ) मानक कॅसॅन्ड्रा सर्व्हर स्थानिक डिस्कवर डेटा संचयित करण्यासाठी जबाबदार आहेत. डेटाचा लोड आणि व्हॉल्यूम जसजसा वाढत जातो, तसतसे त्यांचे प्रमाण दहापट आणि शेकडो पर्यंत सहजतेने वाढवता येते.
• व्यवहार समन्वयक - व्यवहारांची अंमलबजावणी सुनिश्चित करा.
• क्लायंट हे अॅप्लिकेशन सर्व्हर आहेत जे व्यवसाय ऑपरेशन्स अंमलात आणतात आणि व्यवहार सुरू करतात. असे हजारो ग्राहक असू शकतात.

सर्व प्रकारचे सर्व्हर एका सामान्य क्लस्टरचा भाग आहेत, एकमेकांशी संवाद साधण्यासाठी अंतर्गत Cassandra संदेश प्रोटोकॉल वापरतात आणि गप्पाटप्पा क्लस्टर माहितीची देवाणघेवाण करण्यासाठी. हार्टबीटसह, सर्व्हर परस्पर अपयशांबद्दल शिकतात, एकल डेटा स्कीमा राखतात - सारण्या, त्यांची रचना आणि प्रतिकृती; विभाजन योजना, क्लस्टर टोपोलॉजी इ.

ग्राहक

मानक ड्रायव्हर्सऐवजी, फॅट क्लायंट मोड वापरला जातो. असा नोड डेटा संचयित करत नाही, परंतु विनंती अंमलबजावणीसाठी समन्वयक म्हणून कार्य करू शकतो, म्हणजेच, क्लायंट स्वतः त्याच्या विनंत्यांचा समन्वयक म्हणून कार्य करतो: तो स्टोरेज प्रतिकृतींची चौकशी करतो आणि विवादांचे निराकरण करतो. हे केवळ मानक ड्रायव्हरपेक्षा अधिक विश्वासार्ह आणि वेगवान नाही, ज्यासाठी रिमोट कोऑर्डिनेटरसह संप्रेषण आवश्यक आहे, परंतु आपल्याला विनंत्यांचे प्रसारण नियंत्रित करण्यास देखील अनुमती देते. क्लायंटवर उघडलेल्या व्यवहाराच्या बाहेर, रिपॉझिटरीजना विनंत्या पाठवल्या जातात. जर क्लायंटने व्यवहार उघडला असेल, तर व्यवहारातील सर्व विनंत्या व्यवहार समन्वयकाकडे पाठवल्या जातात.

C*एक व्यवहार समन्वयक

समन्वयक ही अशी गोष्ट आहे जी आम्ही C*One साठी सुरवातीपासून लागू केली आहे. हे व्यवहार व्यवस्थापित करण्यासाठी जबाबदार आहे, लॉक आणि व्यवहार ज्या क्रमाने लागू केले जातात.

प्रत्येक सर्व्हिस केलेल्या व्यवहारासाठी, समन्वयक टाइमस्टॅम्प व्युत्पन्न करतो: प्रत्येक त्यानंतरचा व्यवहार मागील व्यवहारापेक्षा मोठा असतो. कॅसॅंड्राची संघर्ष निराकरण प्रणाली टाइमस्टॅम्पवर आधारित असल्यामुळे (दोन परस्परविरोधी नोंदी, नवीनतम टाइमस्टॅम्प असलेली एक वर्तमान मानली जाते), संघर्ष नेहमीच नंतरच्या व्यवहाराच्या बाजूने सोडवला जाईल. अशा प्रकारे आम्ही अंमलबजावणी केली लॅम्पपोर्ट घड्याळ - वितरित प्रणालीमधील संघर्ष सोडवण्याचा एक स्वस्त मार्ग.

कुलूप

अलगाव सुनिश्चित करण्यासाठी, आम्ही सर्वात सोपी पद्धत वापरण्याचा निर्णय घेतला - रेकॉर्डच्या प्राथमिक कीवर आधारित निराशावादी लॉक. दुसऱ्या शब्दांत, व्यवहारात, रेकॉर्ड प्रथम लॉक करणे आवश्यक आहे, त्यानंतरच ते वाचणे, सुधारित करणे आणि जतन करणे आवश्यक आहे. यशस्वी कमिट केल्यानंतरच रेकॉर्ड अनलॉक केला जाऊ शकतो जेणेकरून प्रतिस्पर्धी व्यवहार त्याचा वापर करू शकतील.

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

आमच्या बाबतीत डेटा आधीच एसक्यूएलमधील स्थानिक व्यवहारांच्या गटांमध्ये वितरीत केलेला असल्याने, समन्वयकांना स्थानिक व्यवहार गट नियुक्त करण्याचा निर्णय घेण्यात आला: एक समन्वयक 0 ते 9 पर्यंत टोकनसह सर्व व्यवहार करतो, दुसरा - 10 ते 19 पर्यंत टोकनसह, आणि असेच. परिणामी, समन्वयक उदाहरणांपैकी प्रत्येक व्यवहार गटाचा मास्टर बनतो.

मग समन्वयकाच्या स्मृतीमध्ये बॅनल हॅशमॅपच्या स्वरूपात लॉक लागू केले जाऊ शकतात.

समन्वयक अपयशी

एक समन्वयक केवळ व्यवहारांच्या गटाला सेवा देत असल्याने, त्याच्या अपयशाची वस्तुस्थिती त्वरीत निश्चित करणे फार महत्वाचे आहे जेणेकरून व्यवहार अंमलात आणण्याचा दुसरा प्रयत्न कालबाह्य होईल. हे जलद आणि विश्वासार्ह बनवण्यासाठी, आम्ही पूर्णपणे कनेक्ट केलेला कोरम हायरबीट प्रोटोकॉल वापरला:

प्रत्येक डेटा सेंटरमध्ये किमान दोन समन्वयक नोड्स असतात. कालांतराने, प्रत्येक संयोजक इतर समन्वयकांना हृदयाचा ठोका संदेश पाठवतो आणि त्यांना त्याच्या कार्याबद्दल माहिती देतो, तसेच शेवटच्या वेळी क्लस्टरमधील कोणत्या समन्वयकांकडून त्याला कोणते हृदयाचे ठोके संदेश प्राप्त झाले होते.

इतरांकडून त्यांच्या हृदयाचा ठोका संदेशांचा भाग म्हणून समान माहिती प्राप्त करून, प्रत्येक समन्वयक स्वतः ठरवतो की कोणते क्लस्टर नोड्स कार्यरत आहेत आणि कोणते नाहीत, कोरम तत्त्वानुसार: जर नोड X ला क्लस्टरमधील बहुसंख्य नोड्सकडून सामान्य माहिती प्राप्त झाली असेल. नोड Y वरून संदेशांची पावती, नंतर , Y कार्य करते. आणि त्याउलट, बहुसंख्य नोड Y वरून संदेश गहाळ झाल्याचा अहवाल देताच, Y ने नकार दिला. हे उत्सुक आहे की जर कोरमने नोड X ला सूचित केले की त्याला यापुढे त्याच्याकडून संदेश प्राप्त होत नाहीत, तर नोड X स्वतःला अयशस्वी झाल्याचे समजेल.

हार्टबीट संदेश उच्च वारंवारता, प्रति सेकंद सुमारे 20 वेळा, 50 एमएस कालावधीसह पाठवले जातात. Java मध्ये, 50 ms च्या आत अर्जाच्या प्रतिसादाची हमी देणे कठीण आहे कारण कचरा गोळा करणाऱ्या विरामांच्या तुलनेने लांबीमुळे. G1 गार्बेज कलेक्टर वापरून आम्ही हा प्रतिसाद वेळ साध्य करू शकलो, जे आम्हाला GC विरामांच्या कालावधीसाठी लक्ष्य निर्दिष्ट करण्यास अनुमती देते. तथापि, काहीवेळा, अगदी क्वचितच, संग्राहक विराम 50 ms पेक्षा जास्त असतो, ज्यामुळे चुकीचे दोष शोधू शकतात. हे होण्यापासून रोखण्यासाठी, संयोजक रिमोट नोडच्या बिघाडाची तक्रार करत नाही जेव्हा त्यातील पहिला हृदयाचा ठोका संदेश अदृश्य होतो, फक्त जर अनेक सलग गायब झाले असतील. अशा प्रकारे आम्ही 200 मध्ये समन्वयक नोडचे अपयश शोधण्यात व्यवस्थापित केले. ms

परंतु कोणत्या नोडने कार्य करणे थांबवले आहे हे द्रुतपणे समजून घेणे पुरेसे नाही. याबाबत आपण काहीतरी केले पाहिजे.

आरक्षण

उत्कृष्ट योजनेमध्ये, मास्टर अयशस्वी झाल्यास, त्यापैकी एक वापरून नवीन निवडणूक सुरू करणे समाविष्ट आहे फॅशनेबल सार्वत्रिक अल्गोरिदम तथापि, अशा अल्गोरिदममध्ये वेळ अभिसरण आणि निवडणूक प्रक्रियेच्या लांबीसह सुप्रसिद्ध समस्या आहेत. आम्ही पूर्णपणे कनेक्ट केलेल्या नेटवर्कमध्ये समन्वयक बदलण्याची योजना वापरून असा अतिरिक्त विलंब टाळण्यात सक्षम होतो:

समजा आम्हाला गट 50 मध्ये व्यवहार चालवायचा आहे. मुख्य समन्वयक अपयशी झाल्यास गट 50 मध्ये कोणते नोड्स व्यवहार करतील ते बदलण्याची योजना आधीच ठरवू या. डेटा सेंटर अयशस्वी झाल्यास सिस्टम कार्यक्षमता राखणे हे आमचे ध्येय आहे. पहिला राखीव दुसर्‍या डेटा सेंटरचा नोड असेल आणि दुसरा राखीव तिसर्‍याकडील नोड असेल हे ठरवू. ही योजना एकदा निवडली जाते आणि क्लस्टरचे टोपोलॉजी बदलेपर्यंत बदलत नाही, म्हणजेच नवीन नोड्स त्यात प्रवेश करेपर्यंत (जे फार क्वचित घडते). जुना अयशस्वी झाल्यास नवीन सक्रिय मास्टर निवडण्याची प्रक्रिया नेहमी खालीलप्रमाणे असेल: पहिला राखीव सक्रिय मास्टर होईल, आणि जर त्याचे कार्य करणे थांबले असेल, तर दुसरा राखीव सक्रिय मास्टर होईल.

ही योजना सार्वत्रिक अल्गोरिदमपेक्षा अधिक विश्वासार्ह आहे, कारण नवीन मास्टर सक्रिय करण्यासाठी जुन्याचे अपयश निश्चित करणे पुरेसे आहे.

पण आता कोणता मास्टर काम करतोय हे ग्राहकांना कसे समजेल? 50 ms मध्ये हजारो ग्राहकांना माहिती पाठवणे अशक्य आहे. जेव्हा एखादा क्लायंट व्यवहार उघडण्यासाठी विनंती पाठवतो तेव्हा परिस्थिती शक्य असते, हे मास्टर यापुढे कार्य करत नाही हे अद्याप माहित नसते आणि विनंतीची वेळ संपेल. हे होण्यापासून रोखण्यासाठी, क्लायंट सट्टेबाजीने ग्रुप मास्टर आणि त्याच्या दोन्ही रिझर्व्हजला एकाच वेळी व्यवहार उघडण्याची विनंती पाठवतात, परंतु या क्षणी जो सक्रिय मास्टर आहे तोच या विनंतीला प्रतिसाद देईल. क्लायंट व्यवहारात पुढील सर्व संप्रेषण केवळ सक्रिय मास्टरसह करेल.

न जन्मलेल्या व्यवहारांच्या रांगेत त्यांच्या नसलेल्या व्यवहारांसाठी बॅकअप मास्टर्स प्लेसला विनंत्या मिळाल्या, जिथे ते काही काळ साठवले जातात. सक्रिय मास्टरचा मृत्यू झाल्यास, नवीन मास्टर त्याच्या रांगेतून व्यवहार उघडण्याच्या विनंतीवर प्रक्रिया करतो आणि क्लायंटला प्रतिसाद देतो. जर क्लायंटने आधीच जुन्या मास्टरसह व्यवहार उघडला असेल, तर दुसऱ्या प्रतिसादाकडे दुर्लक्ष केले जाईल (आणि, स्पष्टपणे, असा व्यवहार पूर्ण होणार नाही आणि क्लायंटद्वारे त्याची पुनरावृत्ती होईल).

व्यवहार कसा चालतो

समजा एका क्लायंटने अशा आणि अशा घटकासाठी अशा आणि अशा प्राथमिक कीसह व्यवहार उघडण्याची विनंती समन्वयकाला पाठवली आहे. समन्वयक या घटकाला लॉक करतो आणि मेमरीमध्ये लॉक टेबलमध्ये ठेवतो. आवश्यक असल्यास, समन्वयक ही संस्था स्टोरेजमधून वाचतो आणि परिणामी डेटा समन्वयकाच्या मेमरीमध्ये व्यवहार स्थितीत संग्रहित करतो.

जेव्हा एखाद्या क्लायंटला व्यवहारात डेटा बदलायचा असतो, तेव्हा तो संयोजकाला संस्था सुधारण्यासाठी विनंती पाठवतो आणि समन्वयक नवीन डेटा मेमरीमध्ये व्यवहार स्थिती टेबलमध्ये ठेवतो. हे रेकॉर्डिंग पूर्ण करते - स्टोरेजमध्ये कोणतेही रेकॉर्डिंग केले जात नाही.

जेव्हा एखादा क्लायंट सक्रिय व्यवहाराचा भाग म्हणून स्वतःच्या बदललेल्या डेटाची विनंती करतो, तेव्हा समन्वयक खालीलप्रमाणे कार्य करतो:

• जर आयडी आधीच व्यवहारात असेल तर डेटा मेमरीमधून घेतला जातो;
• मेमरीमध्ये आयडी नसल्यास, गहाळ डेटा स्टोरेज नोड्समधून वाचला जातो, आधीपासून मेमरीमध्ये असलेल्यांसह एकत्रित केला जातो आणि त्याचा परिणाम क्लायंटला दिला जातो.

अशा प्रकारे, क्लायंट स्वतःचे बदल वाचू शकतो, परंतु इतर क्लायंट हे बदल पाहत नाहीत, कारण ते फक्त समन्वयकाच्या मेमरीमध्ये संग्रहित केले जातात; ते अद्याप कॅसॅंड्रा नोड्समध्ये नाहीत.

जेव्हा क्लायंट कमिट पाठवतो, तेव्हा सेवेच्या मेमरीमध्ये असलेली स्थिती समन्वयकाद्वारे लॉग केलेल्या बॅचमध्ये सेव्ह केली जाते आणि कॅसॅंड्रा स्टोरेजमध्ये लॉग केलेली बॅच म्हणून पाठवली जाते. हे पॅकेज आण्विक (पूर्णपणे) लागू केले आहे याची खात्री करण्यासाठी स्टोअर आवश्यक ते सर्व करतात आणि समन्वयकाला प्रतिसाद देतात, जो लॉक रिलीझ करतो आणि क्लायंटला व्यवहाराच्या यशाची पुष्टी करतो.

आणि रोलबॅक करण्यासाठी, समन्वयकाला फक्त व्यवहार स्थितीद्वारे व्यापलेली मेमरी मुक्त करणे आवश्यक आहे.

वरील सुधारणांचा परिणाम म्हणून, आम्ही 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 प्रमाणेच सोपे आहे. आणि सर्वात महत्त्वाचे म्हणजे, मूळ व्यवहार सारणीतील बदलांच्या अंमलबजावणीच्या गतीवर अनुक्रमणिका परिणाम करत नाहीत.

काय झालं

आम्ही तीन वर्षांपूर्वी सी*वन विकसित केले आणि ते व्यावसायिक ऑपरेशनमध्ये लाँच केले.

शेवटी आम्हाला काय मिळाले? सोशल नेटवर्कमधील डेटाच्या सर्वात महत्वाच्या प्रकारांपैकी एक असलेल्या फोटो प्रोसेसिंग आणि स्टोरेज उपप्रणालीचे उदाहरण वापरून याचे मूल्यांकन करूया. आम्ही स्वतः छायाचित्रांच्या मृतदेहांबद्दल बोलत नाही, परंतु सर्व प्रकारच्या मेटा-माहितीबद्दल बोलत आहोत. आता ओड्नोक्लास्निकीकडे सुमारे 20 अब्ज रेकॉर्ड आहेत, सिस्टम प्रति सेकंद 80 हजार वाचन विनंत्या प्रक्रिया करते, डेटा बदलाशी संबंधित प्रति सेकंद 8 हजार एसीआयडी व्यवहार.

जेव्हा आम्ही प्रतिकृती घटक = 1 सह SQL वापरला (परंतु RAID 10 मध्ये), तेव्हा मायक्रोसॉफ्ट एसक्यूएल सर्व्हर (अधिक 32 बॅकअप) चालवणाऱ्या 11 मशीनच्या अत्यंत उपलब्ध क्लस्टरवर फोटो मेटेनफॉर्मेशन संग्रहित केले गेले. बॅकअप संग्रहित करण्यासाठी 10 सर्व्हरचेही वाटप करण्यात आले. एकूण 50 महागड्या कार. त्याच वेळी, सिस्टम रिझर्व्हशिवाय, रेटेड लोडवर चालते.

नवीन प्रणालीमध्ये स्थलांतर केल्यानंतर, आम्हाला प्रतिकृती घटक = 3 - प्रत्येक डेटा सेंटरमध्ये एक प्रत प्राप्त झाली. एकूण 63 सर्व्हरसाठी या प्रणालीमध्ये 6 कॅसॅन्ड्रा स्टोरेज नोड्स आणि 69 समन्वयक मशीन आहेत. परंतु ही मशीन खूपच स्वस्त आहेत, त्यांची एकूण किंमत एसक्यूएल सिस्टमच्या किंमतीच्या सुमारे 30% आहे. त्याच वेळी, भार 30% वर ठेवला जातो.

C*One च्या परिचयाने, विलंबता देखील कमी झाली: SQL मध्ये, लेखन ऑपरेशनला सुमारे 4,5 ms लागले. सी*वन मध्ये - सुमारे 1,6 ms. व्यवहार कालावधी सरासरी 40 ms पेक्षा कमी आहे, वचनबद्धता 2 ms मध्ये पूर्ण होते, वाचन आणि लेखन कालावधी सरासरी 2 ms आहे. 99 व्या पर्सेंटाइल - केवळ 3-3,1 एमएस, कालबाह्यतेची संख्या 100 पट कमी झाली आहे - हे सर्व सट्ट्याच्या व्यापक वापरामुळे.

आत्तापर्यंत, बहुतेक SQL सर्व्हर नोड्स बंद केले गेले आहेत; नवीन उत्पादने फक्त C*One वापरून विकसित केली जात आहेत. आम्ही आमच्या क्लाउडमध्ये काम करण्यासाठी C*On चे रुपांतर केले एक ढग, ज्यामुळे नवीन क्लस्टर्सच्या तैनातीला गती देणे, कॉन्फिगरेशन सुलभ करणे आणि स्वयंचलित ऑपरेशन करणे शक्य झाले. स्त्रोत कोडशिवाय, हे करणे अधिक कठीण आणि अवजड असेल.

आता आम्ही आमच्या इतर स्टोरेज सुविधा क्लाउडमध्ये हस्तांतरित करण्यावर काम करत आहोत - परंतु ती पूर्णपणे वेगळी कथा आहे.

स्त्रोत: www.habr.com