2010-07-29 11 views
13

एप्लिकेशन कोड और कॉन्फ़िगरेशन फ़ाइलों को कोड संग्रह में बनाए रखा जाता है। लेकिन कभी-कभी, परियोजना के एक हिस्से के रूप में, मेरे पास कुछ डेटा भी होता है (जो कुछ मामलों में> 100 एमबी,> 1 जीबी या तो हो सकता है), जिसे डेटाबेस में संग्रहीत किया जाता है। गिट कोड और उसके परिवर्तनों को संभालने में अच्छा काम करता है, लेकिन विकास टीम आसानी से डेटा कैसे साझा कर सकती है?किसी एप्लिकेशन के साथ डेटासेट को कैसे प्रबंधित करें?

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

आप ऐसी परिस्थितियों को कैसे संभालेंगे?

+0

डेटा से डेटा का मतलब है कि किसी डेटाबेस या कुछ फ्लैट फ़ाइल में डेटा (उदाहरण के लिए एमपी 3 फाइलों की फिल्म या संग्रह)? – slebetman

+0

मेरे मामले में यह एक डेटाबेस है। मैं इसे कुछ एक्सएमएल/जेएसओएन/एसक्यूएल फाइल में निर्यात कर सकता हूं, लेकिन यह एक बहुत बड़ी फाइल होगी। –

उत्तर

4

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

आपके डेटाबेस के आकार के कारण इसका अर्थ एक बड़ा "संस्करण 0" फ़ाइल होगा। लेकिन, माइग्रेशन रणनीति का उपयोग करके, उसके बाद अद्यतनों को प्रबंधित किया जाना चाहिए क्योंकि वे केवल डेल्टा होंगे। आप अपने मौजूदा माइग्रेशन को एक से एक से liquibase में कनवर्ट करने में सक्षम हो सकते हैं, साथ ही यह एक बड़े-बैंग दृष्टिकोण से बेहतर हो सकता है।

यदि आप डेल्टा बहुत बड़े हैं तो आप @belisarius की रणनीति का लाभ उठा सकते हैं ताकि प्रत्येक डेवलपर को व्यक्तिगत रूप से डेल्टा लागू करने की आवश्यकता न हो।

2

हम आमतौर पर डेटाबेस सिंक या प्रतिकृति स्कीमा का उपयोग करते हैं।

प्रत्येक डेवलपर के पास डेटाबेस की 2 प्रतियां होती हैं, एक काम करने के लिए और दूसरा सिंक संस्करण रखने के लिए।

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

यह प्रतिकृति स्कीमा के रूप में मजबूत है .... कभी-कभी (डीबी के आधार पर) जो अच्छी खबर का प्रतिनिधित्व नहीं करता है।

3

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

इस बात को ध्यान में रखते हुए, एक निर्भरता प्रबंधक (उदा। Apache Ivy) को अपनी निर्माण प्रक्रिया के साथ एकीकृत क्यों न करें और इसे अपने डेटाबेस को प्रबंधित करने दें? ऐसा लगता है कि एक निर्भरता प्रबंधक के लिए बनाया गया था।

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

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

+0

धन्यवाद ग्रेग, आपका पहला समाधान अच्छा लगता है। मैं इसे देख लूँगा। आपका दूसरा समाधान - डीबी डेटा माइग्रेशन - सिद्धांत में बहुत अच्छा है, लेकिन मैं इसे वास्तविक जीवन में काम नहीं कर सका (मैं वर्तमान में इसका उपयोग कर रहा हूं, और यही मेरा प्रश्न है)। यह बताने के लिए एक टिप्पणी से अधिक समय लगेगा क्यों। मुझे शायद इसके बारे में एक ब्लॉग पोस्ट लिखना चाहिए :) –

+0

@Ofri, यकीन है कि समझ में आता है। अभी भी सामान्य मामले के लिए उपयोगी हो सकता है - यह वही है जो मैं खुद को इसी तरह की स्थितियों में अक्सर करता हूं। दुर्भाग्यवश, मुझे लगता है कि कुछ बड़े डाउनलोड होने जा रहे हैं और इसके चारों ओर कोई रास्ता नहीं है ... अच्छी बात यह है कि हमने पिछले डायल-अप को स्थानांतरित कर दिया है। :-) – Greg

+0

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

1

DataGrove एक नया उत्पाद है जो आपको डेटाबेस के लिए संस्करण नियंत्रण देता है। हम आपको पूरे डेटाबेस (स्कीमा और डेटा) को स्टोर करने, टैग करने, पुनर्स्थापित करने और किसी भी समय डेटाबेस को साझा करने की अनुमति देते हैं।

ऐसा लगता है कि आप क्या देख रहे हैं।

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