NoSQL बनाम SQL डेटाबेस के बारे में चर्चा करते हुए, मैं कभी-कभी सुनता हूं कि कंपनियां स्कीमालेस NoSQL डेटाबेस का उपयोग करना पसंद करती हैं क्योंकि स्कीमा को एक नए संस्करण में स्थानांतरित करना समस्याग्रस्त है। लेकिन क्या उन्नयन करते समय यह वास्तव में एक बड़ी समस्या है? क्या इस तरह के ऑपरेशन के लिए रिलेशनल डेटाबेस खराब हैं?
मैं इस ब्लॉग पोस्ट को MongoDB ब्लॉग पर पढ़ता हूं: क्यों स्कीमलेस?
जवाबों:
सिर्फ इसलिए कि आपके NoSql डेटाबेस में एक पारंपरिक अर्थ में स्कीमा नहीं है, इसका मतलब यह नहीं है कि एक तार्किक स्कीमा नहीं है जिसे आपको इन परिवर्तनों से निपटने की आवश्यकता है। MongoDb का उपयोग करते हुए एक विशिष्ट ऐप के मामले में, सबसे अधिक संभावना है कि आपका कोड निश्चित तरीके से व्यवहार करने के लिए जोंस ऑब्जेक्ट के कुछ क्षेत्रों की अपेक्षा करता है। यदि आप व्यवहार को बदलते हैं, तो यह इस प्रकार है कि आप डेटाबेस में पहले से मौजूद डेटा को अपडेट करना चाहते हैं। अब, पारंपरिक RDBMS के साथ यह काफी हद तक सुलझी हुई समस्या थी - आपको केवल अंतर्निहित तालिकाओं को बदलना पड़ा। लेकिन इन newfangled NoSQL डेटाबेस के साथ, आपके पास एक निर्णय है - क्या आप अपने सभी ऑब्जेक्ट्स को मून करने और अपडेट करने के लिए एक स्क्रिप्ट लिखते हैं? या क्या आप मक्खी पर संस्करणों के बीच बदलने के लिए कोड जोड़ते हैं? यदि हां, तो आप कब तक v1 वस्तुओं का समर्थन करते हैं? सदैव? V3 तक?
मैं जोड़ता हूँ कि MongoDb ब्लॉग पोस्ट में उपयोग किया जाने वाला उदाहरण थोड़ा सरल है और अगर आपको एक अच्छी अपडेट प्रक्रिया मिल गई है, तो कोई भी आसान मामला नहीं है, कोई बात नहीं कि RDBMS क्या है; एक फ़ील्ड जोड़ने से शायद ही कभी दर्द होता है। यह तब होता है जब आप अपने Nameक्षेत्र को विभाजित करने का निर्णय लेते हैं FirstNameऔर LastNameयह चीजें रोमांचक हो जाती हैं।
लेकिन क्या उन्नयन करते समय यह वास्तव में एक बड़ी समस्या है?
यह हो सकता है।
कुछ संगठन हैं - अच्छी तरह से अव्यवस्थित, और स्कीमा प्रवास का बहुत बुरा काम करते हैं।
"माइग्रेशन वीकेंड"। सर्वर बंद करो। सभी डेटा का बैकअप लें और निर्यात करें। नया स्कीमा बनाएँ (अक्सर मौजूदा स्कीमा को संशोधित करके)। पुनः लोड डेटा या जगह में पुनर्गठन का प्रयास।
"कंटीन्यू ट्विकिंग"। SQL द्वारा अनुमत सीमा तक तालिकाएँ बदलें। ALTER के प्रदर्शन के अनुक्रम को ट्रैक किए बिना। पिछले स्कीमा संस्करण में वापस जाने का कोई तरीका नहीं है। जहां आवश्यक हो, मौजूदा तालिकाओं से नई तालिकाएं बनाएं, नई तालिकाओं का उपयोग करने के लिए सभी अनुप्रयोगों को उम्मीद से समायोजित करें। लेकिन - अच्छे क्यूए की कमी - पुरानी तालिकाओं को "बस के मामले में" छोड़ देना।
"पूर्ण दहशत"। बस स्कीमा संशोधनों को रोकें। एक बड़ा बदबू बनाओ। दावा करें कि जोखिम बहुत अधिक है। इस दिशा में सभी प्रयासों को अवरुद्ध करें। कुछ अधिक समझदार दृष्टिकोण अपनाने के लिए मजबूर होने तक स्कीमा को बंधक बना लें।
क्या इस तरह के ऑपरेशन के लिए रिलेशनल डेटाबेस खराब हैं?
किसी भी स्कीमा को माइग्रेन का दर्द होता है।
सबसे बड़ा मुद्दा तकनीकी नहीं है।
यह शब्दार्थ है।
स्कीमा परिवर्तन का एक सिद्धांत कारण यह है कि पिछला स्कीमा समस्या डोमेन से बहुत अच्छी तरह मेल नहीं खाता है। चूंकि शब्दार्थ बदल गए हैं, डेटाबेस (और अनुप्रयोगों) को बदलने की आवश्यकता है। कभी-कभी ये गहन परिवर्तन होते हैं जिनके लिए डेटा के साथ एप्लिकेशन के काम करने के तरीके को पुनर्विचार करने की आवश्यकता होती है।
डेटाबेस के संशोधित शब्दार्थ बहुत कठिन हो सकते हैं।
स्कीमा परिवर्तनों के बजाय लोग क्या करते हैं, यह केवल भौतिक स्कीमा का दुरुपयोग है। वे गलत डेटा को मौजूदा क्षेत्रों में लोड करना शुरू कर देते हैं क्योंकि वे कर सकते हैं। एक "टिप्पणी" फ़ील्ड अचानक ग्राहक प्रबंधन जानकारी का एक महत्वपूर्ण टुकड़ा होने लगती है जिसके बाद "//" वास्तविक टिप्पणी के बाद होती है। यह डेटा "फ़ील्ड 1 - फ़ील्ड 2 // टिप्पणी" के टुकड़ों के लिए बढ़ता है। उपयोगकर्ताओं के पास एक स्प्रेडशीट है जो टिप्पणी क्षेत्र से इस अतिरिक्त डेटा को निकालता है क्योंकि "वास्तविक" एप्लिकेशन सॉफ़्टवेयर में इसे बदलने के लिए कड़ी मेहनत का एक स्कीमा था जिसे आईटी ने इसे बदलने से इनकार कर दिया था।
हम उत्पादन डेटाबेस को बिना किसी समस्या के तालिकाओं और (अशक्त) स्तंभों को अपग्रेड करते हैं। अनुप्रयोग के पिछले संस्करण उन्नत डेटाबेस के साथ ठीक काम करते हैं, वे सिर्फ नए सामान का संदर्भ नहीं देते हैं। हम तालिकाओं या स्तंभों को हटाने से बचते हैं, या बदलते हैं कि मौजूदा डेटा कैसे संग्रहीत किया जाता है, हालांकि जब यह आवश्यक होता है तो हम रूपांतरण लिपियों का निर्माण करते हैं। आपके डेटाबेस में एक घोषित प्रकार सुरक्षित स्कीमा है या नहीं, डेटा संरचना में परिवर्तन के लिए नई संरचना के साथ बातचीत करने के लिए डेटा रूपांतरण और एप्लिकेशन अपग्रेड की आवश्यकता होती है।
निर्भर करता है।
सबसे पहले, यदि आपके पास कई मशीनों को फैलाने वाला एक बहुत बड़ा डेटाबेस है, तो सब कुछ (सिर्फ डेटाबेस अपडेट नहीं) दर्द होने वाला है। (कोई फर्क नहीं पड़ता कि आपने समय से पहले कितनी योजना बनाई थी)।
दूसरा, डेटाबेस को अपडेट करना सिर्फ एक डेटाबेस की बात नहीं है - यह उस बड़ी प्रणाली पर भी निर्भर करता है जिसमें DB हिस्सा है। इसमें डेटाबेस परिनियोजन (कई डेटाबेस सर्वर, कई डेटा-सेंटर, मास्टर-स्लेव सेटअप आदि) भी शामिल हैं।
दर्द को सिस्टम घटकों को आर्किटेक्चर द्वारा कम किया जा सकता है, जैसे कि वे सभी डीबी स्कीमा परिवर्तन घटना के 'संज्ञान' के कुछ प्रकार हैं। इसका मतलब यह है कि पूरे सिस्टम को स्कीमा परिवर्तनों के प्रति सहिष्णु होना चाहिए और इसका जवाब 'साने' तरीके से दिया जा सकता है।
आप MySQL स्कीमा अपडेट से निपटने के लिए फेसबुक द्वारा विकसित एक उपयोगिता की जांच कर सकते हैं ।
इसके अलावा, मानक सर्वोत्तम प्रथाएं हैं जैसे कि आप केवल पढ़ने के लिए मास्टर को बदलते हैं, गुलामों में बदलाव करते हैं या विकास की नकल करते हैं, आदि।
किसी भी मामले में, एक पूर्ण बैकअप और व्यापक परीक्षण सूट होना जरूरी है। तभी, आप किसी भी परिवर्तन को आत्मविश्वास और सुरक्षित रूप से कर सकते हैं।