क्या रिलेशनल डेटाबेस बर्बाद होते हैं?

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

हाल ही में, कई गैर-संबंधपरक डेटाबेस दिखाई दिए हैं। यह बताता है कि यदि आपको मांग पर लगभग असीमित स्केलेबिलिटी की आवश्यकता है, तो आपको एक गैर-संबंधपरक डेटाबेस की आवश्यकता है।



यदि यह सच है, तो क्या इसका मतलब यह है कि शक्तिशाली संबंधपरक डेटाबेस कमजोर हो गए हैं? क्या इसका मतलब यह है कि संबंधपरक डेटाबेस के दिन बीत जाते हैं और जल्द ही पूरी तरह से गुजर जाएंगे? इस लेख में, हम विभिन्न स्थितियों के संबंध में गैर-संबंधपरक डेटाबेस की लोकप्रिय प्रवृत्ति पर विचार करेंगे और देखेंगे कि क्या यह संबंधपरक डेटाबेस के भविष्य को प्रभावित करेगा।



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

आइए बुनियादी बातों से शुरू करें

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







रिलेशनल डेटाबेस तक पहुँच रिलेशनल डेटाबेस मैनेजमेंट सिस्टम (RDBMS) के माध्यम से है। लगभग हमारे द्वारा उपयोग किए जाने वाले लगभग सभी डेटाबेस सिस्टम रिलेशनल हैं, जैसे कि Oracle, SQL Server, MySQL, Sybase, DB2, TeraData, और इसी तरह।



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



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

रिलेशनल डेटाबेस समस्याएँ

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



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



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



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



इन लाभों के साथ-साथ उनके लिए मौजूदा मांग ने नए डेटाबेस प्रबंधन प्रणालियों की एक लहर पैदा की है।

नई लहर

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



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

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



भंडारण सुविधाएँ

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

कोई शामिल नहीं

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







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

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



डेटा का उपयोग

संबंधपरक डेटाबेस	की-वैल्यू स्टोरेज
संरचित क्वेरी लैंग्वेज (SQL) का उपयोग करके डेटा बनाया, अपडेट, डिलीट और क्वेर किया जाता है।	API विधि कॉल का उपयोग करके डेटा बनाया, अपडेट, डिलीट और क्वेर किया जाता है।
SQL क्वेरी कनेक्शन (जॉइन) का उपयोग करते हुए एकल तालिका से या कई तालिकाओं से डेटा प्राप्त कर सकते हैं।	कुछ कार्यान्वयन फ़िल्टर शर्तों को सेट करने के लिए SQL जैसी सिंटैक्स प्रदान करते हैं।
SQL क्वेरी में एकत्रीकरण और जटिल फ़िल्टर शामिल हो सकते हैं।	अक्सर, आप केवल मूल तुलना ऑपरेटरों (=; =; <,>, <= और =>) का उपयोग कर सकते हैं।
एक रिलेशनल डेटाबेस में आमतौर पर एम्बेडेड तर्क होते हैं, जैसे ट्रिगर, संग्रहीत कार्यविधियाँ, और फ़ंक्शन।	डेटा अखंडता का समर्थन करने के लिए सभी व्यावसायिक तर्क और तर्क आवेदन कोड में निहित हैं।

अनुप्रयोग सहभागिता

संबंधपरक डेटाबेस	की-वैल्यू स्टोरेज
अक्सर, देशी एपीआई का उपयोग किया जाता है, या सामान्यीकृत किया जाता है, जैसे कि OLE DB या ODBC।	अक्सर, डेटा तक पहुंचने के लिए SOAP और / या REST API का उपयोग किया जाता है।
डेटा को एक प्रारूप में संग्रहीत किया जाता है जो उनकी प्राकृतिक संरचना को प्रदर्शित करता है, इसलिए अनुप्रयोग संरचनाओं और संबंधपरक डेटाबेस संरचनाओं का मानचित्रण आवश्यक है।	डेटा को एप्लिकेशन की संरचना में अधिक कुशलता से प्रदर्शित किया जा सकता है, वस्तुओं को डेटा लिखने के लिए केवल कोड की आवश्यकता होती है।

की-वैल्यू स्टोरेज: लाभ

रिलेशनल स्टोरेज पर इस तरह के सिस्टम के दो अलग-अलग फायदे हैं।

क्लाउड सेवाओं के लिए उपयुक्त है

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



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

