2.1 NoSQL या शब्दाचा उदय
अलीकडे, "NoSQL" हा शब्द अतिशय फॅशनेबल आणि लोकप्रिय झाला आहे, या चिन्हाखाली सर्व प्रकारचे सॉफ्टवेअर सोल्यूशन्स सक्रियपणे विकसित आणि प्रचारित केले जात आहेत. NoSQL प्रचंड प्रमाणात डेटा, रेखीय स्केलेबिलिटी, क्लस्टर्स, फॉल्ट टॉलरन्स, नॉन-रिलेशनॅलिटीचा समानार्थी बनला आहे. तथापि, काही लोकांना NoSQL स्टोरेज म्हणजे काय, हा शब्द कसा दिसला आणि त्यांच्यात कोणती सामान्य वैशिष्ट्ये आहेत याची स्पष्ट समज आहे. ही पोकळी भरून काढण्याचा प्रयत्न करूया.
या संज्ञेबद्दलची सर्वात मनोरंजक गोष्ट अशी आहे की 90 च्या दशकाच्या उत्तरार्धात याचा वापर केला गेला असला तरीही, 2009 च्या मध्यात ज्या स्वरूपात त्याचा वापर केला जातो त्याच स्वरूपात त्याचा खरा अर्थ प्राप्त झाला. सुरुवातीला, हे ओपनचे नाव होते. -स्रोत डेटाबेस कार्लो स्ट्रोझीने तयार केला, ज्याने सर्व डेटा ASCII फाइल्स म्हणून संग्रहित केला आणि डेटामध्ये प्रवेश करण्यासाठी SQL ऐवजी शेल स्क्रिप्टचा वापर केला. त्याचा सध्याच्या स्वरूपातील "NoSQL" शी काहीही संबंध नव्हता.
जून 2009 मध्ये जोहान ऑस्करसन यांनी सॅन फ्रान्सिस्कोमध्ये आयटी स्टोरेज आणि प्रोसेसिंग मार्केटमधील नवीन ट्रेंडवर चर्चा करण्यासाठी एक बैठक आयोजित केली. सभेची मुख्य प्रेरणा बिगटेबल आणि डायनॅमो सारखी नवीन मुक्त स्रोत उत्पादने होती. मीटिंगसाठी उज्ज्वल चिन्हासाठी, ट्विटर हॅशटॅगमध्ये पूर्णपणे बसेल असा एक विस्तृत आणि संक्षिप्त शब्द शोधणे आवश्यक होते. यापैकी एक अटी रॅकस्पेस - "NoSQL" मधील एरिक इव्हान्सने प्रस्तावित केली होती. हा शब्द केवळ एका बैठकीसाठी नियोजित होता आणि त्यात खोल अर्थपूर्ण भार नव्हता, परंतु असे घडले की ते व्हायरल जाहिरातीप्रमाणे संपूर्ण जागतिक नेटवर्कमध्ये पसरले आणि आयटी उद्योगातील संपूर्ण ट्रेंडचे वास्तविक नाव बनले. तसे, व्होल्डेमॉर्ट (अमेझॉन डायनॅमो क्लोन), कॅसॅंड्रा, एचबेस (गुगल बिगटेबलचे अॅनालॉग), हायपरटेबल, काउचडीबी, मोंगोडीबी परिषदेत बोलले.
"NoSQL" हा शब्द मूळ स्वरूपात पूर्णपणे उत्स्फूर्त आहे आणि त्यामागे सर्वसाधारणपणे स्वीकारलेली व्याख्या किंवा वैज्ञानिक संस्था नाही हे पुन्हा एकदा आवर्जून सांगण्यासारखे आहे. हे नाव रिलेशनल डेटाबेसपासून दूर असलेल्या आयटी विकासाच्या वेक्टरचे वैशिष्ट्य आहे. याचा अर्थ फक्त नॉट ओन्ली एसक्यूएल आहे, जरी नो एसक्यूएलच्या थेट व्याख्येचे समर्थक आहेत. प्रमोद सदलज आणि मार्टिन फॉलर यांनी त्यांच्या अलीकडील पुस्तक "NoSQL डिस्टिल्ड" मध्ये NoSQL जगाविषयीचे ज्ञान गटबद्ध आणि व्यवस्थित करण्याचा प्रयत्न केला.
2.2 NoSQL डेटाबेसची मूलभूत वैशिष्ट्ये
सर्व NoSQL साठी काही सामान्य वैशिष्ट्ये आहेत, कारण अनेक विषम प्रणाली आता NoSQL लेबलखाली लपलेल्या आहेत (कदाचित सर्वात संपूर्ण यादी http://nosql-database.org/ येथे आढळू शकते). अनेक वैशिष्ट्ये केवळ विशिष्ट NoSQL डेटाबेससाठीच विलक्षण आहेत, सूची करताना मी निश्चितपणे याचा उल्लेख करेन.
1. कोणतेही SQL वापरलेले नाही
म्हणजे एएनएसआय एस क्यू एल डीएमएल, कारण अनेक डेटाबेस सुप्रसिद्ध आवडत्या वाक्यरचना प्रमाणेच क्वेरी भाषा वापरण्याचा प्रयत्न करतात, परंतु कोणीही ते पूर्णपणे अंमलात आणले नाही आणि यशस्वी होण्याची शक्यता नाही. जरी अफवा आहे की स्टार्टअप्स SQL लागू करण्याचा प्रयत्न करत आहेत, उदाहरणार्थ hadup मध्ये ( http://www.drawntoscalehq.com/ आणि http://www.hadapt.com/ ).
2. असंरचित (योजनारहित)
याचा अर्थ असा आहे की NoSQL डेटाबेसमध्ये, रिलेशनल डेटाबेसेसच्या विपरीत, डेटा स्ट्रक्चरचे नियमन केले जात नाही (किंवा कमकुवतपणे टाइप केले असल्यास, जर आम्ही प्रोग्रामिंग भाषांशी साधर्म्य काढले तर) - तुम्ही प्रथम घोषणात्मकपणे संरचना बदलल्याशिवाय वेगळ्या ओळीत किंवा दस्तऐवजात अनियंत्रित फील्ड जोडू शकता. संपूर्ण टेबलचे. अशा प्रकारे, डेटा मॉडेल बदलण्याची आवश्यकता असल्यास, अनुप्रयोग कोडमधील बदल प्रतिबिंबित करणे ही एकच पुरेशी क्रिया आहे.
उदाहरणार्थ, MongoDB मध्ये फील्डचे नाव बदलताना:
BasicDBObject order = new BasicDBObject();
order.put("date", orderDate); // this field was a long time ago
order.put("totalSum", total); // before we just used "sum"आम्ही ऍप्लिकेशन लॉजिक बदलल्यास, वाचताना आम्हाला नवीन फील्ड देखील अपेक्षित आहे. परंतु डेटा स्कीमा नसल्यामुळे, इतर आधीपासून अस्तित्वात असलेल्या ऑर्डर ऑब्जेक्ट्समधून totalSum फील्ड गहाळ आहे. या परिस्थितीत, पुढील कारवाईसाठी दोन पर्याय आहेत.
प्रथम सर्व कागदपत्रे क्रॉल करणे आणि सर्व विद्यमान दस्तऐवजांमध्ये हे फील्ड अद्यतनित करणे आहे. डेटाच्या व्हॉल्यूममुळे, ही प्रक्रिया कोणत्याही लॉकशिवाय होते (अल्टर टेबल रिनेम कॉलम कमांडशी तुलना करता येते), त्यामुळे अपडेट दरम्यान, आधीच अस्तित्वात असलेला डेटा इतर प्रक्रियांद्वारे वाचला जाऊ शकतो. म्हणून, दुसरा पर्याय - अनुप्रयोग कोड तपासणे - अपरिहार्य आहे:
BasicDBObject order = new BasicDBObject();
Double totalSum = order.getDouble("sum"); // This is the old model
if (totalSum == null)
totalSum = order.getDouble("totalSum"); // This is the updated modelआणि आधीच जेव्हा आम्ही पुन्हा रेकॉर्ड करतो तेव्हा आम्ही हे फील्ड डेटाबेसमध्ये नवीन स्वरूपात लिहू.
स्कीमाच्या अनुपस्थितीचा एक सुखद परिणाम म्हणजे विरळ डेटासह कार्य करण्याची कार्यक्षमता. जर एका दस्तऐवजात तारीख_प्रकाशित फील्ड असेल आणि दुसऱ्यामध्ये नसेल, तर दुसऱ्यासाठी रिकामे तारीख_प्रकाशित फील्ड तयार केले जाणार नाही. हे, तत्त्वतः, तार्किक आहे, परंतु कमी स्पष्ट उदाहरण म्हणजे कॉलम-फॅमिली NoSQL डेटाबेस, जे टेबल/स्तंभांच्या परिचित संकल्पना वापरतात. तथापि, स्कीमा नसल्यामुळे, स्तंभ घोषणात्मकपणे घोषित केले जात नाहीत आणि वापरकर्त्याच्या डेटाबेस सत्रादरम्यान बदलले/जोडले जाऊ शकतात. हे, विशेषतः, सूचीच्या अंमलबजावणीसाठी डायनॅमिक स्तंभांचा वापर करण्यास अनुमती देते.
अनस्ट्रक्चर्ड स्कीमामध्ये काही तोटे आहेत - डेटा मॉडेल बदलताना ऍप्लिकेशन कोडमध्ये वर नमूद केलेल्या ओव्हरहेड व्यतिरिक्त - बेसवरील सर्व प्रकारच्या निर्बंधांची अनुपस्थिती (शून्य, अद्वितीय नाही, चेक प्रतिबंध इ.), तसेच तेथे वेगवेगळ्या प्रकल्पांच्या डेटाबेससह समांतरपणे काम करताना संरचना डेटा समजून घेण्यात आणि नियंत्रित करण्यात अतिरिक्त अडचणी येतात (डेटाबेसच्या बाजूला कोणतेही शब्दकोष नाहीत). तथापि, वेगाने बदलणाऱ्या आधुनिक जगात, अशी लवचिकता अजूनही एक फायदा आहे. एक उदाहरण म्हणजे ट्विटर, ज्याने पाच वर्षांपूर्वी ट्विटसह फक्त थोडी अतिरिक्त माहिती (वेळ, ट्विटर हँडल आणि मेटा-माहितीचे काही बाइट्स) संग्रहित केले होते, परंतु आता, संदेशाव्यतिरिक्त, आणखी काही मेटाडेटाचे किलोबाइट्स डेटाबेसमध्ये साठवले जातात.
(यापुढे, आम्ही मुख्यतः की-व्हॅल्यू, दस्तऐवज आणि कॉलम-फॅमिली डेटाबेसबद्दल बोलत आहोत, आलेख डेटाबेसमध्ये हे गुणधर्म नसतील)
२.३. एकत्रित स्वरूपात डेटाचे प्रतिनिधित्व (एकत्रित)
रिलेशनल मॉडेलच्या विपरीत, जे ऍप्लिकेशनच्या लॉजिकल बिझनेस एंटिटीला विविध भौतिक सारण्यांमध्ये सामान्यीकरणाच्या उद्देशाने संग्रहित करते, NoSQL स्टोअर्स या घटकांवर सर्वसमावेशक वस्तू म्हणून कार्य करतात:
हे उदाहरण मानक ई-कॉमर्स संकल्पनात्मक रिलेशनल मॉडेल "ऑर्डर - ऑर्डर आयटम - पेमेंट्स - उत्पादन" साठी एकत्रीकरण प्रदर्शित करते. दोन्ही प्रकरणांमध्ये, ऑर्डर एका लॉजिकल ऑब्जेक्टमध्ये पोझिशन्ससह एकत्रित केली जाते, तर प्रत्येक स्थान उत्पादनाची लिंक आणि त्यातील काही गुणधर्म संचयित करते, उदाहरणार्थ, नाव (पुनर्प्राप्त करताना उत्पादन ऑब्जेक्टची विनंती करू नये म्हणून असे विकृतीकरण आवश्यक आहे. ऑर्डर - वितरित सिस्टमचा मुख्य नियम ऑब्जेक्ट्स दरम्यान "जोडणे" आहे). एका एकूणात, देयके ऑर्डरसह एकत्रित केली जातात आणि ऑब्जेक्टचा अविभाज्य भाग असतात, दुसऱ्यामध्ये ते वेगळ्या ऑब्जेक्टमध्ये ठेवतात. हे NoSQL डेटाबेसेसमध्ये डेटा स्ट्रक्चर डिझाइन करण्याचा मुख्य नियम दर्शविते - त्याने ऍप्लिकेशनच्या आवश्यकतांचे पालन केले पाहिजे आणि वारंवार येणाऱ्या विनंत्यांसाठी शक्य तितके ऑप्टिमाइझ केले पाहिजे.
अनेकजण आक्षेप घेतील, हे लक्षात घेऊन की मोठ्या, बर्‍याचदा डिनॉर्मलाइज्ड, ऑब्जेक्‍टसह काम करताना डेटावर अनियंत्रित क्वेरी वापरताना अनेक समस्या येतात, जेव्हा क्वेरी एकत्रित संरचनेत बसत नाहीत. आम्ही ऑर्डर लाइन आयटम आणि पेमेंटसह ऑर्डर वापरत असल्यास (अ‍ॅप कसे कार्य करते), परंतु व्यवसाय आम्हाला गेल्या महिन्यात विशिष्ट उत्पादनाच्या किती युनिट्सची विक्री झाली हे मोजण्यास सांगते? या प्रकरणात, OrderItem टेबल स्कॅन करण्याऐवजी (रिलेशनल मॉडेलच्या बाबतीत), आम्हाला NoSQL स्टोरेजमधील संपूर्ण ऑर्डर पुनर्प्राप्त करावी लागतील, जरी आम्हाला या माहितीची जास्त गरज भासणार नाही. दुर्दैवाने, ही एक तडजोड आहे जी वितरित प्रणालीमध्ये करावी लागेल: आम्ही पारंपारिक सिंगल-सर्व्हर सिस्टमप्रमाणे डेटा सामान्य करू शकत नाही,
मी टेबलमध्ये दोन्ही दृष्टिकोनांचे साधक आणि बाधक गट करण्याचा प्रयत्न केला:
