🥇अधिक डेवलपर्स को डेटाबेस के बारे में यह जानना चाहिए

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

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

आप भाग्यशाली हैं यदि 99,999% समय नेटवर्क समस्याएँ पैदा नहीं कर रहा है।
ACID का अर्थ कई अलग-अलग चीजें हैं।
प्रत्येक डेटाबेस में स्थिरता और अलगाव सुनिश्चित करने के लिए अपने स्वयं के तंत्र होते हैं।
जब सामान्य अवरोध को बनाए रखना कठिन होता है तो आशावादी अवरोधन सहायता के लिए आता है।
गंदे पढ़ने और डेटा हानि के अलावा अन्य विसंगतियाँ भी हैं।
डेटाबेस और उपयोगकर्ता हमेशा कार्रवाई की दिशा में सहमत नहीं होते हैं।
एप्लिकेशन-स्तरीय शार्डिंग को एप्लिकेशन के बाहर ले जाया जा सकता है।
स्वतः वृद्धि खतरनाक हो सकती है।
पुराना डेटा उपयोगी हो सकता है और उसे लॉक करने की आवश्यकता नहीं है।
विकृतियाँ किसी भी समय स्रोत के लिए विशिष्ट हैं।
देरी के कई मायने हैं.
किसी विशिष्ट लेनदेन के लिए प्रदर्शन आवश्यकताओं का मूल्यांकन किया जाना चाहिए।
नेस्टेड लेन-देन खतरनाक हो सकता है.
लेन-देन को आवेदन स्थिति से नहीं जोड़ा जाना चाहिए।
क्वेरी प्लानर आपको डेटाबेस के बारे में बहुत कुछ बता सकते हैं।
ऑनलाइन माइग्रेशन कठिन है, लेकिन संभव है।
डेटाबेस में उल्लेखनीय वृद्धि से अप्रत्याशितता में वृद्धि होती है।

मैं इस लेख के पुराने संस्करण पर उनकी प्रतिक्रिया के लिए इमैनुएल ओडेके, रीन हेनरिक्स और अन्य को धन्यवाद देना चाहता हूं।

आप भाग्यशाली हैं यदि 99,999% समय नेटवर्क समस्याएँ पैदा नहीं कर रहा है।

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

स्पैनर (Google का विश्व स्तर पर वितरित डेटाबेस) के लिए 99,999% की उपलब्धता दर के साथ, Google का दावा है कि केवल 7,6% तक समस्याएँ नेटवर्क से संबंधित हैं. साथ ही, कंपनी अपने विशेष नेटवर्क को उच्च उपलब्धता का "मुख्य स्तंभ" कहती है। अध्ययन बेलीस और किंग्सबरी2014 में आयोजित, "में से एक को चुनौती देता है"वितरित कंप्यूटिंग के बारे में गलत धारणाएँ", जिसे पीटर ड्यूश ने 1994 में तैयार किया था। क्या नेटवर्क वास्तव में विश्वसनीय है?

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

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

ACID का अर्थ बहुत सी अलग-अलग चीजें हैं

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

जब मैंने पहली बार उद्योग में प्रवेश किया, तो हमारे तकनीकी नेतृत्व ने इस बारे में बात की कि ACID अवधारणा कितनी प्रासंगिक थी। निष्पक्ष होने के लिए, ACID को सख्त कार्यान्वयन मानक के बजाय एक मोटा विवरण माना जाता है। आज मुझे यह अधिकतर उपयोगी लगता है क्योंकि यह मुद्दों की एक विशिष्ट श्रेणी को उठाता है (और संभावित समाधानों की एक श्रृंखला का सुझाव देता है)।

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

इस बारे में बहस कि क्या MongoDB ACID आवश्यकताओं का अनुपालन करता है, संस्करण 4 के जारी होने के बाद भी जारी है। MongoDB को लंबे समय से समर्थन नहीं मिला है काटना, हालाँकि डिफ़ॉल्ट रूप से डेटा हर 60 सेकंड में एक बार से अधिक डिस्क पर नहीं भेजा जाता था। निम्नलिखित परिदृश्य की कल्पना करें: एक एप्लिकेशन दो राइट्स (w1 और w2) पोस्ट करता है। MongoDB सफलतापूर्वक w1 को संग्रहीत करता है, लेकिन हार्डवेयर विफलता के कारण w2 खो जाता है।

