एंटरप्राइझसाठी वितरित DBMS

CAP प्रमेय वितरित प्रणाली सिद्धांताचा आधारशिला आहे. अर्थात, त्याच्या सभोवतालचा विवाद कमी होत नाही: त्यातील व्याख्या प्रामाणिक नाहीत आणि कोणताही कठोर पुरावा नाही... तरीही, दैनंदिन सामान्य ज्ञानाच्या स्थितीवर ठामपणे उभे राहून, प्रमेय सत्य आहे हे आपण अंतर्ज्ञानाने समजतो.

फक्त एक गोष्ट जी स्पष्ट नाही ती म्हणजे "पी" अक्षराचा अर्थ. जेव्हा क्लस्टर विभाजित केले जाते, तेव्हा कोरम पूर्ण होईपर्यंत प्रतिसाद द्यायचा नाही किंवा उपलब्ध डेटा परत द्यायचा हे ठरवते. या निवडीच्या परिणामांवर अवलंबून, प्रणालीचे वर्गीकरण CP किंवा AP असे केले जाते. कॅसॅन्ड्रा, उदाहरणार्थ, क्लस्टर सेटिंग्जवर अवलंबून नसून प्रत्येक विशिष्ट विनंतीच्या पॅरामीटर्सवर अवलंबून, कोणत्याही प्रकारे वागू शकते. पण जर सिस्टीम "पी" नसेल आणि ती फुटली तर काय?

या प्रश्नाचे उत्तर काहीसे अनपेक्षित आहे: CA क्लस्टर विभाजित होऊ शकत नाही.
हे कोणत्या प्रकारचे क्लस्टर आहे जे विभाजित होऊ शकत नाही?

अशा क्लस्टरचा एक अपरिहार्य गुणधर्म म्हणजे सामायिक डेटा स्टोरेज सिस्टम. बहुसंख्य प्रकरणांमध्ये, याचा अर्थ SAN वर जोडणे, जे SAN पायाभूत सुविधा राखण्यास सक्षम असलेल्या मोठ्या उद्योगांसाठी CA सोल्यूशन्सचा वापर मर्यादित करते. एकाच डेटासह एकाधिक सर्व्हर कार्य करण्यासाठी, क्लस्टर केलेली फाइल सिस्टम आवश्यक आहे. अशा फाइल सिस्टम HPE (CFS), Veritas (VxCFS) आणि IBM (GPFS) पोर्टफोलिओमध्ये उपलब्ध आहेत.

ओरॅकल आरएसी

रिअल ऍप्लिकेशन क्लस्टर पर्याय प्रथम 2001 मध्ये ओरॅकल 9i च्या रिलीझसह दिसला. अशा क्लस्टरमध्ये, एकाच डेटाबेससह अनेक सर्व्हर उदाहरणे कार्य करतात.
ओरॅकल क्लस्टर्ड फाइल सिस्टम आणि स्वतःचे सोल्यूशन - ASM, ऑटोमॅटिक स्टोरेज मॅनेजमेंट या दोन्हीसह कार्य करू शकते.

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

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

परंतु एखाद्या प्रसंगाला डेटा बदलण्याची आवश्यकता असल्यास काय होईल?

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

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

वेगवेगळ्या RAC नोड्सवर समान पृष्ठे यादृच्छिकपणे अद्यतनित केल्याने डेटाबेस कार्यप्रदर्शन नाटकीयरित्या कमी होते, क्लस्टर कार्यप्रदर्शन एका उदाहरणापेक्षा कमी असू शकते.

Oracle RAC चा योग्य वापर म्हणजे डेटाचे भौतिकरित्या विभाजन करणे (उदाहरणार्थ, विभाजित टेबल यंत्रणा वापरणे) आणि समर्पित नोडद्वारे विभाजनांच्या प्रत्येक संचामध्ये प्रवेश करणे. RAC चा मुख्य उद्देश क्षैतिज स्केलिंग नव्हता, परंतु दोष सहिष्णुता सुनिश्चित करणे हा होता.

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

