2009-12-25 9 views
16

मैं मोंगोडीबी या कॉच डीबी जैसे डेटाबेसों के लिए स्कीमा माइग्रेशन को स्वचालित करने का एक तरीका ढूंढ रहा हूं।क्या NoSQL डेटाबेस के लिए स्कीमा माइग्रेशन के लिए कोई उपकरण हैं?

पसंदीदा रूप से, यह नमूना पायथन में लिखा जाना चाहिए, लेकिन कोई अन्य भाषा ठीक है।

+0

सवाल यह है कि एक NoSQL में रिलेशनल सुविधाओं emulates है? उदाहरण के लिए, कुंजी-मूल्य भंडारण में कई से अधिक संबंधों का सही तरीका क्या है? या बाधाएं? एसओ, बीटीडब्ल्यू में आपका स्वागत है :-) – sastanin

+0

नहीं। मेरा मतलब स्कीमा माइग्रेशन है। एक दस्तावेज़ संस्करण से दूसरे में माइग्रेट कैसे करें (फ़ील्ड का नाम बदलें, आदि)। –

उत्तर

9

चूंकि एक नोस्कल डेटाबेस में बड़ी मात्रा में डेटा हो सकता है, जिसे आप नियमित rdbms sence में माइग्रेट नहीं कर सकते हैं। दरअसल आप इसे rdbms के साथ-साथ जैसे ही आपका डेटा कुछ आकार सीमा पास नहीं कर सकते हैं। किसी मौजूदा तालिका में फ़ील्ड जोड़ने के लिए एक दिन के लिए अपनी साइट को नीचे लाने के लिए अव्यवहारिक है, और इसलिए rdbms के साथ आप केवल बदले में पैच कर रहे हैं जैसे कि फ़ील्ड के लिए नई टेबल जोड़ना और डेटा प्राप्त करने के लिए जुड़ना। नोस्कल दुनिया में आप कई चीजें कर सकते हैं।

  • जैसा कि अन्य ने सुझाव दिया है कि आप अपना कोड लिख सकते हैं ताकि यह संभावित स्कीमा के विभिन्न 'संस्करण' को संभाले। यह आमतौर पर आसान है तो यह दिखता है। कई प्रकार के स्कीमा परिवर्तन चारों ओर कोड के लिए तुच्छ हैं। उदाहरण के लिए यदि आप स्कीमा में एक नया फ़ील्ड जोड़ना चाहते हैं, तो आप इसे सभी नए रिकॉर्ड में जोड़ दें और यह सभी पुराने रिकॉर्ड पर खाली होगा (आपको "फ़ील्ड मौजूद नहीं है" त्रुटियां या कुछ भी नहीं मिलेगा;)। यदि आपको पुराने रिकॉर्ड में फ़ील्ड के लिए 'डिफ़ॉल्ट' मान की आवश्यकता है तो कोड में बहुत ही कम किया जाता है।
  • एक अन्य विकल्प है और वास्तव में केवल समझदार विकल्प क्षेत्र की तरह गैर तुच्छ स्कीमा परिवर्तन के साथ आगे जाने का नाम बदलता है और संरचनात्मक परिवर्तन प्रत्येक रिकॉर्ड में schema_version स्टोर करने के लिए, और पर पढ़ें अगले करने के लिए किसी भी संस्करण से डेटा माइग्रेट करने के लिए कोड है । यानी यदि आपका वर्तमान स्कीमा संस्करण 10 है और आप 7 के संस्करण के साथ डेटाबेस से एक रिकॉर्ड पढ़ते हैं, तो आपकी डीबी परत को migrate_8, migrate_9, और migrate_10 पर कॉल करना चाहिए। इस तरह से उपयोग किया जाने वाला डेटा धीरे-धीरे नए संस्करण में माइग्रेट हो जाएगा। और अगर यह तक नहीं पहुँचा है, तो कौन परवाह करता है कि कौन सा संस्करण यह है;)
3

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

+4

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

+2

मुझे लगता है कि NoSQL डेटाबेस के लिए हमारे पास "डेटा माइग्रेशन" टूल होना चाहिए, बल्कि "स्कीमा माइग्रेशन" टूल। यदि कोई नहीं है, तो मैं खुद को लिखूंगा। –

+0

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

2

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

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

+0

एचएम, यह एक समझ में आता है। लेकिन सवाल तैयार उपकरणों के बारे में है, जो मुझे मेरे दस्तावेज़ संस्करणों को अद्यतित रखने में भी मदद करेगा। –

1

एक परियोजना एक NoSQL डेटाबेस के संबंध में एक स्कीमा माइग्रेशन के लिए एक की जरूरत है जब मुझे लगता है कि आप अभी भी एक संबंधपरक डेटाबेस में सोच रहे हैं बनाता है तरीका, लेकिन एक NoSQL डेटाबेस का उपयोग कर।

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

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

कृपया ध्यान रखें जब आपको लगता है और डिजाइन अलग ढंग से तुलना कि NoSQL भंडारण सबसे अच्छा काम करता है जब एक आरडीबीएमएस का उपयोग करने के

+0

यह एक समाधान नहीं है। आपके लिए धन्यवाद "दिलचस्प" IMHO। –

+1

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

+0

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