परिदृश्य को दर्शाने वाला आरेख. डिस्क पर डेटा लिखने से पहले MongoDB क्रैश हो जाता है

डिस्क से प्रतिबद्धता करना एक महंगी प्रक्रिया है। बार-बार प्रतिबद्धताओं से बचकर, डेवलपर्स विश्वसनीयता की कीमत पर रिकॉर्डिंग प्रदर्शन में सुधार करते हैं। MongoDB वर्तमान में लॉगिंग का समर्थन करता है, लेकिन गंदा लेखन अभी भी डेटा अखंडता को प्रभावित कर सकता है क्योंकि लॉग डिफ़ॉल्ट रूप से हर 100ms पर कैप्चर किए जाते हैं। यानी, लॉग और उनमें प्रस्तुत परिवर्तनों के लिए एक समान परिदृश्य अभी भी संभव है, हालांकि जोखिम बहुत कम है।

प्रत्येक डेटाबेस की अपनी स्थिरता और अलगाव तंत्र होते हैं

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

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

मौजूदा समवर्ती मॉडल और उनके बीच संबंधों की समीक्षा

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

SQL मानक निम्नलिखित अलगाव स्तरों का उल्लेख करता है:

serializable (सबसे कठोर और महंगा): क्रमबद्ध निष्पादन का कुछ अनुक्रमिक लेनदेन निष्पादन के समान प्रभाव होता है। अनुक्रमिक निष्पादन का अर्थ है कि प्रत्येक अगला लेनदेन पिछले लेनदेन के पूरा होने के बाद ही शुरू होता है। यह ध्यान दिया जाना चाहिए कि स्तर serializable व्याख्या में अंतर के कारण इसे अक्सर तथाकथित स्नैपशॉट अलगाव (उदाहरण के लिए, ओरेकल में) के रूप में लागू किया जाता है, हालांकि स्नैपशॉट अलगाव स्वयं SQL मानक में प्रस्तुत नहीं किया जाता है।
दोहराने योग्य पाठ: वर्तमान लेनदेन में अप्रतिबद्ध रिकॉर्ड वर्तमान लेनदेन के लिए उपलब्ध हैं, लेकिन अन्य लेनदेन द्वारा किए गए परिवर्तन (जैसे नई पंक्तियाँ) दिखाई नहीं देना.
प्रतिबद्ध पढ़ें: लेनदेन के लिए अप्रतिबद्ध डेटा उपलब्ध नहीं है। इस मामले में, लेनदेन केवल प्रतिबद्ध डेटा देख सकते हैं, और फैंटम रीड्स हो सकते हैं। यदि कोई लेन-देन नई पंक्तियाँ सम्मिलित और प्रतिबद्ध करता है, तो वर्तमान लेन-देन पूछे जाने पर उन्हें देख सकेगा।
बिना प्रतिबद्धता के पढ़ें (कम से कम सख्त और महंगा स्तर): गंदे पढ़ने की अनुमति है, लेन-देन में अन्य लेन-देन द्वारा किए गए अप्रतिबद्ध परिवर्तन देखे जा सकते हैं। व्यवहार में, यह स्तर प्रश्नों जैसे मोटे अनुमानों के लिए उपयोगी हो सकता है COUNT(*) मेज पर।

Уровень serializable यह डेटा रेस के जोखिम को कम करता है, जबकि इसे लागू करना सबसे महंगा है और इसके परिणामस्वरूप सिस्टम पर सबसे अधिक प्रतिस्पर्धी भार पड़ता है। अन्य अलगाव स्तरों को लागू करना आसान है, लेकिन डेटा दौड़ की संभावना बढ़ जाती है। कुछ DBMS आपको एक कस्टम आइसोलेशन स्तर सेट करने की अनुमति देते हैं, अन्य की प्राथमिकताएँ मजबूत होती हैं और सभी स्तर समर्थित नहीं होते हैं।

