संस्करण-आधारित पुनर्वित्त: क्या यह उत्पादन में संभव है?

नमस्ते! मेरा नाम एंटोनिना है, मैं स्पोर्टमास्टर लैब आईटी डिवीजन का एक ओरेकल डेवलपर हूं। मैं यहां केवल दो साल से काम कर रहा हूं, लेकिन एक दोस्ताना टीम, एक करीबी-बुनना टीम, एक सलाह प्रणाली, कॉर्पोरेट प्रशिक्षण के लिए धन्यवाद, महत्वपूर्ण द्रव्यमान जमा हुआ है जब मैं न केवल ज्ञान का उपभोग करना चाहता हूं, बल्कि अपना अनुभव भी साझा करना चाहता हूं।



तो, संस्करण-आधारित पुनर्वितरण। हमें इस तकनीक का अध्ययन करने की इतनी अधिक आवश्यकता क्यों है, इसके अलावा, "उच्च उपलब्धता" शब्द और संस्करण-आधारित पुनर्वितरण हमें Oracle डेवलपर्स के रूप में समय बचाने में कैसे मदद करता है?

ओरेकल द्वारा समाधान के रूप में क्या प्रस्तावित है? इस तकनीक को लागू करते समय पिछवाड़े में क्या चल रहा है, हमें किन समस्याओं का सामना करना पड़ा ... सामान्य तौर पर, कई सवाल हैं। मैं उन्हें विषय पर दो पदों में जवाब देने की कोशिश करूंगा, और उनमें से पहला पहले से ही कट के तहत है।

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

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

यह स्पष्ट है कि मध्यम और छोटे व्यवसायों के लिए, और अमेज़ॅन जैसे विशाल के लिए नहीं, ये मात्रात्मक विशेषताएं काफी कम होंगी, लेकिन फिर भी, सापेक्ष रूप से, यह एक महत्वपूर्ण मूल्यांकन विशेषता है।



इसलिए, हमें अपने आवेदन की उच्च उपलब्धता सुनिश्चित करने की आवश्यकता है। ओरेकल डेवलपर्स के पास इस पहुंच के लिए कुछ संभावित खतरनाक स्थान हैं?

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

फिर से, इस अपडेट को दो और वर्गों में विभाजित किया जा सकता है।

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

तो एडिशन-बेस्ड रिडिफाइनमेंट का इससे क्या लेना-देना है? और यह तकनीक - यह उपयोगकर्ताओं के काम को प्रभावित किए बिना, मक्खी पर, ऑनलाइन आवेदन को अपडेट करने का तरीका है।



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



समाधान के रूप में क्या प्रस्तावित है? संस्करण 11.2 के साथ शुरू ओरेकल, संस्करण-आधारित पुनर्परिवर्तन तकनीक पेश की गई है और संस्करण, संस्करण योग्य वस्तुओं, संस्करण दृश्य, क्रॉस-संस्करण ट्रिगर जैसी अवधारणाओं को पेश किया गया है। हमने खुद को "संस्करण" के रूप में इस तरह के अनुवाद की अनुमति दी। सामान्य तौर पर, कुछ खिंचाव वाली EBR तकनीक को DBMS के अंदर ही DBMS ऑब्जेक्ट्स का वर्जन कहा जा सकता है।

तो एक इकाई के रूप में संस्करण क्या है?

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



यह वही है जो तकनीक बाहर से दिखती है। यह कैसे काम करता है? शुरुआत के लिए - कोड स्तर पर। हमारे पास हमारा मूल एप्लिकेशन, संस्करण 1 होगा, जिसमें कुछ एल्गोरिदम हैं जो हमारे डेटा को संसाधित करते हैं। जब हम समझते हैं कि हमें एक नया संस्करण बनाते समय अपग्रेड करने की आवश्यकता है, तो निम्न होता है: कोड को संसाधित करने वाली सभी ऑब्जेक्ट्स को नए संस्करण में विरासत में मिला है ... उसी समय, इस नए बनाए गए सैंडबॉक्स में, हम मज़ेदार हो सकते हैं जैसा कि हम चाहते हैं, उपयोगकर्ता के लिए अदृश्य रूप से: हम बदल सकते हैं जो काम करते हैं कार्य, प्रक्रिया; पैकेज बदलें; हम किसी भी वस्तु का उपयोग करने से मना भी कर सकते हैं।

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



