परिचय

नमस्कार, हेब्र!

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

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

इससे पहले कि मैं आगे जाऊं, मुझे निम्नलिखित धारणाएं बनाने दें।

आप अधिकांश अनुप्रयोगों के डेटाबेस के साथ काम करने के तर्क को 3 भागों में विभाजित कर सकते हैं:

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

डाउनटाइम एक ऐसी स्थिति है जब हमारे व्यावसायिक तर्क का एक हिस्सा उपयोगकर्ता के लिए ध्यान देने योग्य समय के लिए उपलब्ध नहीं है / गिरता है / भरी हुई है, मान लीजिए कि यह कुछ सेकंड का है।

डाउनटाइम की अनुपस्थिति किसी व्यवसाय के लिए एक महत्वपूर्ण स्थिति हो सकती है, जिसका किसी भी प्रयास से पालन किया जाना चाहिए।

रोल आउट प्रक्रिया

बाहर रोल करते समय मुख्य आवश्यकताएं:

1. हमारे पास एक काम करने का आधार है।
2. हमारे पास कई मशीनें हैं जहां व्यापार तर्क घूमता है।
3. व्यापार तर्क के साथ कारें बैलेंसर के पीछे छिपी हुई हैं।
4. हमारा आवेदन पहले, उसके दौरान और बाद में माइग्रेशन (पुराने कोड पुराने और नए डेटाबेस स्कीमा के साथ सही ढंग से काम करता है) के लिए अच्छी तरह से काम करता है।
5. हमारा एप्लिकेशन कारों पर कोड को अपडेट करने के दौरान, उसके पहले और बाद में अच्छी तरह से काम करता है (पुराने और नए कोड वर्तमान डेटाबेस योजना के साथ सही ढंग से काम करते हैं)।

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

प्रत्यक्ष रोलिंग आदेश:

1. प्रवास में बाढ़;
2. बैलेंसर से एक मशीन को हटा दिया, मशीन को अपडेट किया और फिर से शुरू किया, मशीन को बैलेंसर को लौटा दिया;
3. सभी कारों को अपडेट करने के लिए पिछले चरण को दोहराया।

रिवर्स रोल-आउट ऑर्डर टेबल और कॉलमों को हटाने के लिए प्रासंगिक है, जब हम स्वचालित रूप से परिवर्तित योजना के अनुसार माइग्रेशन बनाते हैं और CI के सभी माइग्रेशनों की उपस्थिति को मान्य करते हैं:

1. बैलेंसर से एक मशीन को हटा दिया, मशीन को अपडेट किया और फिर से शुरू किया, मशीन को बैलेंसर को लौटा दिया;
2. सभी कारों को अपडेट करने के लिए पिछले चरण को दोहराया;
3. माइग्रेशन में बाढ़ आ गई।

सिद्धांत

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

पोस्टग्रेज में कई प्रकार के ताले होते हैं, आप यहां अधिक विवरण देख सकते हैं, विषय के भाग के रूप में, मैं केवल टेबल को कवर करूंगा और ताले लिखूंगा।

टेबल स्तर के ताले

टेबल स्तर पर, पोस्टग्रेज में कई प्रकार के ताले होते हैं , मुख्य विशेषता यह है कि उनके बीच टकराव होता है, अर्थात परस्पर विरोधी ताले के साथ दो ऑपरेशन एक साथ नहीं किए जा सकते हैं:

उदाहरण के लिए, ALTER TABLE tablename ADD COLUMN newcolumn integer और SELECT COUNT(*) FROM tablename को एक-एक करके सख्ती से निष्पादित किया जाना चाहिए, अन्यथा हम यह नहीं पता लगा सकते हैं कि COUNT(*) पर लौटने के लिए कौन से कॉलम हैं।

Django के माइग्रेशन (नीचे पूरी सूची) में, निम्नलिखित ऑपरेशन और उनके संबंधित ताले हैं:

सभी टिप्पणियों में से, सभी ALTER TABLE में एक समान विशिष्ट लॉक नहीं है, साथ ही django के माइग्रेशनों में CREATE INDEX CONCURRENTLY और ALTER TABLE VALIDATE CONSTRAINT , लेकिन बाद में मानक संचालन के लिए एक सुरक्षित विकल्प के लिए इनकी आवश्यकता होगी।

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