अलगाव स्तरों के लिए समर्थन को अक्सर किसी दिए गए डीबीएमएस में विज्ञापित किया जाता है, लेकिन केवल इसके व्यवहार का सावधानीपूर्वक अध्ययन ही बता सकता है कि वास्तव में क्या हो रहा है।

विभिन्न डीबीएमएस के लिए विभिन्न अलगाव स्तरों पर समवर्ती विसंगतियों की समीक्षा

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

जब सामान्य अवरोध को बनाए रखना कठिन होता है तो आशावादी अवरोधन सहायता के लिए आता है।

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

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

UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1

इस मामले में, तालिका अद्यतन कर रहा हूँ products यदि किसी अन्य ऑपरेशन ने पहले इस पंक्ति में परिवर्तन किया है तो इसे निष्पादित नहीं किया जाएगा। यदि इस पंक्ति पर कोई अन्य ऑपरेशन नहीं किया गया, तो एक पंक्ति के लिए परिवर्तन होगा और हम कह सकते हैं कि अद्यतन सफल रहा।

गंदे पढ़ने और डेटा हानि के अलावा अन्य विसंगतियाँ भी हैं

जब डेटा स्थिरता की बात आती है, तो ध्यान दौड़ की स्थितियों की संभावना पर होता है जो गंदे पढ़ने और डेटा हानि का कारण बन सकता है। हालाँकि, डेटा विसंगतियाँ यहीं नहीं रुकतीं।

ऐसी विसंगतियों का एक उदाहरण रिकॉर्डिंग विकृति है (तिरछा लिखें). विकृतियों का पता लगाना कठिन होता है क्योंकि आमतौर पर उनकी सक्रिय रूप से तलाश नहीं की जाती है। वे गंदे पढ़ने या डेटा हानि के कारण नहीं हैं, बल्कि डेटा पर लगाए गए तार्किक बाधाओं के उल्लंघन के कारण हैं।

उदाहरण के लिए, आइए एक निगरानी एप्लिकेशन पर विचार करें जिसके लिए हर समय एक ऑपरेटर को ऑन-कॉल की आवश्यकता होती है:

BEGIN tx1;                      BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0                               SELECT COUNT(*)
                                FROM operators
                                WHERE oncall = TRUE;
                                0
UPDATE operators                UPDATE operators
SET oncall = TRUE               SET oncall = TRUE
WHERE userId = 4;               WHERE userId = 2;
COMMIT tx1;                     COMMIT tx2;

उपरोक्त स्थिति में, यदि दोनों लेनदेन सफलतापूर्वक किए जाते हैं तो रिकॉर्ड भ्रष्टाचार घटित होगा। हालाँकि कोई गंदा रीड या डेटा हानि नहीं हुई थी, डेटा की अखंडता से समझौता किया गया था: अब एक ही समय में दो लोगों को ऑन-कॉल माना जाता है।

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

डेटाबेस और उपयोगकर्ता हमेशा इस बात पर सहमत नहीं होते कि क्या करना है

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

विकास के दौरान, विशेष रूप से गैर-अवरुद्ध पुस्तकालयों के साथ काम करते समय, खराब शैली और कम पठनीयता उपयोगकर्ताओं को यह विश्वास दिला सकती है कि लेनदेन क्रमिक रूप से निष्पादित होते हैं, जबकि वास्तव में वे किसी भी क्रम में डेटाबेस में आ सकते हैं।

पहली नज़र में, नीचे दिए गए प्रोग्राम में, T1 और T2 को क्रमिक रूप से कॉल किया जाता है, लेकिन यदि ये फ़ंक्शन गैर-अवरुद्ध हैं और तुरंत परिणाम को फॉर्म में लौटाते हैं वादा, तो कॉल का क्रम उन क्षणों द्वारा निर्धारित किया जाएगा जब उन्होंने डेटाबेस में प्रवेश किया था:

परिणाम1 = टी1() // वास्तविक परिणाम वादे हैं
परिणाम2 = टी2()

