बिग डेटा: बैकअप इसके बिना काम नहीं करता है

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

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

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

वृद्धिशील

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

प्रतिकृति

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

डबल ईटीएल

एक नियम के रूप में, डेटा वेयरहाउस में प्रवेश करने से पहले, डेटा ईटीएल या ईएलटी प्रक्रियाओं से गुजरता है। संक्षिप्त नाम ETL खुद हमें बताता है कि डेटा तदनुसार परिवर्तित किया जाता है, और डेटा वेयरहाउस में जाने से पहले अतिरिक्त डेटा काट दिया जाता है। इस प्रक्रिया को समानांतर किया जा सकता है - अर्थात डेटा लोडिंग एक डेटा वेयरहाउस में नहीं, बल्कि दो या अधिक में करें। इस प्रकार, हमारे पास आवश्यकतानुसार डेटा वेयरहाउस की कई प्रतियाँ होंगी। लेकिन, इसके बावजूद, इस दृष्टिकोण में एक महत्वपूर्ण कमी है - अक्सर प्रतियां समान नहीं होती हैं, क्योंकि डेटा लोडिंग के दौरान त्रुटियां और विसंगतियां होती हैं। यह हमेशा स्पष्ट नहीं होता है कि कौन सी प्रतियाँ अधिक सही हैं। शायद कुछ व्यवसाय इस तरह की विसंगति की अनुमति दे सकते हैं, लेकिन अगर हम वित्तीय कंपनियों के बारे में बात कर रहे हैं, तो इस धारणा को अस्तित्व का अधिकार नहीं है। आप त्रुटियों के सत्यापन और सुधार के लिए एक जटिल प्रक्रिया विकसित कर सकते हैं, लेकिन, एक नियम के रूप में, यह केवल पूरी प्रक्रिया को जटिल और धीमा कर देता है। इस दृष्टिकोण को संक्षेप में, हम कह सकते हैं कि यह सीमित संख्या में मामलों में लागू है।

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