यहां दो बिंदुओं को संक्षेप में प्रस्तुत किया जा सकता है:

1. अगर आसान लॉकिंग का विकल्प है, तो आप इसे CREATE INDEX और CREATE INDEX CONCURRENTLY रूप में उपयोग कर सकते हैं।
2. व्यापार तर्क के साथ डेटा स्कीमा संघर्ष को बदलने के लिए सबसे अधिक माइग्रेशन, इसके अलावा, वे ACCESS EXCLUSIVE साथ संघर्ष करते हैं, ACCESS EXCLUSIVE , हम इस लॉक को पकड़ते समय भी SELECT करने में सक्षम नहीं होते हैं और संभवतः यहां डाउनटाइम की अपेक्षा करते हैं, इस मामले को छोड़कर जब यह ऑपरेशन तुरंत काम नहीं करता है और हमारा डाउनटाइम होगा कुछ सेकंड के लिए।

एक विकल्प होना चाहिए, या हम हमेशा ACCESS EXCLUSIVE से बचते हैं, ACCESS EXCLUSIVE , हम नई प्लेट बनाते हैं और डेटा को वहां कॉपी करते हैं - मज़बूती से, लेकिन डेटा की एक बड़ी मात्रा के लिए लंबे समय के लिए, या हम जितनी जल्दी हो सके ACCESS EXCLUSIVE बनाते हैं और डाउनटाइम के खिलाफ अतिरिक्त चेतावनी देते हैं - यह संभावित रूप से खतरनाक है, लेकिन तेज़ है।

रिकॉर्ड ताले

रिकॉर्डिंग स्तर पर, वहाँ भी ताले हैं https://www.postgresql.org/docs/current/static/explicit-locking.html#LOCKING-ROWS , वे भी संघर्ष करते हैं, लेकिन वे केवल हमारे व्यापार तर्क को प्रभावित करते हैं:

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

संचालन का क्रम

एक और महत्वपूर्ण ज्ञान है कि ऑपरेशन कैसे किया जाएगा, कब और कैसे वे ताले लेते हैं और जारी करते हैं:

यहाँ आप निम्न मदों को उजागर कर सकते हैं:

1. ऑपरेशन के निष्पादन का समय - माइग्रेशन के लिए यह लॉक को पकड़ने का समय होता है, अगर हेवी लॉक को लंबे समय तक रखा जाता है, तो हमारे पास एक डाउनटाइम होगा, उदाहरण के लिए, यह CREATE INDEX या ALTER TABLE ADD COLUMN SET DEFAULT साथ हो सकता है (पोस्टग्रास 11 में यह बेहतर है)।
2. परस्पर विरोधी तालों के लिए प्रतीक्षा समय - अर्थात, प्रवासन तब तक प्रतीक्षा करता है जब तक कि सभी परस्पर विरोधी अनुरोध काम नहीं करते हैं, और इस समय नए अनुरोध हमारे प्रवासन की प्रतीक्षा करेंगे, धीमी गति से अनुरोध यहां बहुत खतरनाक हो सकते हैं, या तो केवल इष्टतम या विश्लेषणात्मक नहीं है, इसलिए इसके दौरान धीमी गति से नहीं होना चाहिए। पलायन।
3. प्रति सेकंड अनुरोधों की संख्या - यदि हमारे पास लंबे समय तक काम करने के कई अनुरोध हैं, तो मुफ्त कनेक्शन जल्दी से समाप्त हो सकते हैं और एक समस्याग्रस्त स्थान के बजाय, पूरा डेटाबेस डाउनटाइम में जा सकता है (सुपरसुअर के लिए केवल एक कनेक्शन सीमा होगी), यहां आपको धीमी अनुरोधों से बचने की आवश्यकता है, अनुरोधों की संख्या कम करें उदाहरण के लिए, न्यूनतम लोड के दौरान माइग्रेशन शुरू करें, अपने स्वयं के डेटाबेस के साथ विभिन्न सेवाओं में महत्वपूर्ण घटकों को अलग करें।
4. एक लेन-देन में माइग्रेशन के कई संचालन होते हैं - एक लेनदेन में अधिक संचालन, लंबे समय तक लॉक आयोजित किया जाता है, इसलिए भारी संचालन को अलग करना बेहतर होता है, एक भारी लॉक के साथ एक लेन-देन में कोई डेटा ALTER TABLE VALIDATE CONSTRAINT डेटा या डेटा माइग्रेशन नहीं।