यदि परमाणुता की आवश्यकता है (अर्थात, या तो सभी ऑपरेशन पूरे होने चाहिए या निरस्त होने चाहिए) और अनुक्रम मायने रखता है, तो ऑपरेशन T1 और T2 को एक ही लेनदेन के भीतर निष्पादित किया जाना चाहिए।

एप्लिकेशन-स्तरीय शार्डिंग को एप्लिकेशन के बाहर ले जाया जा सकता है

शेयरिंग किसी डेटाबेस को क्षैतिज रूप से विभाजित करने की एक विधि है। कुछ डेटाबेस स्वचालित रूप से डेटा को क्षैतिज रूप से विभाजित कर सकते हैं, जबकि अन्य ऐसा नहीं कर सकते हैं, या इसमें बहुत अच्छे नहीं हैं। जब डेटा आर्किटेक्ट/डेवलपर्स यह अनुमान लगाने में सक्षम होते हैं कि डेटा कैसे एक्सेस किया जाएगा, तो वे इस कार्य को डेटाबेस को सौंपने के बजाय उपयोगकर्ता स्थान में क्षैतिज विभाजन बना सकते हैं। इस प्रक्रिया को "एप्लिकेशन-स्तरीय शार्डिंग" कहा जाता है (एप्लिकेशन-स्तरीय शार्डिंग).

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

आर्किटेक्चर का एक उदाहरण जिसमें एप्लिकेशन सर्वर को शार्डिंग सेवा से अलग किया जाता है

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

स्वतः वृद्धि खतरनाक हो सकती है

ऑटोइन्क्रीमेंट प्राथमिक कुंजी उत्पन्न करने का एक सामान्य तरीका है। अक्सर ऐसे मामले होते हैं जब डेटाबेस का उपयोग आईडी जनरेटर के रूप में किया जाता है, और डेटाबेस में पहचानकर्ता उत्पन्न करने के लिए डिज़ाइन की गई तालिकाएँ होती हैं। ऐसे कई कारण हैं जिनकी वजह से ऑटो-इंक्रीमेंटिंग का उपयोग करके प्राथमिक कुंजी बनाना आदर्श से बहुत दूर है:

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

किसी दृष्टिकोण पर निर्णय लेने से पहले, अनुक्रमण, विभाजन और शार्डिंग पर ऑटो-इंक्रीमेंटिंग आईडी और यूयूआईडी के प्रभाव पर विचार करें।

पुराना डेटा उपयोगी हो सकता है और उसे लॉक करने की आवश्यकता नहीं है

मल्टीवर्जन कंकरेंसी कंट्रोल (एमवीसीसी) कई स्थिरता आवश्यकताओं को लागू करता है जिनकी ऊपर संक्षेप में चर्चा की गई थी। कुछ डेटाबेस (उदाहरण के लिए, पोस्टग्रेज़, स्पैनर) स्नैपशॉट के साथ लेनदेन को "फ़ीड" करने के लिए एमवीसीसी का उपयोग करते हैं - डेटाबेस के पुराने संस्करण। निरंतरता सुनिश्चित करने के लिए स्नैपशॉट लेनदेन को क्रमबद्ध भी किया जा सकता है। पुराने स्नैपशॉट से पढ़ते समय, पुराना डेटा पढ़ा जाता है।

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

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

एप्लिकेशन सर्वर स्थानीय प्रतिकृति से 5 सेकंड पुराना डेटा पढ़ता है, भले ही नवीनतम संस्करण प्रशांत महासागर के दूसरी ओर उपलब्ध हो

DBMS स्वचालित रूप से पुराने संस्करणों को मिटा देते हैं और, कुछ मामलों में, आपको अनुरोध पर ऐसा करने की अनुमति देते हैं। उदाहरण के लिए, पोस्टग्रेज़ उपयोगकर्ताओं को ऐसा करने की अनुमति देता है VACUUM अनुरोध पर, और समय-समय पर यह ऑपरेशन स्वचालित रूप से भी करता है। एक घंटे से अधिक पुराने स्नैपशॉट से छुटकारा पाने के लिए स्पैनर एक कचरा संग्रहकर्ता चलाता है।

