👨🏾‍🍳 🧀 🔓 1440 डेटाबेस माइग्रेशन का अनुभव करें 📢 💞 🏴󠁧󠁢󠁥󠁮󠁧󠁿

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

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

बेशक, यह एक काल्पनिक कहानी है। ऐसा कभी किसी के साथ नहीं हुआ। कम से कम, ऐसा नहीं होता अगर डेटाबेस स्कीमा को बदलने का काम पलायन के माध्यम से आयोजित किया गया होता।

डेटाबेस माइग्रेशन टूल क्या है?

माइग्रेशन के माध्यम से डेटाबेस स्कीमा परिवर्तन के प्रबंधन का विचार अत्यंत सरल है:

प्रत्येक परिवर्तन को एक अलग माइग्रेशन फ़ाइल के रूप में जारी किया जाता है।
माइग्रेशन फ़ाइल में प्रत्यक्ष और रिवर्स दोनों परिवर्तन शामिल हैं।
डेटाबेस में माइग्रेशन का आवेदन एक विशेष उपयोगिता द्वारा किया जाता है।

सबसे सरल प्रवासन उदाहरण:

-- 20180618152059: create sequence for some_table CREATE SEQUENCE some_table_seq; --//@UNDO DROP SEQUENCE some_table_seq;

यह दृष्टिकोण एक सामान्य एसक्यूएल फ़ाइल में परिवर्तन के आयोजन पर कई फायदे प्रदान करता है। मर्ज संघर्षों की मात्र अनुपस्थिति इसके लायक है।

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

माईबैटिस माइग्रेशन के साथ आठ साल

हम Wrike पर 2010 में परिवर्तन के माध्यम से डेटाबेस परिवर्तन दृष्टिकोण का उपयोग करना शुरू कर दिया, मार्च 29, साढ़े बारह बजे। तब से, हमने 1,440 माइग्रेशन लागू किए हैं, जिसमें 6,436 प्रत्यक्ष परिवर्तन और 5,015 रिवर्स शामिल हैं। सामान्य तौर पर, हमने PostgreSQL के साथ संयोजन में MyBatis माइग्रेशन टूल का उपयोग करके कुछ अनुभव प्राप्त किया है।

संक्षेप में, हमने कभी पछतावा नहीं किया। यदि ऐसा होता है कि आप माइग्रेशन या कुछ इसी तरह का उपयोग नहीं कर रहे हैं, तो यह शुरू करने का समय है। हां, पेंटियम 4 भी पुराना है।

लेकिन किसी भी चीज़ की खूबियों के बारे में बात करना उबाऊ है, सीधे कठिनाइयों की ओर चलते हैं।

PostgreSQL बारीकियों

पोस्टग्रेज के लिए माइग्रेशन लिखने में कोई कठिनाई नहीं है, शायद, दो को छोड़कर:

आप अनुक्रमणिका नहीं बना सकते,
आप NOT NULL कॉलम नहीं जोड़ सकते।

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

NULL कॉलम बनाना मुश्किल नहीं है, यहाँ आपको चार चरणों में बदलाव करने की आवश्यकता है:

एक पूर्ण स्तंभ बनाएं (पोस्टग्रेज़ में यह मुफ़्त है)।
एक मान के लिए DEFAULT कॉलम सेट करें।
लूप में, गंभीर रूप से DEFAULT में NULL मान अपडेट करें।
सेट नॉट नॉट।

यहां सबसे बड़ी पकड़ तीसरे पैराग्राफ में है। NULL मानों को भागों में अद्यतन करने की आवश्यकता है, क्योंकि UPDATE some_table SET some_column='' WHERE some_column IS NULL ; तालिका को अवरुद्ध करेगा, जैसा कि सूचकांक के मामले में है, उसी परिणाम के साथ। और माइग्रेशन केवल SQL कमांड निष्पादित कर सकते हैं, इसलिए ऐसी स्क्रिप्ट को हाथ से उत्पादन में रोल करना होगा। औसत से नीचे खुशी। अब, यदि माइग्रेशन में एक चक्र लिखा जा सकता है, तो कोई समस्या नहीं होगी। शायद यह हुक के माध्यम से लागू किया गया है।

एक UNIQUE सूचकांक बनाने और एक PRIMARY KEY को बदलने के लिए भी कुछ कौशल की आवश्यकता होती है, लेकिन ये ऑपरेशन अपेक्षाकृत कम ही होते हैं।

क्लस्टर बारीकियों

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

नतीजतन, git pull बाद git pull डेवलपर को पहले डेटाबेस के पहले उदाहरण में परिवर्तन करना चाहिए, फिर दूसरे उदाहरण के लिए, फिर दूसरे डेटाबेस के पहले उदाहरण और इसी तरह के सिद्धांत पर। यहां डेटाबेस माइग्रेशन प्रबंधन उपयोगिता को प्रबंधित करने के लिए उपयोगिता लिखना सही है। कुल स्वचालन।

भूमिका बाजीगरी