समय समाप्ति

lock_timeout में lock_timeout और statement_timeout जैसी सेटिंग्स हैं, जो माइग्रेशन की शुरुआत को सुरक्षित रख सकती हैं, दोनों ही खराब लिखित माइग्रेशन से और खराब परिस्थितियों से जिनमें माइग्रेशन को ट्रिगर किया जा सकता है। उन्हें विश्व स्तर पर और वर्तमान कनेक्शन दोनों के लिए स्थापित किया जा सकता है।

SET lock_timeout TO '2s' माइग्रेशन से पहले धीमे अनुरोधों / लेन-देन की प्रतीक्षा करते समय डाउनटाइम से बच जाएगा: https://www.postgresql.org/docs/current/static/runtime-config-client.html##UC-LOCK-TIMEOUT ।

SET statement_timeout TO '2s' हैवी लॉक से भारी माइग्रेशन शुरू करने पर डाउनटाइम से बच जाएगा: https://www.postgresql.org/docs/current/static/runtime-config-client.html##UC-STATEMENT-TIMEOUT ।

Dedloki

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

रिकॉर्ड भंडारण

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

मल्टीवर्सन कंसीवेंसी कंट्रोल (MVCC)

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

Django उदाहरण

हमें अब इस बात का अंदाजा है कि डाउनटाइम किस पर निर्भर हो सकता है और इससे कैसे बचा जा सकता है, लेकिन ज्ञान को लागू करने से पहले, आप देख सकते हैं कि django किस बॉक्स से बाहर निकलता है ( https://github.com/django/django/blob/2.1.2.django) /db/backends/base/schema.py और https://github.com/django/django/blob/2.1.2/django/db/backends/postgresql/schema.py

Django मेरे प्रवास की जरूरतों को बहुत अच्छी तरह से कवर करता है, अब हम अपने ज्ञान के साथ डाउनटाइम के बिना माइग्रेशन के लिए सुरक्षित और खतरनाक संचालन पर चर्चा कर सकते हैं।

हम SHARE UPDATE EXCLUSIVE लॉकिंग या ACCESS EXCLUSIVE साथ सुरक्षित माइग्रेशन कहेंगे, जो तुरंत काम करता है।
हम SHARE और ACCESS EXCLUSIVE ताले के साथ खतरनाक माइग्रेशन कहेंगे, जिनमें काफी समय लगता है।

मैं महान उदाहरणों के साथ प्रलेखन के लिए एक उपयोगी लिंक छोड़ दूंगा।

तालिका बनाएं और हटाएं

CREATE SEQUENCE , DROP SEQUENCE , CREATE TABLE , DROP TABLE को सेफ कहा जा सकता है, क्योंकि बिजनेस लॉजिक या तो माइग्रेटेड टेबल के साथ काम नहीं करता है, फॉरवर्ड डिजाइन के साथ टेबल डिलीट करने का व्यवहार थोड़ा बाद में होगा।

भारी कार्यपत्रक संचालन का समर्थन किया

ALTER TABLE RENAME TO - मैं इसे सुरक्षित नहीं कह सकता, क्योंकि प्रवास के पहले और बाद में ऐसी तालिका के साथ काम करने वाले तर्क लिखना कठिन है।

जैसे ही यह शारीरिक रूप से प्लेट को स्थानांतरित करता है, तब ALTER TABLE SET TABLESPACE - असुरक्षित, और यह एक बड़ी मात्रा में एक लंबा समय ले सकता है।

दूसरी ओर, ये ऑपरेशन बेहद दुर्लभ हैं, एक विकल्प के रूप में आप एक नई तालिका बनाने और उसमें डेटा कॉपी करने की पेशकश कर सकते हैं।

कॉलम बनाएं और हटाएं

ALTER TABLE ADD COLUMN , ALTER TABLE DROP COLUMN - को सुरक्षित कहा जा सकता है (DEFAULT / NOT NULL / PRIMARY KEY / UNIQUE के बिना निर्माण), क्योंकि व्यावसायिक तर्क या तो किसी माइग्रेटेड कॉलम के साथ काम नहीं करता है, FOREIGN KEY के साथ कॉलम हटाने का व्यवहार नहीं करता है। अन्य स्थिरांक और सूचकांक बाद में आएंगे।

ALTER TABLE ADD COLUMN SET DEFAULT , ALTER TABLE ADD COLUMN SET NOT NULL , ALTER TABLE ADD COLUMN PRIMARY KEY , ALTER TABLE ADD COLUMN UNIQUE असुरक्षित संचालन, क्योंकि वे एक कॉलम जोड़ते हैं और, ताले जारी किए बिना, डिफॉल्ट्स के साथ डेटा अपडेट करते हैं या निर्माण कार्य की तरह बनाते हैं। अशक्त स्तंभ और आगे परिवर्तन।

यह 11 SET DEFAULT में तेजी से SET DEFAULT उल्लेख करने योग्य है, इसे सुरक्षित माना जा सकता है, लेकिन यह django में बहुत उपयोगी नहीं है, क्योंकि django केवल कॉलम भरने के लिए SET DEFAULT का उपयोग करता है और फिर DROP DEFAULT बनाता है, और अंतराल और माइग्रेशन और अद्यतन मशीनों के साथ अंतराल में व्यावसायिक तर्क, रिकॉर्ड बनाए जा सकते हैं जिसमें डिफ़ॉल्ट अनुपस्थित होगा, अर्थात्, फिर सभी समान, डेटा माइग्रेशन करते हैं।

वर्कशीट पर भारी समर्थन वाला संचालन

ALTER TABLE RENAME COLUMN - मैं भी इसे सुरक्षित नहीं कह सकता, क्योंकि प्रवास के पहले और बाद में इस तरह के स्तंभ के साथ काम करने वाले तर्क लिखना कठिन है। बल्कि, यह ऑपरेशन भी अक्सर नहीं होगा, एक विकल्प के रूप में एक नया कॉलम बनाने और इसे डेटा कॉपी करने का प्रस्ताव किया जा सकता है।

स्तंभ परिवर्तन

ALTER TABLE ALTER COLUMN TYPE - ऑपरेशन खतरनाक और सुरक्षित दोनों हो सकता है। सुरक्षित यदि केवल पोस्टग्रेज ही स्कीम में बदलाव करता है, और डेटा पहले से ही आवश्यक प्रारूप में संग्रहीत है और अतिरिक्त प्रकार के चेक की आवश्यकता नहीं है, उदाहरण के लिए:

• varchar(LESS) से varchar(MORE) टाइप परिवर्तन;
• प्रकार varchar(ANY) परिवर्तन varchar(ANY) से text परिवर्तन;
• numeric(LESS, SAME) से numeric(LESS, SAME) परिवर्तन numeric(MORE, SAME) ।

ALTER TABLE ALTER COLUMN SET NOT NULL खतरनाक ALTER TABLE ALTER COLUMN SET NOT NULL है, क्योंकि यह NULL के अंदर डेटा और जांच से गुजरता है, सौभाग्य से इस निर्माण को दूसरे CHECK IS NOT NULL बदला जा सकता CHECK IS NOT NULL । यह ध्यान देने योग्य है कि यह प्रतिस्थापन एक अलग योजना का नेतृत्व करेगा, लेकिन समान गुणों के साथ।

ALTER TABLE ALTER COLUMN DROP NOT NULL , ALTER TABLE ALTER COLUMN SET DEFAULT , ALTER TABLE ALTER COLUMN DROP DEFAULT - सुरक्षित संचालन।

अनुक्रमणिका और स्थिरांक बनाना और हटाना

ALTER TABLE ADD CONSTRAINT CHECK और पूर्व ALTER TABLE ADD CONSTRAINT FOREIGN KEY असुरक्षित संचालन हैं, लेकिन उन्हें NOT VALID जा सकता है और तब ALTER TABLE VALIDATE CONSTRAINT NOT VALID रूप में घोषित किया जा सकता है।

ALTER TABLE ADD CONSTRAINT PRIMARY KEY और ALTER TABLE ADD CONSTRAINT UNIQUE असुरक्षित हैं, क्योंकि वे अंदर एक अद्वितीय सूचकांक बनाते हैं, लेकिन आप CONCURRENTLY रूप में एक अद्वितीय सूचकांक बना सकते हैं, फिर USING INDEX माध्यम से रेडी-मेड इंडेक्स का उपयोग करके संबंधित स्थिरांक बनाएं।

CREATE INDEX एक असुरक्षित ऑपरेशन है, लेकिन एक सूचकांक को CONCURRENTLY के रूप में बनाया जा सकता है।

ALTER TABLE DROP CONSTRAINT CHECK , ALTER TABLE DROP CONSTRAINT CHECK , ALTER TABLE DROP CONSTRAINT FOREIGN KEY ALTER TABLE DROP CONSTRAINT PRIMARY KEY , ALTER TABLE DROP CONSTRAINT UNIQUE , DROP INDEX - सुरक्षित संचालन।

यह ध्यान देने योग्य है कि ALTER TABLE ADD CONSTRAINT FOREIGN KEY और ALTER TABLE DROP CONSTRAINT FOREIGN KEY एक ही बार में दो टेबल लॉक करते हैं।

Django में ज्ञान लागू करना

Django के पास किसी भी SQL को निष्पादित करने के लिए माइग्रेशन में एक ऑपरेशन है: https://docs.djangoproject.com/en/2.1/ref/migration-operations/#django.db.migrations.operations.RunSQL । इसके माध्यम से, आप आवश्यक टाइमआउट सेट कर सकते हैं और माइग्रेशन के लिए वैकल्पिक संचालन को लागू कर सकते हैं, यह दर्शाता है कि हम जिस स्थान को बदल रहे हैं, वह state_operations ।

यह अपने कोड के लिए अच्छी तरह से काम करता है, हालांकि इसके लिए अतिरिक्त लेखन की आवश्यकता होती है, लेकिन आप db बैकएंड पर गंदा काम छोड़ सकते हैं, उदाहरण के लिए, https://github.com/tbicr/django-pg-zero-downtime-migrations//lob/master/django_zero_downtime_migrations_postgres_backend .py वर्णित प्रथाओं को इकट्ठा करता है और सुरक्षित समकक्षों के साथ असुरक्षित संचालन की जगह लेता है, और यह तीसरे पक्ष के पुस्तकालयों के लिए काम करेगा।

अंत में

इन प्रथाओं ने मुझे बॉक्स के बाहर django द्वारा बनाई गई एक समान योजना प्राप्त करने की अनुमति दी, जिसमें CHECK IS NOT NULL निर्माण के स्थान पर NOT NULL और कुछ निर्माण नाम (उदाहरण के लिए, ALTER TABLE ADD COLUMN UNIQUE और एक विकल्प के लिए) को शामिल किया गया। वैकल्पिक माइग्रेशन परिचालनों के लिए एक अन्य ट्रेड-ऑफ में लेन-देन की कमी हो सकती है, विशेष रूप से जहां CREATE INDEX CONCURRENTLY और ALTER TABLE VALIDATE CONSTRAINT ।

यदि आप पोस्टग्रेट्स से आगे नहीं जाते हैं, तो डेटा योजना को बदलने के लिए कई विकल्प हो सकते हैं, और वे विशिष्ट सेवाओं के संयोजन में भिन्न हो सकते हैं:

• jsonb का उपयोग schamaless घोल के रूप में किया जाता है
• डाउनटाइम पर जाने का अवसर
• डाउनटाइम के बिना माइग्रेशन करने की आवश्यकता

किसी भी मामले में, मुझे उम्मीद है कि सामग्री या तो समयोपरि बढ़ाने या चेतना का विस्तार करने के लिए उपयोगी साबित हुई।