3.1। कमजोर एसिड गुण
लंबे समय से, आर्किटेक्ट और डेवलपर्स के लिए डेटा स्थिरता एक पवित्र गाय रही है। सभी संबंधपरक डेटाबेसों ने कुछ स्तर का अलगाव प्रदान किया, या तो अपडेट लॉक और ब्लॉकिंग रीड्स के माध्यम से, या पूर्ववत लॉग के माध्यम से। बड़ी मात्रा में सूचनाओं और वितरित प्रणालियों के आगमन के साथ, यह स्पष्ट हो गया कि एक ओर उनके लिए संचालन का एक लेन-देन सेट सुनिश्चित करना और दूसरी ओर उच्च उपलब्धता और तेज़ प्रतिक्रिया समय प्राप्त करना असंभव था।
इसके अलावा, यहां तक कि एक रिकॉर्ड को अपडेट करने की गारंटी नहीं है कि कोई अन्य उपयोगकर्ता तुरंत सिस्टम में परिवर्तन देखेगा, क्योंकि परिवर्तन हो सकता है, उदाहरण के लिए, मास्टर नोड में, और प्रतिकृति एसिंक्रोनस रूप से दास नोड में कॉपी की जाती है, जिसके साथ अन्य उपयोगकर्ता काम करता है। इस मामले में, वह एक निश्चित अवधि के बाद परिणाम देखेंगे। इसे अंतिम स्थिरता कहा जाता है और यही अब दुनिया की सभी सबसे बड़ी इंटरनेट कंपनियां करने जा रही हैं, जिसमें फेसबुक और अमेज़ॅन भी शामिल हैं। उत्तरार्द्ध गर्व से घोषित करता है कि अधिकतम अंतराल जिसके दौरान उपयोगकर्ता असंगत डेटा देख सकता है, एक सेकंड से अधिक नहीं है। ऐसी स्थिति का एक उदाहरण चित्र में दिखाया गया है:
ऐसी स्थिति में जो तार्किक प्रश्न उठता है, वह यह है कि उन प्रणालियों के साथ क्या किया जाए जो शास्त्रीय रूप से संचालन की परमाणुता-स्थिरता पर उच्च माँग रखती हैं और साथ ही साथ तेजी से वितरित समूहों - वित्तीय, ऑनलाइन स्टोर आदि की आवश्यकता होती है? अभ्यास से पता चलता है कि ये आवश्यकताएं अब प्रासंगिक नहीं हैं: यहां वित्तीय बैंकिंग प्रणाली के एक डिजाइनर ने कहा है: "यदि हम वास्तव में एटीएम (एटीएम) के वैश्विक नेटवर्क में प्रत्येक लेनदेन के पूरा होने की प्रतीक्षा करते हैं, तो लेनदेन में इतना समय लगेगा कि ग्राहक गुस्से में भाग जाएगा। यदि आप और आपका साथी एक ही समय में पैसे निकालते हैं और सीमा से अधिक हो जाते हैं तो क्या होता है? "आप दोनों को पैसा मिल जाएगा, और हम इसे बाद में ठीक कर देंगे।"
एक अन्य उदाहरण चित्र में दिखाई गई होटल बुकिंग है। ऑनलाइन स्टोर जिनकी डेटा नीति अंतिम स्थिरता मानती है, उन्हें ऐसी स्थितियों (स्वचालित संघर्ष समाधान, ऑपरेशन रोलबैक, अन्य डेटा के साथ अपडेट) के मामले में उपाय प्रदान करने की आवश्यकता होती है। व्यवहार में, होटल हमेशा आपात स्थिति में मुफ्त कमरों का "पूल" रखने की कोशिश करते हैं, और यह एक विवादास्पद स्थिति का समाधान हो सकता है।
वास्तव में, कमजोर एसीआईडी गुणों का मतलब यह नहीं है कि वे मौजूद नहीं हैं। ज्यादातर मामलों में, रिलेशनल डेटाबेस के साथ काम करने वाला एक एप्लिकेशन तार्किक रूप से संबंधित वस्तुओं (ऑर्डर - ऑर्डर आइटम) को बदलने के लिए लेनदेन का उपयोग करता है, जो कि आवश्यक है, क्योंकि ये अलग-अलग टेबल हैं। NoSQL डेटाबेस में डेटा मॉडल के सही डिज़ाइन के साथ (कुल ऑर्डर आइटम की सूची के साथ एक ऑर्डर है), आप रिलेशनल डेटाबेस के रूप में एकल रिकॉर्ड को बदलते समय अलगाव के समान स्तर को प्राप्त कर सकते हैं।
3.2। वितरित सिस्टम, कोई साझा संसाधन नहीं (कुछ भी साझा नहीं करें)
दोबारा, यह डेटाबेस ग्राफ़ पर लागू नहीं होता है, जिसकी संरचना, परिभाषा के अनुसार, दूरस्थ नोड्स में अच्छी तरह फैलती नहीं है।
यह शायद NoSQL डेटाबेस के विकास का मुख्य मूलमंत्र है। दुनिया में सूचना की हिमस्खलन वृद्धि और इसे उचित समय में संसाधित करने की आवश्यकता के साथ, ऊर्ध्वाधर मापनीयता की समस्या उत्पन्न हुई - प्रोसेसर की गति 3.5 गीगाहर्ट्ज़ पर रुक गई, डिस्क से पढ़ने की गति भी बढ़ रही है धीमी गति, साथ ही एक शक्तिशाली सर्वर की कीमत हमेशा कई सरल सर्वरों की कुल कीमत से अधिक होती है। इस स्थिति में, पारंपरिक रिलेशनल डेटाबेस, यहां तक कि डिस्क की एक सरणी पर क्लस्टर किए गए, गति, मापनीयता और थ्रूपुट की समस्या को हल करने में सक्षम नहीं हैं।
स्थिति से बाहर निकलने का एकमात्र तरीका क्षैतिज स्केलिंग है, जब कई स्वतंत्र सर्वर एक तेज़ नेटवर्क से जुड़े होते हैं और प्रत्येक डेटा का केवल एक हिस्सा और / या रीड-अपडेट अनुरोधों का केवल एक हिस्सा होता है। इस वास्तुकला में, भंडारण क्षमता (क्षमता, प्रतिक्रिया समय, थ्रूपुट) बढ़ाने के लिए, आपको केवल क्लस्टर में एक नया सर्वर जोड़ने की आवश्यकता है - और बस इतना ही। साझाकरण, प्रतिकृति, दोष सहिष्णुता (परिणाम तब भी प्राप्त किया जाएगा जब एक या अधिक सर्वर प्रतिक्रिया देना बंद कर दें), नोड जोड़ने के मामले में डेटा पुनर्वितरण को NoSQL डेटाबेस द्वारा ही नियंत्रित किया जाता है।
मैं वितरित NoSQL डेटाबेस के मुख्य गुणों को संक्षेप में प्रस्तुत करूँगा:
प्रतिकृति - अद्यतन करते समय डेटा को अन्य नोड्स में कॉपी करना। दोनों को अधिक मापनीयता प्राप्त करने और डेटा की उपलब्धता और सुरक्षा बढ़ाने की अनुमति देता है। यह दो प्रकारों में उप-विभाजित करने की प्रथा है:
मास्टर-स्लेव :
और पीयर-टू-पीयर : 
पहला प्रकार पढ़ने के लिए अच्छी मापनीयता मानता है (किसी भी नोड से हो सकता है), लेकिन गैर-स्केलेबल लेखन (केवल मास्टर नोड के लिए)। निरंतर उपलब्धता सुनिश्चित करने के साथ सूक्ष्मताएं भी हैं (मास्टर क्रैश की स्थिति में, या तो मैन्युअल रूप से या स्वचालित रूप से शेष नोड्स में से एक को इसके स्थान पर सौंपा गया है)। दूसरे प्रकार की प्रतिकृति मानती है कि सभी नोड समान हैं और पढ़ने और लिखने दोनों अनुरोधों को पूरा कर सकते हैं।
शेयरिंग नोड्स द्वारा डेटा का विभाजन है:
गति और थ्रूपुट को बढ़ाने के लिए शेयरिंग को अक्सर रिलेशनल डेटाबेस के लिए "बैसाखी" के रूप में उपयोग किया जाता था: उपयोगकर्ता एप्लिकेशन ने डेटा को कई स्वतंत्र डेटाबेस में विभाजित किया और, जब उपयोगकर्ता ने संबंधित डेटा का अनुरोध किया, तो एक विशिष्ट डेटाबेस तक पहुँचा। NoSQL डेटाबेस में, शार्डिंग, प्रतिकृति की तरह, स्वचालित रूप से डेटाबेस द्वारा ही किया जाता है और उपयोगकर्ता अनुप्रयोग इन जटिल तंत्रों से अलग होता है।
3.3। NoSQL डेटाबेस ज्यादातर ओपन सोर्स हैं और 21वीं सदी में बनाए गए हैं
यह दूसरे आधार पर है कि सदालज और फाउलर ने ऑब्जेक्ट डेटाबेस को NoSQL के रूप में वर्गीकृत नहीं किया (हालाँकि http://nosql-database.org/ उन्हें सामान्य सूची में शामिल करता है), क्योंकि वे 90 के दशक में बनाए गए थे और उन्हें कभी अधिक लोकप्रियता नहीं मिली ...
NoSQL आंदोलन एक विशाल गति से लोकप्रियता प्राप्त कर रहा है। हालाँकि, इसका मतलब यह नहीं है कि संबंधपरक डेटाबेस अवशेषी या कुछ पुरातन होते जा रहे हैं। सबसे अधिक संभावना है कि वे सक्रिय रूप से पहले की तरह उपयोग और उपयोग किए जाएंगे, लेकिन अधिक से अधिक NoSQL डेटाबेस उनके साथ सहजीवन में कार्य करेंगे। हम बहुभाषाविद दृढ़ता के युग में प्रवेश कर रहे हैं, एक ऐसा युग जहां विभिन्न आवश्यकताओं के लिए विभिन्न डेटा स्टोर का उपयोग किया जाता है। अब डेटा के निर्विरोध स्रोत के रूप में संबंधपरक डेटाबेस का कोई एकाधिकार नहीं है। तेजी से, आर्किटेक्ट डेटा की प्रकृति के आधार पर भंडारण का चयन करते हैं और हम इसे कैसे हेरफेर करना चाहते हैं, कितनी मात्रा में जानकारी अपेक्षित है। और इसलिए सब कुछ और दिलचस्प हो जाता है।
नीचे हम एक उदाहरण के रूप में NoSQL कैसेंड्रा DBMS का उपयोग करके वितरित डेटाबेस के संचालन को समझने की कोशिश करेंगे ...