किसी भी समय स्रोत विरूपण के अधीन होते हैं

कंप्यूटर विज्ञान में सबसे गुप्त रहस्य यह है कि सभी टाइमिंग एपीआई झूठ बोलते हैं। दरअसल, हमारी मशीनों को सही वर्तमान समय का पता नहीं चलता। कंप्यूटर में क्वार्ट्ज क्रिस्टल होते हैं जो कंपन उत्पन्न करते हैं जिनका उपयोग समय रखने के लिए किया जाता है। हालाँकि, वे पर्याप्त सटीक नहीं हैं और सटीक समय से आगे/पीछे हो सकते हैं। शिफ्ट प्रति दिन 20 सेकंड तक पहुंच सकती है। इसलिए, हमारे कंप्यूटर पर समय को समय-समय पर नेटवर्क के साथ सिंक्रनाइज़ किया जाना चाहिए।

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

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

स्थिति इस तथ्य से बढ़ जाती है कि एप्लिकेशन और डेटाबेस अक्सर अलग-अलग मशीनों पर स्थित होते हैं (यदि अलग-अलग डेटा केंद्रों में नहीं)। इस प्रकार, समय न केवल विभिन्न मशीनों में वितरित डीबी नोड्स पर भिन्न होगा। यह एप्लिकेशन सर्वर पर भी भिन्न होगा.

Google TrueTime बिल्कुल अलग दृष्टिकोण अपनाता है। अधिकांश लोगों का मानना है कि इस दिशा में Google की प्रगति को परमाणु और जीपीएस घड़ियों में सामान्य परिवर्तन द्वारा समझाया गया है, लेकिन यह बड़ी तस्वीर का केवल एक हिस्सा है। यहां बताया गया है कि ट्रूटाइम कैसे काम करता है:

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

स्पैनर घटक ट्रूटाइम का उपयोग करते हैं, जहां TT.now() एक अंतराल लौटाता है, इसलिए स्पैनर बस उस बिंदु तक सोता है जहां यह आश्वस्त हो सकता है कि वर्तमान समय एक निश्चित बिंदु पार कर चुका है

वर्तमान समय निर्धारित करने में सटीकता कम होने का अर्थ है स्पैनर संचालन की अवधि में वृद्धि और प्रदर्शन में कमी। यही कारण है कि उच्चतम संभव सटीकता बनाए रखना महत्वपूर्ण है, भले ही पूरी तरह से सटीक घड़ी प्राप्त करना असंभव हो।

देरी के कई मायने हैं

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

किसी विशिष्ट लेनदेन के लिए प्रदर्शन आवश्यकताओं का मूल्यांकन किया जाना चाहिए

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

संबंधित तालिकाओं में निर्दिष्ट बाधाओं और पंक्ति पैडिंग के साथ तालिका X (50 मिलियन पंक्तियों के साथ) में एक नई पंक्ति सम्मिलित करते समय थ्रूपुट और विलंबता लिखें।
किसी निश्चित उपयोगकर्ता के मित्रों के मित्रों को प्रदर्शित करने में विलंब जब मित्रों की औसत संख्या 500 हो।
जब उपयोगकर्ता प्रति घंटे X प्रविष्टियों के साथ 100 अन्य उपयोगकर्ताओं का अनुसरण करता है, तो उपयोगकर्ता के इतिहास से शीर्ष 500 प्रविष्टियों को पुनर्प्राप्त करने में विलंबता।

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

प्रत्येक ऑपरेशन के लिए मेट्रिक्स एकत्र करते समय उच्च कार्डिनैलिटी से अवगत रहें। उच्च-शक्ति डिबगिंग डेटा प्राप्त करने के लिए लॉग, ईवेंट संग्रह, या वितरित ट्रेसिंग का उपयोग करें। लेख में "विलंबता को डीबग करना चाहते हैं?» आप विलंब डिबगिंग पद्धतियों से स्वयं को परिचित कर सकते हैं।

नेस्टेड लेन-देन खतरनाक हो सकता है

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

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

