बड़ा डेटा बैकअप

हमारे डेटा वेयरहाउस को डिज़ाइन और ऑपरेट करते समय, सवाल कई बार उठता है कि बैकअप या प्रतिकृति कैसे बनाई जाए। मैंने हमेशा उसे एक ही जवाब दिया - कोई रास्ता नहीं। मैं थोड़ा समझाऊंगा क्यों।

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

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

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

तो, क्लोनिंग संभव बनाता है:

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

और यह सब प्रदर्शन दंड के बिना, और न्यूनतम जोखिम के साथ। हालाँकि, ऐसी कठिनाइयाँ भी हैं जिनका उल्लेख किया जाना चाहिए:

• सिस्टम के बीच डेटा अखंडता की निगरानी करना
• खरोंच से एक नई प्रणाली शुरू करना

इन दोनों समस्याओं को 100% सटीकता के साथ हल करना काफी कठिन है, लेकिन हमें इसकी आवश्यकता नहीं थी। यह पर्याप्त है कि आर्थिक रूप से महत्वपूर्ण आँकड़े मेल खाते हैं, और विस्तृत डेटा थोड़ा भिन्न हो सकते हैं या अनुपस्थित भी हो सकते हैं। दोनों मामलों में, लाइव सिस्टम के साथ सार्थक डेटा की प्रतिलिपि बनाकर डेटा सिंक्रनाइज़ेशन किया जा सकता है। इस प्रकार, हमारे पास यह चुनने के लिए हमेशा पूर्ण नियंत्रण और स्थान था कि क्या हम एक सटीक प्रतिलिपि प्राप्त करना चाहते हैं, लेकिन कुछ दिनों में, या कम सटीक, लेकिन तेज़।

वर्णित दृष्टिकोण ने हमें कई बार मदद की है। इसके अलावा, उसने हमें विभिन्न डेटाबेस (विभिन्न विक्रेताओं) पर सिस्टम की अनुमति दी, लेकिन एक ही एल्गोरिदम पर काम कर रहा है। इस प्रकार एक डेटाबेस से दूसरे में प्रवास को सरल बनाना।

अद्यतन: टिप्पणी प्राप्त करने के बाद, कुछ स्पष्टीकरण की आवश्यकता थी।

संभवतः, यह शुरू करने और लिखने के लायक था कि हम किस तरह के डेटा की प्रक्रिया करते हैं। मुझे यकीन है कि प्रस्तावित दृष्टिकोण विभिन्न मामलों में काम करता है, लेकिन बारीकियों को चोट नहीं पहुंचेगी।

हम भंडारण में कई प्रकार के स्रोतों से डेटा को संसाधित और लोड करते हैं। यह है:

• रनटाइम सर्वर से आंकड़े दर्ज करने और विज्ञापन अभियान छापों के संदर्भ में लॉग
• ओन्टोलॉजी और विवरण लॉग को सही ढंग से व्याख्या करने की अनुमति देते हैं
• हमारे भागीदारों की साइटों से डेटा

यह सभी डेटा रिपॉजिटरी में अपलोड किया गया है, और हमारे ग्राहकों, भागीदारों, स्वयं के उपयोगकर्ताओं और विभिन्न एल्गोरिदम द्वारा उपयोग किया जाता है जो कि क्या, कहाँ और कैसे प्रदर्शित करें, इसके आधार पर निर्णय लेते हैं। डेटाबेस की विफलता का मतलब न केवल व्यवसाय को रोकना और पैसा खोना है, बल्कि यह भी है कि तब विफलता के दौरान जमा हुए डेटा को "पकड़ा" जाना होगा। और दक्षता बहुत महत्वपूर्ण है। इसलिए, बैकअप सिस्टम का प्रश्न निष्क्रिय नहीं है।

डेटा की मात्रा बड़ी है। कच्चे लॉग प्रति दिन कुछ टेराबाइट्स लेते हैं, हालांकि संसाधित रूप में बहुत कम। मुकाबला आधार लगातार बढ़ रहा है, और अब कई टेराबाइट लेता है।

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