• गहाळ नोडच्या कॅशेमध्ये असलेली सर्व पृष्ठे “गोठवते”;
• गहाळ नोडचे लॉग (पुन्हा करा) वाचते आणि या नोंदींमध्ये रेकॉर्ड केलेले बदल पुन्हा लागू करते, त्याच वेळी इतर नोड्समध्ये बदललेल्या पृष्ठांच्या अलीकडील आवृत्त्या आहेत का ते तपासते;
• प्रलंबित व्यवहार मागे घेतो.

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

व्यवहारांसाठी IBM शुद्ध डेटा प्रणाली

2009 मध्ये ब्लू जायंट पोर्टफोलिओमध्ये DBMS साठी क्लस्टर सोल्यूशन दिसले. वैचारिकदृष्ट्या, हे पॅरलल सिस्प्लेक्स क्लस्टरचे उत्तराधिकारी आहे, जे "नियमित" उपकरणांवर तयार केले आहे. 2009 मध्ये, DB2 pureScale हे सॉफ्टवेअर संच म्हणून प्रसिद्ध झाले आणि 2012 मध्ये, IBM ने व्यवहारांसाठी Pure Data Systems नावाचे उपकरण देऊ केले. एनालिटिक्ससाठी प्युअर डेटा सिस्टीममध्ये गोंधळून जाऊ नये, जे नेटेझा पुनर्नामित करण्यापेक्षा अधिक काही नाही.

पहिल्या दृष्टीक्षेपात, PureScale आर्किटेक्चर Oracle RAC सारखेच आहे: त्याच प्रकारे, अनेक नोड्स एका सामान्य डेटा स्टोरेज सिस्टमशी जोडलेले आहेत आणि प्रत्येक नोड त्याच्या स्वतःच्या मेमरी क्षेत्रे आणि व्यवहार लॉगसह स्वतःचे DBMS उदाहरण चालवते. परंतु, ओरॅकलच्या विपरीत, DB2 मध्ये db2LLM* प्रक्रियांच्या संचाद्वारे प्रस्तुत केलेली समर्पित लॉकिंग सेवा आहे. क्लस्टर कॉन्फिगरेशनमध्ये, ही सेवा वेगळ्या नोडवर ठेवली जाते, ज्याला पॅरलल सिस्प्लेक्समध्ये कपलिंग फॅसिलिटी (CF) आणि शुद्ध डेटामध्ये PowerHA म्हणतात.

PowerHA खालील सेवा प्रदान करते:

• लॉक व्यवस्थापक;
• जागतिक बफर कॅशे;
• इंटरप्रोसेस कम्युनिकेशन्सचे क्षेत्र.

PowerHA वरून डेटाबेस नोड्समध्ये डेटा हस्तांतरित करण्यासाठी आणि मागे, रिमोट मेमरी ऍक्सेस वापरला जातो, म्हणून क्लस्टर इंटरकनेक्टने RDMA प्रोटोकॉलला समर्थन दिले पाहिजे. PureScale इथरनेटवर Infiniband आणि RDMA दोन्ही वापरू शकते.

जर नोडला पृष्ठाची आवश्यकता असेल आणि हे पृष्ठ कॅशेमध्ये नसेल, तर नोड जागतिक कॅशेमध्ये पृष्ठाची विनंती करतो आणि जर ते तेथे नसेल तरच ते डिस्कवरून वाचते. ओरॅकलच्या विपरीत, विनंती फक्त PowerHA ला जाते, शेजारच्या नोड्सना नाही.

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

जर सुधारित पंक्ती असलेले पृष्ठ आधीच लॉक केलेले असेल, तर लॉक व्यवस्थापक बदल केलेल्या नोडच्या मेमरीमधून सुधारित पृष्ठ वाचेल, लॉक सोडेल, इतर नोड्सच्या कॅशेमध्ये सुधारित पृष्ठ अवैध करेल आणि विनंती केलेल्या नोडला पृष्ठ लॉक द्या.

"डर्टी", म्हणजेच बदललेली, पृष्ठे नियमित नोड आणि पॉवरएचए (कास्टआउट) वरून डिस्कवर लिहिली जाऊ शकतात.

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