अधिक प्राकृतिक कोड एकीकरण

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



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

की-वैल्यू स्टोरेज: नुकसान

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



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



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

सीमित डेटा विश्लेषण

आमतौर पर, सभी क्लाउड स्टोरेज को कई पट्टों के प्रकार पर बनाया जाता है, जिसका अर्थ है कि एक ही प्रणाली का उपयोग बड़ी संख्या में उपयोगकर्ताओं और अनुप्रयोगों द्वारा किया जाता है। समग्र प्रणाली के "कैप्चर" को रोकने के लिए, विक्रेता आमतौर पर अनुरोधों के निष्पादन को सीमित करते हैं। उदाहरण के लिए, SimpleDB में, एक क्वेरी 5 सेकंड से अधिक समय तक नहीं चल सकती है। Google AppEngine Datastore में, आप एक अनुरोध ³ में 1000 से अधिक रिकॉर्ड प्राप्त नहीं कर सकते।



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



इस मामले में, एनालिटिक्स के लिए एक अलग डेटाबेस बनाना बेहतर होता है जो आपके की-वैल्यू स्टोरेज के डेटा से पॉपुलेट होगा। अग्रिम में सोचें कि यह कैसे किया जा सकता है। क्या आप सर्वर को क्लाउड या घर पर होस्ट करेंगे? क्या आपके और आपके प्रदाता के बीच सिग्नल देरी के कारण समस्याएं होंगी? क्या आपका स्टोरेज ऐसे डेटा ट्रांसफर का समर्थन करता है? यदि आपके पास 100 मिलियन रिकॉर्ड हैं और आप एक बार में 1,000 रिकॉर्ड ले सकते हैं, तो सभी डेटा को स्थानांतरित करने में कितना समय लगेगा?



हालांकि, स्केलेबिलिटी को प्राथमिकता न दें। यदि आपके उपयोगकर्ता किसी अन्य सेवा की सेवाओं का उपयोग करने का निर्णय लेते हैं, तो यह बेकार हो जाएगा, क्योंकि यह अधिक विकल्प और सेटिंग्स प्रदान करता है।

क्लाउड स्टोरेज

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

अमेज़ॅन: सिंपलडीबी

SimpleDB एक विशेषता-आधारित की-वैल्यू स्टोरेज है जो Amazon WebServices का हिस्सा है। सिंपलबीडी बीटा में है; उपयोगकर्ता इसे मुफ्त में उपयोग कर सकते हैं - जब तक कि उनकी आवश्यकता एक निश्चित सीमा से अधिक न हो।



SimpleDB की कई सीमाएँ हैं। सबसे पहले, क्वेरी निष्पादन समय 5 सेकंड तक सीमित है। दूसरा, तार के अलावा कोई डेटा प्रकार नहीं हैं। सब कुछ संग्रहीत, पुनर्प्राप्त और एक स्ट्रिंग के रूप में तुलना की जाती है, इसलिए तिथियों की तुलना करने के लिए, आपको उन्हें ISO8601 प्रारूप में बदलने की आवश्यकता होगी। तीसरा, किसी भी पंक्ति का अधिकतम आकार 1024 बाइट्स है, जो पाठ के आकार (उदाहरण के लिए, उत्पाद का विवरण) को सीमित करता है, जिसे आप एक विशेषता के रूप में संग्रहीत कर सकते हैं। हालाँकि, चूंकि डेटा संरचना लचीली है, इसलिए आप "उत्पाद विवरण 1", "उत्पाद विवरण", इत्यादि विशेषताओं को जोड़कर इस सीमा को दरकिनार कर सकते हैं। लेकिन विशेषताओं की संख्या भी सीमित है - अधिकतम 256 विशेषताएँ। हालाँकि साधारण सी डी बी बीटा में है, डोमेन का आकार 10 गीगाबाइट तक सीमित है, और पूरा डेटाबेस 1 टेराबाइट से अधिक नहीं ले सकता है।



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

Google AppEngine Data Store

Google का AppEngine Datastore BigTable, Google की आंतरिक संरचित डेटा संग्रहण प्रणाली के शीर्ष पर बनाया गया है। AppEngine Datastore BigTable के लिए सीधी पहुँच प्रदान नहीं करता है, लेकिन BigTable के साथ बातचीत के लिए एक सरलीकृत इंटरफ़ेस के रूप में माना जा सकता है।



