OLTP से OLAP डेटाबेस में प्रतिकृति

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

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

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

रॉबर्ट ने सुझाव दिया, यह मुझे प्रतीत होता है, एक नया, यद्यपि स्वाभाविक, ऐसे मामलों के लिए डेटा प्रतिकृति की समस्या को हल करने के लिए दृष्टिकोण। बाइनरी लॉग को प्रत्येक तालिका के लिए DELETE / INSERT परिचालनों के आंशिक रूप से ऑर्डर किए गए सेट के अनुक्रम में परिवर्तित किया जाता है, इसके अलावा, "सेट" शब्द का अर्थ है कि "समान" ऑपरेशन एक अर्थ में एक बार किए जाने के लिए पर्याप्त हैं। मैं थोड़ा और समझाऊंगा।

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



बाइनरी लॉग में तीन ऑपरेशन एक मध्यवर्ती चरण में 4 संचालन में बदल दिए गए थे, और कमी के बाद केवल अंतिम दो बने रहे।

यह क्या देता है? यह ओएलएपी डेटाबेस बिंदु से डेटा को बदलने का सबसे कुशल तरीका देता है: सबसे पहले, पैकेज में हटाए गए या बदले गए सभी रिकॉर्ड हटा दिए जाते हैं, और नहीं, और फिर प्रत्येक तालिका के लिए एक टुकड़े में, नए और बदले हुए रिकॉर्ड जोड़े जाते हैं, जिसे बैच ऑपरेटरों के माध्यम से कुशलतापूर्वक किया जा सकता है डेटा लोड हो रहा है। यही है, एक सख्ती से आदेश दिया रैखिक अनुक्रम आंशिक रूप से आदेशित सेट (आंशिक रूप से आदेशित सेट के अनुक्रम में) में बदल जाता है। यह मौलिक अर्थ है।

जाहिर है, एक सीमा है। यदि बाइनरी लॉग में UPDATE या DELETE में तालिका की प्राथमिक कुंजी पर एक शर्त शामिल नहीं है, तो यह दृष्टिकोण काम नहीं करता है, और इस मामले में, आपको पारंपरिक तरीके से डेटा को दोहराना होगा।

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