पॉवरएचए दोन सर्व्हरवर चालते आणि मास्टर नोड त्याची स्थिती समकालिकपणे प्रतिरूपित करते. प्राथमिक पॉवरएचए नोड अयशस्वी झाल्यास, क्लस्टर बॅकअप नोडसह कार्य करणे सुरू ठेवते.
अर्थात, तुम्ही एकाच नोडद्वारे डेटा सेट ऍक्सेस केल्यास, क्लस्टरची एकूण कामगिरी जास्त असेल. PureScale अगदी लक्षात घेऊ शकते की डेटाच्या विशिष्ट क्षेत्रावर एका नोडद्वारे प्रक्रिया केली जात आहे, आणि नंतर त्या क्षेत्राशी संबंधित सर्व लॉक्स पॉवरएचएशी संप्रेषण न करता नोडद्वारे स्थानिक पातळीवर प्रक्रिया केली जातील. परंतु अनुप्रयोगाने दुसर्‍या नोडद्वारे या डेटामध्ये प्रवेश करण्याचा प्रयत्न केल्यावर, केंद्रीकृत लॉक प्रक्रिया पुन्हा सुरू होईल.

90% वाचन आणि 10% लेखनाच्या वर्कलोडवर IBM च्या अंतर्गत चाचण्या, जे रिअल-वर्ल्ड प्रोडक्शन वर्कलोड्ससारखेच आहे, 128 नोड्सपर्यंत जवळजवळ रेषीय स्केलिंग दर्शवते. चाचणी अटी, दुर्दैवाने, उघड नाहीत.

HPE नॉनस्टॉप SQL

Hewlett-Packard Enterprise पोर्टफोलिओचे स्वतःचे उच्च उपलब्ध व्यासपीठ देखील आहे. हे नॉनस्टॉप प्लॅटफॉर्म आहे, 1976 मध्ये Tandem Computers ने बाजारात आणले. 1997 मध्ये, कंपनी कॉम्पॅकने विकत घेतली, जी 2002 मध्ये हेवलेट-पॅकार्डमध्ये विलीन झाली.

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

सिस्टमच्या सुरुवातीच्या आवृत्त्यांमध्ये प्रोप्रायटरी प्रोसेसर वापरले होते जे एकमेकांशी सिंक्रोनाइझ केले गेले होते: सर्व ऑपरेशन्स अनेक प्रोसेसरद्वारे समकालिकपणे पार पाडल्या गेल्या होत्या आणि प्रोसेसरपैकी एकाने त्रुटी केल्यावर ते बंद केले गेले आणि दुसरे कार्य चालूच ठेवले. नंतर, प्रणाली पारंपारिक प्रोसेसरवर स्विच झाली (प्रथम MIPS, नंतर इटानियम आणि शेवटी x86), आणि इतर यंत्रणा सिंक्रोनाइझेशनसाठी वापरल्या जाऊ लागल्या:

• संदेश: प्रत्येक सिस्टम प्रक्रियेत "सावली" जुळी असते, ज्याला सक्रिय प्रक्रिया वेळोवेळी त्याच्या स्थितीबद्दल संदेश पाठवते; मुख्य प्रक्रिया अयशस्वी झाल्यास, शेवटच्या संदेशाद्वारे निर्धारित केलेल्या क्षणापासून सावली प्रक्रिया कार्य करण्यास प्रारंभ करते;
• मतदान: स्टोरेज सिस्टममध्ये एक विशेष हार्डवेअर घटक आहे जो एकाधिक समान प्रवेश स्वीकारतो आणि प्रवेश जुळत असल्यासच ते कार्यान्वित करतो; फिजिकल सिंक्रोनाइझेशनऐवजी, प्रोसेसर असिंक्रोनस पद्धतीने कार्य करतात आणि त्यांच्या कार्याच्या परिणामांची तुलना केवळ I/O क्षणांवर केली जाते.

1987 पासून, एक रिलेशनल DBMS नॉनस्टॉप प्लॅटफॉर्मवर चालू आहे - प्रथम SQL/MP, आणि नंतर SQL/MX.