डेटा संरचनाओं का क्या होता है और इसके साथ संस्करण दृश्य का क्या करना है?



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



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



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

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



जब हमने महसूस किया कि पुराने एप्लिकेशन से उपयोगकर्ता सभी डिस्कनेक्ट हो गए हैं, तो यह संस्करण उपयोग से छिपाया जा सकता है। शायद यहां तक ​​कि डेटा संरचना को भी बदल दिया गया है। हमें याद है कि हमारे साथ नव निर्मित संस्करण में संस्करण दृश्य पहले से ही कॉलम 1, 3,4,5 के सेट पर दिखेगा। अच्छी तरह से और तदनुसार, अगर हमें इस संरचना की आवश्यकता नहीं है, तो इसे हटाया जा सकता है। यहाँ एक संक्षिप्त सारांश है कि यह कैसे काम करता है।



प्रतिबंध क्या हैं? यही है, अच्छी तरह से किया गया ओरेकल, उत्कृष्ट ओरेकल, उत्कृष्ट ओरेकल: वे एक अच्छी बात के साथ आए। इस समय पहली सीमा संस्करण प्रकार की वस्तुओं की है, ये पीएल / एसक्यूएल ऑब्जेक्ट्स हैं, अर्थात, प्रक्रियाएं, पैकेज, फ़ंक्शन, ट्रिगर और इसी तरह। समानार्थी हैं और विचार संस्करण हैं।

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



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

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

अगला। संस्करण दृश्य स्कीमा स्वामी, तालिका स्वामी और केवल प्रत्येक संस्करण में हैं। इसके मूल में, एक संस्करण दृश्य तालिका आवरण है, इसलिए यह स्पष्ट है कि यह अनुप्रयोग के प्रत्येक संस्करण में अद्वितीय होना चाहिए।

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

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



मुझे उम्मीद है कि अब आप समझ गए होंगे कि यह कैसे काम करता है। यदि आप तय करते हैं - "हाँ, हम इसे छूना चाहते हैं" - इस तकनीक का उपयोग करने के लिए स्विच करने के लिए क्या करने की आवश्यकता है?

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

इसके अलावा, स्वाभाविक रूप से, चयनित योजना को संस्करण विशेषाधिकार दिए गए हैं।
उसके बाद, हम तालिका का नाम बदलते हैं। ऐसा क्यों किया जाता है? बस हमारे PL / SQL कोड ऑब्जेक्ट्स को टेबल के संशोधन से बचाने के लिए।

हमने अपनी तालिका के अंत में एक तेज प्रतीक फेंकने का फैसला किया, जिसे 30-वर्ण की सीमा दी गई। उसके बाद, मूल तालिका नाम के साथ संस्करण दृश्य बनाए जाते हैं। और पहले से ही उन्हें कोड के अंदर उपयोग किया जाएगा। यह महत्वपूर्ण है कि हम जिस पहले संस्करण में जा रहे हैं, वह संस्करण दृश्य स्रोत तालिका में स्तंभों का एक पूरा सेट है, क्योंकि PL / SQL कोड ऑब्जेक्ट इन सभी स्तंभों को समान रूप से एक्सेस कर सकते हैं।

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

मैं और-और-और ... स्वाभाविक रूप से, परीक्षण, परीक्षण, और यथासंभव अधिक परीक्षण। परीक्षण क्यों? यह इतना सरल नहीं हो सकता है। हम किस बारे में ठोकर खाते थे?

यह मेरी दूसरी पोस्ट के बारे में है।