डेटाबेस संरचना का संस्करण विस्थापित: ऐसा करना बेहतर क्यों नहीं है

प्रागितिहास

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

ध्यान देने योग्य लेख:

• डेटाबेस संरचना का संस्करण विस्थापित: सिद्धांत से अभ्यास करने के लिए
• डेटाबेस संरचनाओं का संस्करण प्रवासन: मुख्य दृष्टिकोण

लेखक पर भरोसा क्यों किया जा सकता है

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

सारांश

मैं उन सभी टिप्पणियों, मान्यताओं और निष्कर्षों को संक्षेप में प्रस्तुत करने की कोशिश करूंगा जो इस प्रकार हैं:

1. आधुनिक विकास की प्रक्रिया लघु पुनरावृत्तियों, लगातार निर्माण और निरंतर एकीकरण पर केंद्रित है
2. वृद्धिशील डेटाबेस संरचना परिवर्तन DBMS की स्पष्ट सीमाओं के कारण काफी महंगे हैं
3. विकास के शुरुआती चरणों में, डीबीएमएस सीमाएं हमेशा स्पष्ट / दिलचस्प नहीं होती हैं (नीचे दी गई हैं)
4. एक सफल उत्पाद को अधिकांश समस्याओं का सामना करना पड़ता है, महत्वपूर्ण आकारों तक पहुंचता है, जो तब होता है जब कई समस्याओं को ठीक करने की लागत बहुत बड़ी है
5. डेटा भंडारण और प्रसंस्करण का विकल्प एप्लिकेशन आर्किटेक्चर को निर्धारित करता है
6. बाद के चरणों में महत्वपूर्ण वास्तु परिवर्तन करना बहुत महंगा आनंद है।
7. यह विकास के बाद के चरणों में है कि वे व्यापार और लाभप्रदता के मामले में स्पष्ट लाभ के कारण प्रक्रिया को गति देने की कोशिश करते हैं
8. डेटाबेस संरचना में परिवर्तन अक्सर संग्रहीत डेटा के अतिरिक्त प्रसंस्करण / रूपांतरण में प्रवेश करते हैं।
9. बाद के चरणों में, डीबीएमएस की कई सीमाओं के कारण डेटाबेस संरचना में कोई भी परिवर्तन, समस्याग्रस्त हैं।
10. कई परियोजनाओं के लिए, शुरुआती चरणों में डेटाबेस संरचना के संस्करण का स्थानांतरण एक स्पष्ट समाधान प्रतीत होगा, बाद में एक गंभीर सीमा बन जाएगी। अधिक या कम सार्वभौमिक नुस्खा - डेटाबेस संरचना में लगातार बदलाव से बचने के लिए आवश्यक है।

एक और उदाहरण

आधुनिक विकास की विशेषताएं

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

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

सारांश:

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

उदाहरण एक, एक 14-वर्षीय प्रणाली

संक्षिप्त विवरण

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

सरलीकृत मॉडल

वास्तव में, सिस्टम का कार्य प्रत्येक प्रकार के उपकरणों के लिए कई सौ मापदंडों को संग्रहीत करना है, उपयोगकर्ता को उन्हें संपादित करने के लिए एक सुविधाजनक इंटरफ़ेस प्रदान करता है, और डिवाइस को भेजे गए कॉन्फ़िगरेशन का निर्माण करता है।

समयरेखा: शुरुआत

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

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

इस स्तर पर समस्याएं

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

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

तकनीकी विवरण

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

वैसे, आप अक्सर एक कॉल में आते हैं, ALTER TABLE का उपयोग नहीं करने के लिए, एक प्रक्रिया के लिए कॉपी-नाम बदलने को प्राथमिकता देते हैं (उदाहरण के लिए: डोन्ट अलर्ट न करें। कॉपी और नाम बदलें )

सबसे तुच्छ जटिलता के डेटा को परिवर्तित करने के लिए, किसी भी मामले में, आपको कुछ प्रोग्रामिंग भाषा में कार्यान्वित अतिरिक्त तर्क का उपयोग करना होगा।

निर्णय

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

प्रभाव

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

समयरेखा: बनना

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

इस दृष्टिकोण का परिणाम एक्सएमएल कोड का एक पहाड़ था और प्रत्येक बाद के संस्करण में संक्रमण के दौरान बड़ी संख्या में आवश्यक परिवर्तन थे। इस स्तर पर, डेटाबेस को X.1 राज्य से X.2 राज्य में स्थानांतरित करने के लिए (नई कार्यक्षमता जोड़ी गई थी), XML डेटाबेस में संग्रहीत कॉन्फ़िगरेशन प्रतिनिधित्व पर एक या कई परिवर्तन करना आवश्यक था। इस तरह के परिवर्तनों को सफलतापूर्वक करने के बाद ही सिस्टम काम करना शुरू कर सकता है (अपडेटेड कोड सहेजे गए दृश्य को डीसर्विलाइज़ कर सकता है)।

