उद्यम को लागी DBMS वितरित

CAP प्रमेय वितरित प्रणाली सिद्धान्त को आधारशिला हो। निस्सन्देह, यसको वरपरको विवाद कम हुँदैन: यसमा परिभाषाहरू प्रामाणिक छैनन्, र त्यहाँ कुनै कडा प्रमाण छैन ... यद्यपि, दृढतापूर्वक दैनिक सामान्य ज्ञानको स्थितिमा उभिएर, हामी सहज रूपमा बुझ्छौं कि प्रमेय सत्य हो।

स्पष्ट नभएको मात्र कुरा अक्षर "P" को अर्थ हो। जब क्लस्टर विभाजित हुन्छ, यसले कोरम नपुगेसम्म प्रतिक्रिया नदिने वा उपलब्ध डाटा फिर्ता दिने निर्णय गर्छ। यो छनोटको नतिजाको आधारमा, प्रणालीलाई CP वा AP को रूपमा वर्गीकृत गरिएको छ। क्यासान्ड्रा, उदाहरणका लागि, क्लस्टर सेटिङहरूमा पनि निर्भर गर्दैन, तर प्रत्येक विशिष्ट अनुरोधको प्यारामिटरहरूमा निर्भर गर्दै, कुनै पनि तरिकाले व्यवहार गर्न सक्छ। तर यदि प्रणाली "P" होइन र यो विभाजित हुन्छ, त्यसपछि के हुन्छ?

यस प्रश्नको जवाफ केहि हदसम्म अप्रत्याशित छ: CA क्लस्टर विभाजित हुन सक्दैन।
यो कस्तो प्रकारको क्लस्टर हो जुन विभाजित हुन सक्दैन?

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

ओरेकल आरएसी

वास्तविक अनुप्रयोग क्लस्टर विकल्प पहिलो पटक 2001 मा Oracle 9i को रिलीज संग देखा पर्यो। यस्तो क्लस्टरमा, धेरै सर्भर उदाहरणहरू समान डाटाबेससँग काम गर्छन्।
Oracle दुबै क्लस्टर गरिएको फाइल प्रणाली र यसको आफ्नै समाधान - ASM, स्वचालित भण्डारण व्यवस्थापनसँग काम गर्न सक्छ।

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

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

तर के हुन्छ यदि कुनै एक उदाहरणले डाटा परिवर्तन गर्न आवश्यक छ?

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

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

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

Oracle RAC को सही प्रयोग भनेको डेटालाई भौतिक रूपमा विभाजन गर्नु हो (उदाहरणका लागि, विभाजन गरिएको तालिका मेकानिजम प्रयोग गरेर) र समर्पित नोड मार्फत विभाजनहरूको प्रत्येक सेट पहुँच गर्न। RAC को मुख्य उद्देश्य तेर्सो मापन थिएन, तर दोष सहिष्णुता सुनिश्चित गर्नु थियो।

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

• हराएको नोडको क्यासमा भएका सबै पृष्ठहरूलाई "फ्रिज गर्दछ";
• हराएको नोडको लगहरू (रिडू) पढ्छ र यी लगहरूमा रेकर्ड गरिएका परिवर्तनहरू पुन: लागू गर्छ, अन्य नोडहरूमा पृष्ठहरूको हालैका संस्करणहरू परिवर्तन भइरहेका छन् कि छैनन् भनेर जाँच गर्दै;
• पेन्डिङ लेनदेनहरू फिर्ता गर्छ।

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

लेनदेनको लागि IBM शुद्ध डाटा प्रणाली

DBMS को लागि क्लस्टर समाधान 2009 मा Blue Giant पोर्टफोलियोमा देखा पर्‍यो। वैचारिक रूपमा, यो "नियमित" उपकरणहरूमा निर्मित समानान्तर सिस्प्लेक्स क्लस्टरको उत्तराधिकारी हो। 2009 मा, DB2 pureScale, एक सफ्टवेयर सुइट, जारी गरियो, र 2012 मा, IBM ले लेनदेनको लागि Pure Data Systems भनिने एउटा उपकरण प्रस्ताव गर्‍यो। यसलाई एनालिटिक्सका लागि शुद्ध डेटा प्रणालीहरूसँग भ्रमित हुनु हुँदैन, जुन पुन: नामाकरण गरिएको Netezza बाहेक अरू केही होइन।

पहिलो नजरमा, PureScale आर्किटेक्चर Oracle RAC जस्तै छ: त्यसै गरी, धेरै नोडहरू साझा डेटा भण्डारण प्रणालीमा जोडिएका छन्, र प्रत्येक नोडले आफ्नै मेमोरी क्षेत्रहरू र लेनदेन लगहरूसँग आफ्नै DBMS उदाहरण चलाउँछ। तर, Oracle को विपरीत, DB2 सँग db2LLM* प्रक्रियाहरूको सेटद्वारा प्रतिनिधित्व गरिएको समर्पित लकिङ सेवा छ। क्लस्टर कन्फिगरेसनमा, यो सेवालाई छुट्टै नोडमा राखिएको छ, जसलाई समानान्तर सिस्प्लेक्समा कपलिङ सुविधा (CF) र शुद्ध डाटामा PowerHA भनिन्छ।

PowerHA ले निम्न सेवाहरू प्रदान गर्दछ:

• लक प्रबन्धक;
• विश्वव्यापी बफर क्यास;
• अन्तरप्रक्रिया संचार क्षेत्र।

PowerHA बाट डाटाबेस नोडहरू र पछाडि डेटा स्थानान्तरण गर्न, रिमोट मेमोरी पहुँच प्रयोग गरिन्छ, त्यसैले क्लस्टर इन्टरकनेक्टले RDMA प्रोटोकललाई समर्थन गर्नुपर्छ। PureScale ले Ethernet मा Infiniband र RDMA दुबै प्रयोग गर्न सक्छ।

यदि नोडलाई पृष्ठ चाहिन्छ, र यो पृष्ठ क्यासमा छैन भने, नोडले पृष्ठलाई विश्वव्यापी क्यासमा अनुरोध गर्दछ, र यदि यो त्यहाँ छैन भने, यसलाई डिस्कबाट पढ्छ। Oracle को विपरीत, अनुरोध केवल PowerHA मा जान्छ, र छिमेकी नोडहरूमा होइन।

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

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

"फोहोर", अर्थात्, परिवर्तन गरिएको, पृष्ठहरू नियमित नोड र PowerHA (castout) बाट डिस्कमा लेख्न सकिन्छ।

यदि PureScale नोडहरू मध्ये एउटा असफल भयो भने, रिकभरी केवल ती लेनदेनहरूमा मात्र सीमित हुन्छ जुन असफलताको समयमा पूरा भएको थिएन: पूरा कारोबारहरूमा त्यो नोडद्वारा परिमार्जन गरिएका पृष्ठहरू PowerHA मा विश्वव्यापी क्यासमा हुन्छन्। नोड क्लस्टरको सर्भरहरू मध्ये एकमा कम कन्फिगरेसनमा पुन: सुरु हुन्छ, पेन्डिङ लेनदेनहरू रोल ब्याक गर्छ र लकहरू रिलीज गर्दछ।

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

90% पढ्ने र 10% लेख्ने वर्कलोडमा IBM को आन्तरिक परीक्षणहरू, जुन वास्तविक-विश्व उत्पादन वर्कलोडहरूसँग धेरै मिल्दोजुल्दो छ, लगभग 128 नोडहरू सम्म रैखिक स्केलिंग देखाउँदछ। परीक्षण सर्तहरू, दुर्भाग्यवश, खुलासा गरिएको छैन।

HPE ननस्टप SQL

Hewlett-Packard Enterprise पोर्टफोलियोको आफ्नै उच्च उपलब्ध प्लेटफर्म पनि छ। यो ननस्टप प्लेटफर्म हो, सन् १९७६ मा Tandem Computers द्वारा बजारमा जारी गरिएको थियो। 1976 मा, कम्पनी कम्प्याक द्वारा अधिग्रहण गरिएको थियो, जुन 1997 मा हेवलेट-प्याकार्ड संग मर्ज भयो।

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

