2011-08-30 15 views
8

जब आप SimpleDB जैसे नोस्क्ल स्टोर का उपयोग कर रहे हैं तो आप एक प्रमुख स्कीमा परिवर्तन कैसे प्रबंधित करते हैं?एनओएसक्यूएल स्टोरेज सिस्टम में स्कीमा परिवर्तनों को कैसे कार्यान्वित करें

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

SQL डेटाबेस के साथ आप क्लाइंट सॉफ़्टवेयर परिनियोजन प्रक्रिया के हिस्से के रूप में एसक्यूएल कथन का सेट चलाएंगे। जाहिर है, यह सरल डीबी जैसे

  • SQL अद्यतन कथन के बराबर नहीं है।
  • SimpleDB की वितरित प्रकृति के कारण, यह जानने का कोई तरीका नहीं है कि डेटाबेस में किए गए परिवर्तनों ने आपके क्लाइंट सॉफ़्टवेयर को चलाने वाले सभी नोड्स को 'फ़िल्टर किया' है।

कुछ समाधान मैं के बारे में सोचा है

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

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

यह सब जटिल है और मुझे आश्चर्य है कि मुझे कुछ याद आ रहा है?

धन्यवाद

रिचर्ड

उत्तर

4

मैं आपके दूसरे विकल्प के समान कुछ उपयोग करता हूं, लेकिन संस्करण विशेषता के बिना।

सबसे पहले, अपने परिवर्तनों को उन चीज़ों में रखने की कोशिश करें जो पिछड़े संगत बनाने में आसान हैं - प्राथमिक कुंजी को बदलने के लिए यह सबसे खराब स्थिति है।

फ़ील्ड को निकालना आसान है - बस उस फ़ील्ड को लिखना बंद करें जब सभी सर्वर एक संस्करण चला रहे हैं जिसके लिए इसकी आवश्यकता नहीं है।

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

फ़ील्ड बदलना इन दोनों परिचालनों का एक संयोजन है।

इस दृष्टिकोण के साथ परिवर्तन के रूप में लागू होते हैं - नए संस्करण का उपयोग करके लिखें, लेकिन पुराने संस्करण को नए क्षेत्र के लिए डिफ़ॉल्ट या व्युत्पन्न मानों के साथ पढ़ने की अनुमति दें।

आप एक ही कोड को सभी रिकॉर्ड अपडेट करने के लिए एक ही कोड का उपयोग कर सकते हैं, हालांकि यह एक बड़े डेटासेट पर उपयुक्त नहीं हो सकता है।

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

1

RavenDB एक और NoSQL डेटाबेस माइग्रेशन का उपयोग करता है इस

http://ayende.com/blog/66563/ravendb-migrations-rolling-updates

http://ayende.com/blog/66562/ravendb-migrations-when-to-execute

आम तौर पर परिवर्तन के इन प्रकार के अपने आवेदन के द्वारा नियंत्रित किया जाता है कि बदलता है हासिल करने के लिए संस्करण एक्स और कन्वर्टि लोड करने पर एक नया स्कीमा संस्करण वाई के लिए और

संबंधित मुद्दे