यह कोई रहस्य नहीं है कि भूमिकाएं एक अलग डेटाबेस के स्तर पर नहीं रहती हैं, लेकिन पूरे डेटाबेस सर्वर के स्तर पर, कम से कम पोस्टग्रेज में। इस स्थिति में, आपको REVOKE INSERT ON some_table FROM some_role का उल्लेख करने की आवश्यकता हो सकती है; उत्पादन में पूर्वनिर्धारित होने के लिए भूमिकाओं की अपेक्षा करना अभी भी संभव है, लेकिन देव या मंचन के लिए यह पहले से ही मुश्किल है। उसी समय, विकास में, निश्चित रूप से, सभी डेटाबेस एक ही स्थानीय सर्वर पर मौजूद होते हैं, इसलिए आप केवल माइग्रेशन में CREATE ROLE नहीं लिख सकते हैं, और IF NOT EXISTS समर्थित नहीं है। सब कुछ बस हल किया जाता है:

 DO $$ BEGIN IF NOT EXISTS (SELECT * FROM pg_roles WHERE rolname = 'some_role') THEN CREATE ROLE "some_role" NOLOGIN; END IF; END; $$;

इसे देखो! मैं उन्हें पकड़ता हूं और टॉस करता हूं, पकड़ता हूं और टॉस करता हूं, यह बहुत आसान है

विकास की वास्तविकता का एक सा

डेवलपर्स गलती करते हैं, और यहां तक कि एसक्यूएल पलायन में भी ऐसा होता है। आमतौर पर त्रुटियों को समीक्षा में देखा जा सकता है, लेकिन यह असामान्य भी हो सकता है। यदि हम प्रत्यक्ष परिवर्तनों के बारे में बात करते हैं, तो वहां जाम अभी भी उत्पादन तक नहीं पहुंचता है - सत्यापन के कई चरण हैं। लेकिन उलटे बदलाव के साथ घटनाएं घट सकती हैं। ./migrate up प्रवास में त्रुटियों से बचने के लिए, जब माइग्रेशन का परीक्षण करते हैं, तो आपको न केवल प्रदर्शन करने की आवश्यकता है। यह कुछ भी जटिल नहीं है, आपको बस यह सुनिश्चित करने की आवश्यकता है कि चालीस डेवलपर्स हमेशा ऐसा करते हैं। एक अच्छे तरीके से, उपयोगिता डेवलपर वातावरण के लिए स्वचालित रूप से इस तरह के कॉम्बो का प्रदर्शन कर सकती है।

वातावरण का परीक्षण करें

यदि परीक्षण वातावरण अल्पकालिक है: मान लें कि आप एक कंटेनर बनाते हैं, डेटाबेस को इनिशियलाइज़ करते हैं और इंटीग्रेशन टेस्ट चलाते हैं, तो कोई समस्या नहीं होनी चाहिए। हम ./migrate bootstrap , फिर ./migrate up , और आप कर चुके हैं। बस जब माइग्रेशन की संख्या एक हजार से अधिक हो जाती है, तो इस प्रक्रिया में देरी हो सकती है। यह शर्म की बात है जब डेटाबेस परीक्षण चलाने की तुलना में लंबा है। हमें चकमा देना है।

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

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

यदि समीक्षा के बाद माइग्रेशन पर हस्ताक्षर किए गए थे, तो मंचन के लिए ड्राफ्ट के आवेदन को प्रतिबंधित करना संभव होगा। और changelog में न केवल प्रवास पहचानकर्ता को बचाना संभव होगा, बल्कि checksum भी उपयोगी होगा।

जैसा था वैसा ही लौटा

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

इसी समय, प्रवास पाठ है। और इस पाठ को वहां, changelog में सहेजना संभव होगा। फिर, यदि कोड से माइग्रेशन चला गया है, तो यह किन कारणों से मायने नहीं रखता है, इसे हमेशा वापस लाया जा सकता है। और अपने आप भी।

फिर से पूर्ववत करें

यूएनडीओ अनुभाग निश्चित रूप से आवश्यक है। लेकिन इसे क्यों लिखें? बेशक, आकर्षक मामले हैं, लेकिन ज्यादातर बदलाव CREATE TABLE या ADD COLUMN या CREATE INDEX । उनके लिए, उपयोगिता स्वचालित रूप से रिवर्स ऑपरेशन उत्पन्न कर सकती है, सीधे SQL कोड का उपयोग करके। बेशक, एक विशिष्टता है। CREATE TABLE ${name} - यह एक ऐसी विशेष टीम है, अचानक गैर-मानक। हां, और DROP TABLE ${name} उत्पन्न करने के लिए, आपको तीसरे शब्द तक अभिव्यक्ति को पार्स करने में सक्षम होना चाहिए। हालांकि, सामान्य तौर पर, यह पूरी तरह से संभव तकनीकी कार्य है। आउट ऑफ द बॉक्स हो सकता है।

निष्कर्ष

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

1440 डेटाबेस माइग्रेशन का अनुभव करें