प्रणालीको प्रारम्भिक संस्करणहरूले स्वामित्व प्रोसेसरहरू प्रयोग गर्थे जुन एकअर्कासँग सिंक्रोनाइज गरिएको थियो: सबै अपरेशनहरू धेरै प्रोसेसरहरूद्वारा सिंक्रोनस रूपमा प्रदर्शन गरिएको थियो, र एक प्रोसेसरले त्रुटि गरेपछि, यो बन्द भयो, र दोस्रोले काम गर्न जारी राख्यो। पछि, प्रणालीले परम्परागत प्रोसेसरहरूमा स्विच गर्यो (पहिलो MIPS, त्यसपछि Itanium र अन्तमा x86), र अन्य संयन्त्रहरू सिङ्क्रोनाइजेसनको लागि प्रयोग गर्न थाले:

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

1987 देखि, एक रिलेशनल DBMS ननस्टप प्लेटफर्ममा चलिरहेको छ - पहिलो SQL/MP, र पछि SQL/MX।

सम्पूर्ण डाटाबेस भागहरूमा विभाजित छ, र प्रत्येक भाग आफ्नै डाटा पहुँच प्रबन्धक (DAM) प्रक्रियाको लागि जिम्मेवार छ। यसले डाटा रेकर्डिङ, क्यासिङ, र लकिङ मेकानिजमहरू प्रदान गर्दछ। डाटा प्रशोधन एक्जिक्युटर सर्भर प्रक्रियाहरू द्वारा सम्बद्ध डाटा प्रबन्धकहरू जस्तै समान नोडहरूमा चलिरहेको छ। SQL/MX अनुसूचकले कार्यकारीहरू बीच कार्यहरू विभाजन गर्दछ र परिणामहरू एकत्रित गर्दछ। जब सहमत परिवर्तनहरू गर्न आवश्यक छ, TMF (लेनदेन व्यवस्थापन सुविधा) पुस्तकालय द्वारा प्रदान गरिएको दुई-चरण कमिट प्रोटोकल प्रयोग गरिन्छ।

NonStop 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 बाट समाधानहरू उपलब्ध छन्। केही Lenovo कन्फिगरेसनहरूले SAN बिना पनि सञ्चालन गर्न अनुमति दिन्छ - एक साझा भण्डारण प्रणालीको भूमिका स्थानीय डिस्कहरूमा GPFS क्लस्टरद्वारा खेलिन्छ।

माथि सूचीबद्ध प्लेटफर्महरूको विपरीत, HANA एक इन-मेमोरी DBMS हो, अर्थात् प्राथमिक डेटा छवि RAM मा भण्डार गरिएको छ, र केवल लगहरू र आवधिक स्न्यापसटहरू प्रकोपको अवस्थामा रिकभरीको लागि डिस्कमा लेखिन्छन्।

प्रत्येक HANA क्लस्टर नोड डाटाको आफ्नै भागको लागि जिम्मेवार छ, र डाटा नक्सा एक विशेष घटक - नाम सर्भर, समन्वयक नोड मा स्थित भण्डारण गरिएको छ। नोडहरू बीच डाटा नक्कल गरिएको छैन। प्रत्येक नोडमा लकिङ जानकारी पनि भण्डारण गरिएको छ, तर प्रणालीमा ग्लोबल डेडलक डिटेक्टर छ।

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

संयोजक नोड दोहोरिएको छ, त्यसैले यदि संयोजक असफल भयो भने, ब्याकअप नोड तुरुन्तै लिन्छ। तर यदि डेटाको साथ नोड असफल भयो भने, त्यसपछि यसको डेटा पहुँच गर्ने एकमात्र तरिका नोड पुन: सुरु गर्नु हो। नियमको रूपमा, HANA क्लस्टरहरूले यसमा हराएको नोडलाई सकेसम्म चाँडो पुन: सुरु गर्नको लागि स्पेयर सर्भर राख्छन्।

स्रोत: www.habr.com