विभिन्न परतों में लेन-देन को एनकैप्सुलेट करने से अप्रत्याशित नेस्टेड लेन-देन हो सकता है, और कोड पठनीयता के दृष्टिकोण से, लेखक के इरादों को समझना मुश्किल हो सकता है। निम्नलिखित कार्यक्रम पर एक नज़र डालें:

with newTransaction():
   Accounts.create("609-543-222")
   with newTransaction():
       Accounts.create("775-988-322")
       throw Rollback();

उपरोक्त कोड का आउटपुट क्या होगा? क्या यह दोनों लेन-देन को वापस ले लेगा, या केवल आंतरिक लेन-देन को? यदि हम पुस्तकालयों की कई परतों पर भरोसा करते हैं जो हमारे लिए लेनदेन के निर्माण को समाहित करती हैं तो क्या होगा? क्या हम ऐसे मामलों की पहचान कर उनमें सुधार कर पाएंगे?

एकाधिक परिचालनों वाले एक डेटा स्तर की कल्पना करें (उदा. newAccount) पहले से ही अपने लेनदेन में लागू किया गया है। यदि आप उन्हें उच्च-स्तरीय व्यावसायिक तर्क के भाग के रूप में चलाते हैं जो अपने स्वयं के लेनदेन के भीतर चलता है तो क्या होता है? इस मामले में अलगाव और स्थिरता क्या होगी?

function newAccount(id string) {
  with newTransaction():
      Accounts.create(id)
}

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

function newAccount(id string) {
   Accounts.create(id)
}
// In main application:
with newTransaction():
   // Read some data from database for configuration.
   // Generate an ID from the ID service.
   Accounts.create(id)
   Uploads.create(id) // create upload queue for the user.

लेन-देन को आवेदन स्थिति से नहीं जोड़ा जाना चाहिए

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

var seq int64
with newTransaction():
    newSeq := atomic.Increment(&seq)
    Entries.query(newSeq)
    // Other operations...

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

क्वेरी प्लानर आपको डेटाबेस के बारे में बहुत कुछ बता सकते हैं

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

SELECT * FROM articles where author = "rakyll" order by title;

परिणाम दो तरीकों से प्राप्त किए जा सकते हैं:

पूर्ण तालिका स्कैन: आप तालिका में प्रत्येक प्रविष्टि को देख सकते हैं और मेल खाने वाले लेखक के नाम के साथ लेख लौटा सकते हैं, और फिर उन्हें ऑर्डर कर सकते हैं।
सूचकांक स्कैन: आप मिलान आईडी ढूंढने, उन पंक्तियों को प्राप्त करने और फिर उन्हें ऑर्डर करने के लिए एक इंडेक्स का उपयोग कर सकते हैं।

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

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

ऑनलाइन माइग्रेशन कठिन है लेकिन संभव है

ऑनलाइन माइग्रेशन, लाइव माइग्रेशन, या रीयल-टाइम माइग्रेशन का अर्थ है बिना डाउनटाइम या डेटा भ्रष्टाचार के एक डेटाबेस से दूसरे डेटाबेस में जाना। यदि संक्रमण एक ही डीबीएमएस/इंजन के भीतर होता है तो लाइव माइग्रेशन करना आसान होता है। स्थिति तब और अधिक जटिल हो जाती है जब विभिन्न प्रदर्शन और स्कीमा आवश्यकताओं के साथ नए DBMS में जाना आवश्यक हो जाता है।

विभिन्न ऑनलाइन माइग्रेशन मॉडल हैं. उनमें से एक यहां पर है:

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

अतिरिक्त जानकारी के लिए, मैं संपर्क करने की सलाह देता हूं लेख, जो इस मॉडल के आधार पर स्ट्राइप की प्रवासन रणनीति का विवरण देता है।

डेटाबेस में उल्लेखनीय वृद्धि से अप्रत्याशितता में वृद्धि होती है

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

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

...

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

पुनश्च

हमारे ब्लॉग पर भी पढ़ें:

स्रोत: www.habr.com

अधिक डेवलपर्स को डेटाबेस के बारे में यह जानना चाहिए