३.१. कमकुवत ACID गुणधर्म
बर्याच काळापासून, डेटा सुसंगतता आर्किटेक्ट आणि विकासकांसाठी एक पवित्र गाय आहे. सर्व रिलेशनल डेटाबेसने काही प्रमाणात अलगाव प्रदान केला, एकतर अपडेट लॉक आणि ब्लॉकिंग रीड्सद्वारे किंवा पूर्ववत लॉगद्वारे. प्रचंड प्रमाणात माहिती आणि वितरण प्रणालीच्या आगमनाने, हे स्पष्ट झाले की त्यांच्यासाठी एकीकडे व्यवहाराचा संच सुनिश्चित करणे आणि दुसरीकडे उच्च उपलब्धता आणि जलद प्रतिसाद वेळ मिळविणे अशक्य आहे.
शिवाय, एक रेकॉर्ड अद्यतनित केल्याने देखील इतर कोणत्याही वापरकर्त्यास सिस्टममधील बदल त्वरित दिसतील याची हमी देत नाही, कारण बदल होऊ शकतो, उदाहरणार्थ, मास्टर नोडमध्ये, आणि प्रतिकृती अतुल्यकालिकपणे स्लेव्ह नोडवर कॉपी केली जाते, ज्यासह दुसरा वापरकर्ता कार्य करते या प्रकरणात, त्याला ठराविक कालावधीनंतर निकाल दिसेल. याला अंतिम सुसंगतता म्हणतात आणि फेसबुक आणि अॅमेझॉनसह जगातील सर्व मोठ्या इंटरनेट कंपन्या आता हेच करणार आहेत. नंतरचे अभिमानाने घोषित करतात की जास्तीत जास्त मध्यांतर ज्या दरम्यान वापरकर्ता विसंगत डेटा पाहू शकतो तो एका सेकंदापेक्षा जास्त नाही. अशा परिस्थितीचे उदाहरण आकृतीमध्ये दर्शविले आहे:
अशा परिस्थितीत उद्भवणारा तार्किक प्रश्न असा आहे की अशा प्रणालींचे काय करावे जे ऑपरेशन्सच्या अणु-सुसंगततेवर उच्च मागणी करतात आणि त्याच वेळी जलद वितरित क्लस्टर्सची आवश्यकता असते - आर्थिक, ऑनलाइन स्टोअर्स इ.? सराव दर्शवितो की या आवश्यकता यापुढे संबंधित नाहीत: आर्थिक बँकिंग प्रणालीच्या एका डिझायनरने असे म्हटले आहे: “जर आम्ही एटीएम (एटीएम) च्या जागतिक नेटवर्कमधील प्रत्येक व्यवहार पूर्ण होण्याची खरोखरच वाट पाहिली, तर व्यवहारांना इतका वेळ लागेल की ग्राहकांना रागाने पळून जायचे. तुम्ही आणि तुमच्या जोडीदाराने एकाच वेळी पैसे काढले आणि मर्यादा ओलांडली तर काय होईल? "तुम्हा दोघांना पैसे मिळतील आणि आम्ही ते नंतर दुरुस्त करू."
दुसरे उदाहरण चित्रात दाखवलेले हॉटेल बुकिंग आहे. ऑनलाइन स्टोअर्स ज्यांचे डेटा धोरण अंतिम सुसंगतता गृहीत धरते त्यांना अशा परिस्थितीत (स्वयंचलित संघर्ष निराकरण, ऑपरेशन रोलबॅक, इतर डेटासह अद्यतन) उपाय प्रदान करणे आवश्यक आहे. व्यवहारात, हॉटेल्स आपत्कालीन परिस्थितीत नेहमी मोकळ्या खोल्यांचा “पूल” ठेवण्याचा प्रयत्न करतात आणि हे विवादास्पद परिस्थितीवर उपाय ठरू शकते.
खरं तर, कमकुवत ACID गुणधर्मांचा अर्थ असा नाही की ते अस्तित्वात नाहीत. बहुतेक प्रकरणांमध्ये, रिलेशनल डेटाबेससह कार्य करणारे ऍप्लिकेशन तार्किकदृष्ट्या संबंधित वस्तू (ऑर्डर - ऑर्डर आयटम) बदलण्यासाठी व्यवहाराचा वापर करते, जे आवश्यक असते, कारण ही भिन्न सारणी आहेत. NoSQL डेटाबेसमधील डेटा मॉडेलच्या योग्य डिझाईनसह (ऑर्डर आयटमच्या सूचीसह एक ऑर्डर आहे), रिलेशनल डेटाबेस प्रमाणे एक रेकॉर्ड बदलताना तुम्ही समान पातळीचे अलगाव साध्य करू शकता.
३.२. वितरित प्रणाली, कोणतीही सामायिक संसाधने नाहीत (काहीही सामायिक करू नका)
पुन्हा, हे डेटाबेस आलेखांवर लागू होत नाही, ज्याची रचना, व्याख्येनुसार, रिमोट नोड्समध्ये चांगली पसरत नाही.
हे कदाचित NoSQL डेटाबेसच्या विकासाचे मुख्य लेटमोटिफ आहे. जगातील माहितीच्या हिमस्खलनाच्या वाढीसह आणि वाजवी वेळेत त्यावर प्रक्रिया करण्याची गरज असल्याने, उभ्या स्केलेबिलिटीची समस्या उद्भवली - प्रोसेसर गतीची वाढ 3.5 GHz वर थांबली, डिस्कमधून वाचण्याची गती देखील वेगाने वाढत आहे. मंद गती, तसेच शक्तिशाली सर्व्हरची किंमत अनेक साध्या सर्व्हरच्या एकूण किंमतीपेक्षा नेहमीच जास्त असते. या परिस्थितीत, पारंपारिक रिलेशनल डेटाबेस, अगदी डिस्कच्या अॅरेवर क्लस्टर केलेले, वेग, स्केलेबिलिटी आणि थ्रूपुटच्या समस्येचे निराकरण करण्यास सक्षम नाहीत.
परिस्थितीतून बाहेर पडण्याचा एकमेव मार्ग म्हणजे क्षैतिज स्केलिंग, जेव्हा अनेक स्वतंत्र सर्व्हर एका वेगवान नेटवर्कद्वारे कनेक्ट केलेले असतात आणि प्रत्येकाकडे डेटाचा फक्त काही भाग असतो आणि / किंवा वाचन-अद्यतन विनंत्यांचा फक्त एक भाग असतो. या आर्किटेक्चरमध्ये, स्टोरेज क्षमता (क्षमता, प्रतिसाद वेळ, थ्रूपुट) वाढवण्यासाठी, तुम्हाला फक्त क्लस्टरमध्ये एक नवीन सर्व्हर जोडण्याची आवश्यकता आहे - आणि तेच. शार्डिंग, प्रतिकृती, दोष सहिष्णुता (एक किंवा अधिक सर्व्हरने प्रतिसाद देणे थांबवले तरीही परिणाम प्राप्त होईल), नोड जोडण्याच्या बाबतीत डेटा पुनर्वितरण NoSQL डेटाबेसद्वारेच हाताळले जाते.
मी वितरित NoSQL डेटाबेसचे मुख्य गुणधर्म थोडक्यात सादर करेन:
प्रतिकृती - अद्यतनित करताना इतर नोड्समध्ये डेटा कॉपी करणे. दोन्हींना अधिक स्केलेबिलिटी प्राप्त करण्यास आणि डेटाची उपलब्धता आणि सुरक्षितता वाढविण्यास अनुमती देते. दोन प्रकारांमध्ये उपविभाजित करण्याची प्रथा आहे:
मास्टर-स्लेव्ह :
आणि पीअर-टू-पीअर : 
पहिला प्रकार वाचनासाठी चांगली स्केलेबिलिटी गृहीत धरतो (कोणत्याही नोडवरून होऊ शकतो), परंतु नॉन-स्केलेबल लेखन (केवळ मास्टर नोडसाठी). सतत उपलब्धता सुनिश्चित करण्यासाठी सूक्ष्मता देखील आहेत (मास्टर क्रॅश झाल्यास, मॅन्युअली किंवा स्वयंचलितपणे उर्वरित नोड्सपैकी एक त्याच्या जागी नियुक्त केला जातो). दुस-या प्रकारची प्रतिकृती असे गृहीत धरते की सर्व नोड समान आहेत आणि ते दोन्ही वाचन आणि लेखन विनंत्या देऊ शकतात.
शार्डिंग म्हणजे नोड्सद्वारे डेटाचे विभाजन:
स्पीड आणि थ्रूपुट वाढवण्यासाठी रिलेशनल डेटाबेससाठी शार्डिंगचा वापर अनेकदा "क्रच" म्हणून केला जातो: वापरकर्ता अनुप्रयोगाने अनेक स्वतंत्र डेटाबेसमध्ये डेटा विभाजित केला आणि जेव्हा वापरकर्त्याने संबंधित डेटाची विनंती केली तेव्हा विशिष्ट डेटाबेसमध्ये प्रवेश केला . NoSQL डेटाबेसमध्ये, प्रतिकृतीप्रमाणे शार्डिंग, डेटाबेसद्वारेच आपोआप केले जाते आणि वापरकर्ता अनुप्रयोग या जटिल यंत्रणेपासून वेगळा असतो.
३.३. NoSQL डेटाबेस हे मुख्यतः मुक्त स्त्रोत आहेत आणि 21 व्या शतकात तयार केले गेले आहेत
दुसर्‍या आधारावर सदलज आणि फॉलरने ऑब्जेक्ट डेटाबेसेसचे NoSQL म्हणून वर्गीकरण केले नाही (जरी http://nosql-database.org/ सामान्य यादीमध्ये त्यांचा समावेश आहे), कारण ते 90 च्या दशकात तयार केले गेले होते आणि त्यांना कधीही जास्त लोकप्रियता मिळाली नाही. .
NoSQL चळवळ प्रचंड वेगाने लोकप्रिय होत आहे. तथापि, याचा अर्थ असा नाही की रिलेशनल डेटाबेस वेस्टिजिअल किंवा काहीतरी पुरातन होत आहेत. बहुधा ते पूर्वीप्रमाणेच सक्रियपणे वापरले आणि वापरले जातील, परंतु अधिकाधिक NoSQL डेटाबेस त्यांच्यासह सहजीवनात कार्य करतील. आम्ही पॉलीग्लॉट पर्सिस्टन्सच्या युगात प्रवेश करत आहोत, एक युग जिथे वेगवेगळ्या गरजांसाठी वेगवेगळे डेटा स्टोअर वापरले जातात. आता डेटाचा निर्विवाद स्रोत म्हणून रिलेशनल डेटाबेसची मक्तेदारी नाही. वाढत्या प्रमाणात, वास्तुविशारद स्वतः डेटाच्या स्वरूपावर आधारित स्टोरेज निवडतात आणि आम्ही ते कसे हाताळू इच्छितो, किती प्रमाणात माहिती अपेक्षित आहे. आणि म्हणून सर्वकाही अधिक मनोरंजक होते.
खाली आम्ही उदाहरण म्हणून NoSQL Cassandra DBMS वापरून वितरित डेटाबेसचे ऑपरेशन समजून घेण्याचा प्रयत्न करू ...