इस स्तर पर समस्याएं

कॉन्फ़िगरेशन परिवर्तन सहेजे गए XML फ़ाइलों के अनुक्रमिक परिवर्तनों का एक समूह थे (xml फाइलें वास्तव में डेटाबेस में संग्रहीत की गई थीं, जो शुरुआती चरणों में उपकरणों के साथ पूरी तरह से संगत थीं)। इन परिवर्तनों में से कुछ ने XML प्रतिनिधित्व को एक स्ट्रिंग के रूप में माना और सामान्य प्रतिस्थापन का उपयोग किया। अन्य प्रोग्रामर DOM ट्री के साथ काम करना पसंद करते हैं या SAX पार्सर का उपयोग करके "अनुकूलित" विकल्प लिखते हैं। इस तरह के परिवर्तन स्वतंत्र थे और उदाहरण के लिए, रिलीज में उनमें से एक बड़ी संख्या की उपस्थिति का मतलब एक प्रकार के कॉन्फ़िगरेशन के लिए कई परिवर्तनों को करने की आवश्यकता हो सकती है, जिनमें से प्रत्येक को DOM ट्री में स्वतंत्र रूप से deserialized किया गया, पेड़ को संशोधित किया गया और बाद में क्रमबद्धता, इस प्रकार संसाधन-गहन दोहराते हुए। पूरी तरह से वैकल्पिक कदम कई बार।

डेवलपर्स के लिए, विकास के दौरान उपयोग किए जाने वाले परीक्षण डेटा के बेहद छोटे आकार के कारण, इस ऑपरेशन में थोड़ा समय लगा। वास्तविक प्रणालियों द्वारा संग्रहीत वास्तविक कॉन्फ़िगरेशन का आकार परिमाण के कई क्रमों से बड़ा था (100 किलोबाइट से 1-2 मेगाबाइट तक, कुल डेटाबेस आकार 1-2 जीबी तक)। सिस्टम के एक नए संस्करण में संक्रमण, एक बार फिर से, ग्राहकों के लिए एक बड़ी समस्या बन गया है।

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

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

निर्णय

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

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

प्रभाव

प्रभाव महत्वपूर्ण नहीं था, इसके अलावा, यह उन ग्राहकों की योग्यता थी, जिन्होंने अंततः (अंततः) अपग्रेड किया और लाइव कार्यों पर सिस्टम का परीक्षण किया।

समयरेखा: परिपक्व प्रणाली

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

इस स्तर पर समस्याएं

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

इसके अलावा, कुछ, विशेष रूप से सक्रिय, क्लाइंट कॉन्फ़िगरेशन का आकार 10 मेगाबाइट और कुल डेटाबेस का आकार 5 गीगाबाइट तक लाने में कामयाब रहे, जिसके बाद उन्हें बहुत ही दिलचस्प समस्याओं का एक नया वर्ग मिला। तस्वीर को पूरा करने के लिए, आप पिछले संस्करणों के उपकरणों के साथ एक प्रणाली को अनुकूल बनाने के लिए नेतृत्व की इच्छा कर सकते हैं। हर समय, उपकरण और नियंत्रण प्रणाली समकालिक रूप से विकसित हुई। उदाहरण: System.1 ने Device.1, System.2 को Device.2, आदि के लिए विन्यास भेजा। डिवाइस के लिए सही कॉन्फ़िगरेशन भेजने के लिए सिस्टम 4 के लिए अवसर प्रदान करने के लिए कार्य निर्धारित किया गया था। 2,3,4। वैसे, मतभेद अक्सर बहुत महत्वपूर्ण थे।

निर्णय

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

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

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

निष्कर्ष

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

विकास की प्रक्रिया काफी तीव्र थी:

याद रखें, दो प्रणालियों का एक वास्तविक ग्राहक सबसे स्थिर और सुविधाजनक विकल्प का चयन करेगा जिसे महंगे रखरखाव की आवश्यकता नहीं होगी और मजबूर निष्क्रियता का न्यूनतम समय प्रदान करेगा। 21 वीं सदी में विकासशील एक सेवा की आवश्यकता है एक प्रणाली कुछ अजीब है। कुछ घंटों से लेकर एक दिन तक "झूठ बोलना" प्रणाली विकसित करना कम से कम बेवकूफी है।

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

बोनस

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