संस्करण परिवर्तन डेटाबेस से डेटाबेस परिवर्तन प्रबंधन के लिए

उन लोगों के लिए धन्यवाद जो डेटाबेस सिस्टम के साथ काम के आयोजन के कई महत्वपूर्ण मुद्दों पर अपने विचारों और अनुभवों, यहां तक ​​कि नकारात्मक लोगों को साझा करने में संकोच नहीं करते हैं। मुझे एक लेख " डेटाबेस संरचना का संस्करणबद्ध प्रवासन आया : यह ऐसा करने के लिए बेहतर क्यों नहीं है ", मैंने इस पर टिप्पणी करने के लिए सोचा, लेकिन, प्रकाशन की तारीख पर विचार करने के बाद, मैंने अपना खुद का लिखने का फैसला किया। यह काफी स्पष्ट है कि लेखक के पास शीर्षक में बनाए गए शब्दों के अर्थ और अर्थ का अपना विचार था। और गलत प्रस्तुति ने इस तथ्य को जन्म दिया कि गलत कार्य हल किया जा रहा था। Habré पर काफी लंबे समय तक संस्करण डेटाबेस माइग्रेशन के संगठन पर लेख दिखाई दिए। उन्हें कीवर्ड खोज द्वारा आसानी से पता चला है। यहाँ इस लेख में: DATABASE STRUCTURE का VERSIONAL MIGRATION: BASIC APPROACHES शब्दावली, कार्यों और उन्हें हल करने की बुनियादी तकनीकों का उत्कृष्ट परिचय दिया गया है।
मैं अपने स्वयं के उदाहरण के माध्यम से उन अप्रत्याशित समस्याओं के बारे में बताना चाहूंगा, जो एक निमंत्रण के बिना, अचानक मेरे पुराने कार्यों में से एक पर हमारे समूह के सामने आईं, और हमारे पास तब क्या कमी थी, इस स्थिति के त्वरित और प्रभावी समाधान के लिए - सामान्य तौर पर, एक नकारात्मक अनुभव भी। - अचानक कोई भविष्य में या भविष्य में काम आएगा। इस तथ्य के बावजूद कि हमारी कंपनी में हम इस तरह की समस्याओं के समाधान के लिए अधिक व्यापक रूप से संपर्क कर रहे हैं, उन्हें "डेटाबेस में परिवर्तन प्रबंधन" शब्द के तहत जोड़कर, मैं ऊपर दिए गए लेख से शब्दावली क्षेत्र में रहने की कोशिश करूंगा।

पिछले वर्षों के अनुभव - UNSOLVED प्रोफाइल के बारे में

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

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

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

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

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

कोई फर्क नहीं पड़ता कि यह कहानी कितनी सामान्य और संक्षिप्त है, डेटाबेस माइग्रेशन से संबंधित कुछ विशिष्ट विशेषताओं को इससे निकाला जा सकता है।

1. आवेदन के विभिन्न संस्करणों की एक बड़ी संख्या का एक साथ समर्थन एक उद्देश्य वास्तविकता है जो डेवलपर्स या उपयोगकर्ताओं की इच्छाओं पर निर्भर नहीं करता है
2. माइग्रेशन के लिए न केवल डेटाबेस को किसी अन्य सर्वर या DBMS प्लेटफ़ॉर्म पर स्थानांतरित करना आवश्यक है, बल्कि एप्लिकेशन सॉफ़्टवेयर के उपलब्ध संस्करण (संस्करण, पीढ़ी) के साथ डेटाबेस को सिंक्रनाइज़ करते समय भी आवश्यक है
3. संस्करणों के बीच का अंतर न केवल प्रसंस्करण तर्क और डेटाबेस संरचनाओं में अंतर के साथ जुड़ा हुआ है, बल्कि विभिन्न DBMS प्लेटफार्मों में, साथ ही मौजूदा हार्डवेयर के लिए विशेष सेटिंग्स में भी जुड़ा हुआ है।
4. इसके लिए केवल माइग्रेशन प्रक्रिया के प्रबंधन की आवश्यकता नहीं है, बल्कि उन तत्वों की संरचना पर योजनाओं, डेटा और सेटिंग्स, ऑडिट (रिपोर्टिंग) की अपरिहार्यता का नियंत्रण भी है, जिन्हें किसके द्वारा और किन मूल्यों से बदला गया है
5. प्रवासन के दौरान डेटाबेस संरचना में परिवर्तन अक्सर संग्रहीत डेटा के अतिरिक्त प्रसंस्करण / रूपांतरण के लिए होता है

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

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

ऐसा लगता है कि सभी सर्वरों को संशोधित करने और प्रत्येक सर्वर पर स्वचालित रूप से उन्हें निष्पादित करने के लिए एक समान स्क्रिप्ट रखना आसान है!

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

अनुप्रयोग के पुराने संस्करण के अस्तित्व के दौरान एक अलग सर्वर पर किए गए परिवर्तनों के लॉग का समर्थन करने से राहत नहीं मिली, क्योंकि यदि कई ऐसे परिवर्तन थे, तो सिंक्रनाइज़ेशन स्क्रिप्ट को "सही" अनुक्रम में कड़ाई से निष्पादित किया जाना चाहिए, और, कुछ मामलों में, एक स्क्रिप्ट का दोहराया निष्पादन है। पूरी तरह से अस्वीकार्य - परिणाम पहले से ही अपरिवर्तनीय होगा।

अब विभिन्न सर्वरों की संख्या से अपना समय गुणा करें!

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

यदि ऐसे उपकरण उपलब्ध थे जो स्वचालित रूप से डेटाबेस की संरचना के लिए एक स्रोत के रूप में दृष्टिकोण का समर्थन करते थे, तो विभिन्न प्रोग्रामिंग भाषाओं में सभी सामान्य स्रोत नियंत्रण प्रणालियों के समान, निम्नलिखित कार्य बहुत आसान होंगे:

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

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

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