संपूर्ण डेटाबेस भागांमध्ये विभागलेला आहे, आणि प्रत्येक भाग त्याच्या स्वतःच्या डेटा ऍक्सेस मॅनेजर (DAM) प्रक्रियेसाठी जबाबदार आहे. हे डेटा रेकॉर्डिंग, कॅशिंग आणि लॉकिंग यंत्रणा प्रदान करते. डेटा प्रोसेसिंग एक्झिक्युटर सर्व्हर प्रक्रियांद्वारे केले जाते जे संबंधित डेटा व्यवस्थापकांप्रमाणेच नोड्सवर चालतात. SQL/MX शेड्युलर कार्यान्वित करणार्‍यांमध्ये कार्ये विभाजित करतो आणि परिणाम एकत्रित करतो. जेव्हा मान्य बदल करणे आवश्यक असते, तेव्हा TMF (ट्रान्झॅक्शन मॅनेजमेंट फॅसिलिटी) लायब्ररीद्वारे प्रदान केलेला द्वि-चरण कमिट प्रोटोकॉल वापरला जातो.

नॉनस्टॉप SQL प्रक्रियांना प्राधान्य देऊ शकते जेणेकरून दीर्घ विश्लेषणात्मक क्वेरी व्यवहाराच्या अंमलबजावणीमध्ये व्यत्यय आणू शकत नाहीत. तथापि, त्याचा उद्देश तंतोतंत लहान व्यवहारांवर प्रक्रिया करणे आहे, विश्लेषण करणे नाही. डेव्हलपर नॉनस्टॉप क्लस्टरच्या उपलब्धतेची हमी देतो पाच "नऊ" च्या स्तरावर, म्हणजे, डाउनटाइम प्रति वर्ष फक्त 5 मिनिटे आहे.

सॅप हाना

HANA DBMS (1.0) चे पहिले स्थिर प्रकाशन नोव्हेंबर 2010 मध्ये झाले आणि SAP ERP पॅकेज मे 2013 मध्ये HANA वर स्विच झाले. प्लॅटफॉर्म खरेदी केलेल्या तंत्रज्ञानावर आधारित आहे: TREX शोध इंजिन (स्तंभ संग्रहणात शोधा), P*TIME DBMS आणि MAX DB.

"HANA" हा शब्द स्वतःच एक संक्षिप्त रूप आहे, उच्च कार्यक्षमता विश्लेषणात्मक उपकरण. हा DBMS कोडच्या स्वरूपात पुरवला जातो जो कोणत्याही x86 सर्व्हरवर चालू शकतो, तथापि, औद्योगिक प्रतिष्ठापनांना केवळ प्रमाणित उपकरणांवर परवानगी आहे. HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC कडून उपाय उपलब्ध आहेत. काही लेनोवो कॉन्फिगरेशन SAN शिवाय ऑपरेशनला परवानगी देतात - स्थानिक डिस्क्सवरील GPFS क्लस्टरद्वारे सामान्य स्टोरेज सिस्टमची भूमिका बजावली जाते.

वर सूचीबद्ध केलेल्या प्लॅटफॉर्मच्या विपरीत, HANA एक इन-मेमरी DBMS आहे, म्हणजे प्राथमिक डेटा प्रतिमा RAM मध्ये संग्रहित केली जाते आणि केवळ लॉग आणि नियतकालिक स्नॅपशॉट्स आपत्तीच्या बाबतीत पुनर्प्राप्तीसाठी डिस्कवर लिहिले जातात.

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

जेव्हा HANA क्लायंट क्लस्टरशी कनेक्ट होतो, तेव्हा ते त्याचे टोपोलॉजी डाउनलोड करते आणि त्यानंतर त्याला कोणत्या डेटाची आवश्यकता असते त्यानुसार कोणत्याही नोडमध्ये थेट प्रवेश करू शकतो. जर एखाद्या व्यवहाराचा एकाच नोडच्या डेटावर परिणाम होत असेल, तर तो त्या नोडद्वारे स्थानिक पातळीवर कार्यान्वित केला जाऊ शकतो, परंतु जर अनेक नोड्सचा डेटा बदलला तर, आरंभ करणारा नोड समन्वयक नोडशी संपर्क साधतो, जो वितरित व्यवहार उघडतो आणि समन्वयित करतो आणि तो वापरून तो करतो. ऑप्टिमाइझ केलेले दोन-फेज कमिट प्रोटोकॉल.

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

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