AppEngine Datastore SimpleDB की तुलना में एकल रिकॉर्ड के भीतर बड़ी संख्या में डेटा प्रकारों का समर्थन करता है। उदाहरण के लिए, सूचियाँ जिनमें एक रिकॉर्ड के भीतर संग्रह हो सकता है।



सबसे अधिक संभावना है कि आप Google AppEngine का उपयोग करते समय इस विशेष डेटा वेयरहाउस का उपयोग करेंगे। हालाँकि, SimpleDB के विपरीत, आप Google की वेब सेवाओं के बाहर AppEngine Datastore (या BigTable) का उपयोग नहीं कर सकते।

Microsoft: SQL डेटा सेवाएँ

SQL डेटा सेवाएँ Microsoft Azure प्लेटफ़ॉर्म का हिस्सा है। SQL डेटा सेवाएँ बीटा में मुफ़्त है, और इसमें डेटाबेस आकार की सीमाएँ हैं। SQL डेटा सेवाएँ एक अलग अनुप्रयोग है - डेटा को संग्रहीत करने वाले कई SQL सर्वर के लिए एक ऐड-ऑन। ये भंडारण प्रासंगिक हो सकते हैं, हालांकि आपके लिए एसडीएस एक महत्वपूर्ण मूल्य भंडारण है, साथ ही ऊपर वर्णित उत्पाद भी हैं।

क्लाउड स्टोरेज

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

CouchDB

CouchDB एक स्वतंत्र, खुला स्रोत, दस्तावेज़-उन्मुख डेटाबेस है। डेटा भंडारण प्रारूप के रूप में, JSON का उपयोग किया जाता है। CouchDB "विचारों" का उपयोग करके दस्तावेज़-उन्मुख और संबंधपरक डेटाबेस के बीच की खाई को भरने के लिए डिज़ाइन किया गया है। इस तरह के विचारों में दस्तावेज़ से तालिका के समान प्रपत्र में डेटा होता है, और आपको अनुक्रमणिका बनाने और क्वेरी करने की अनुमति देता है।



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

वोल्डेमॉर्ट प्रोजेक्ट

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

मोंगो

मोंगो एक डेटाबेस है जो गेनेर मैग्यूसन और ड्वाइट मेरिमैन (जिसे आप डबलक्लिक से जान सकते हैं) द्वारा 10gen पर विकसित किया गया है। CouchDB की तरह, Mongo एक दस्तावेज़-उन्मुख डेटाबेस है जो JSON प्रारूप में डेटा संग्रहीत करता है। हालांकि, मानगो एक शुद्ध कुंजी-मूल्य भंडारण की तुलना में एक वस्तु आधार अधिक होने की संभावना है।

बूंदा बांदी

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

निर्णय

अंत में, आपके आवेदन के लिए गैर-संबंधपरक कुंजी-मूल्य संग्रहण चुनने के चार कारण हैं:

1. आपका डेटा अत्यधिक दस्तावेज़-उन्मुख है, और संबंधपरक मॉडल की तुलना में कुंजी-मूल्य डेटा मॉडल के लिए अधिक उपयुक्त है।
2. आपका डोमेन मॉडल अत्यधिक ऑब्जेक्ट-ओरिएंटेड है, इसलिए की-वैल्यू स्टोरेज का उपयोग करने से डेटा रूपांतरण के लिए अतिरिक्त कोड का आकार कम हो जाएगा।
3. डेटा वेयरहाउस आपके विक्रेता की वेब सेवाओं के साथ सस्ते और आसानी से एकीकृत होता है।
4. आपकी मुख्य चिंता मांग पर उच्च मापनीयता है।

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



अन्य सभी आवश्यकताओं के लिए, अच्छे पुराने संबंधपरक डीबीएमएस को चुनना बेहतर है। तो क्या वे बर्बाद हैं? बिल्कुल नहीं। कम से कम अभी तक नहीं।

---

¹ - मेरी राय में, "डेटा संरचना" शब्द यहाँ अधिक उपयुक्त है, लेकिन मूल डेटा मॉडल को छोड़ दिया है।

² - सबसे अधिक संभावना है, लेखक के दिमाग में था कि गैर-संबंधपरक डेटाबेस अपनी क्षमताओं में संबंधपरक लोगों से नीच हैं।

³ - शायद डेटा पहले से ही पुराना है, लेख फरवरी 2009 से तारीख करता है।