NoSQL डेटाबेस: सार को समझना

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

कहानी।

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

जून 2009 में, सैन फ्रांसिस्को में जोहान ऑस्करसन द्वारा एक बैठक आयोजित की गई, जिसमें आईटी डेटा स्टोरेज और प्रोसेसिंग मार्केट में नए रुझानों पर चर्चा की गई। बैठक के लिए मुख्य उत्तेजना बिगटेबल और डायनमो जैसे नए खुले स्रोत उत्पाद थे। एक बैठक के लिए उज्ज्वल संकेत के लिए, एक कैपेसिटिव और संक्षिप्त शब्द ढूंढना आवश्यक था जो ट्विटर हैशटैग में पूरी तरह से फिट होगा। ऐसा ही एक शब्द रैकस्पेस से एरिक इवांस ने सुझाया था - "NoSQL"। यह शब्द केवल एक बैठक के लिए नियोजित किया गया था और इसमें गहरा शब्दार्थ भार नहीं था, लेकिन ऐसा हुआ कि यह वैश्विक नेटवर्क में एक वायरल विज्ञापन की तरह फैल गया और आईटी उद्योग में एक संपूर्ण दिशा का वास्तविक नाम बन गया। सम्मेलन में, वोल्डेमॉर्ट (अमेज़ॅन डायनमो का क्लोन), कैसेंड्रा, एचबेस (गूगल बिगटेबल के एनालॉग्स), हाइपरटेबल, काउचडीबी, मोंगबॉडी ने बात की।

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

NoSQL डेटाबेस सुविधाएँ

सभी NoSQL के लिए कुछ सामान्य विशेषताएँ हैं, क्योंकि अब NoSQL लेबल के अंतर्गत कई विषम प्रणालियाँ हैं (शायद सबसे पूरी सूची http://nosql-database.org/ पर देखी जा सकती है)। कई विशेषताओं केवल कुछ NoSQL डेटाबेस के लिए अजीब हैं, जिन्हें मैं निश्चित रूप से सूचीबद्ध करते समय उल्लेख करूंगा।

1. SQL का उपयोग नहीं किया जाता है

यह एएनएसआई एसक्यूएल डीएमएल को संदर्भित करता है, क्योंकि कई डेटाबेस प्रसिद्ध पसंदीदा सिंटैक्स के समान क्वेरी भाषाओं का उपयोग करने की कोशिश करते हैं, लेकिन कोई भी इसे पूरी तरह से लागू करने में कामयाब नहीं होता है और सफल होने की संभावना नहीं है। यद्यपि ऐसी अफवाहें हैं कि स्टार्टअप हैं जो एसक्यूएल को लागू करने की कोशिश कर रहे हैं, उदाहरण के लिए, एक बैकअप में ( http://www.drawntoscalehq.com/ और http://www.hadapt.com/ )

2. असंरचित (योजनाबद्ध)

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

उदाहरण के लिए, जब MongoDB में एक फ़ील्ड का नाम बदल रहा है:

BasicDBObject order = new BasicDBObject(); order.put(“date”, orderDate); //     order.put(“totalSum”, total); //     “sum” 

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

 BasicDBObject order = new BasicDBObject(); Double totalSum = order.getDouble(“sum”); //    if (totalSum == null) totalSum = order.getDouble(“totalSum”); //    

और फिर से रिकॉर्डिंग करते समय, हम इस फ़ील्ड को एक नए प्रारूप में डेटाबेस में लिखेंगे।

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

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

(इसके बाद, यह मुख्य रूप से कुंजी-मूल्य, दस्तावेज़ और स्तंभ-परिवार डेटाबेस के बारे में है, ग्राफ़ डेटाबेस में ये गुण नहीं हो सकते हैं)।

3. समुच्चय के रूप में डेटा की प्रस्तुति।

संबंधपरक मॉडल के विपरीत, जो सामान्य करने के लिए विभिन्न भौतिक तालिकाओं में एप्लिकेशन की तार्किक व्यापार इकाई को संग्रहीत करता है, NoSQL स्टोर इन संस्थाओं के साथ अभिन्न वस्तुओं के साथ संचालित होते हैं:



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

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



4. कमजोर ACID गुण।

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



ऐसी स्थिति में जो तार्किक सवाल उठता है, वह यह है कि उन प्रणालियों के लिए क्या करना है जो परिचालन की परमाणु-संगति पर उच्च मांगों को रखते हैं और एक ही समय में तेजी से वितरित क्लस्टर - वित्तीय, ऑनलाइन स्टोर आदि की आवश्यकता होती है? अभ्यास से पता चलता है कि ये आवश्यकताएं लंबे समय से अप्रासंगिक हैं: यह है कि वित्तीय बैंकिंग प्रणाली के एक डेवलपर ने कहा: "अगर हम वास्तव में वैश्विक एटीएम नेटवर्क (एटीएम) में प्रत्येक लेनदेन के पूरा होने के लिए इंतजार कर रहे थे, तो लेनदेन में इतना समय लगेगा कि ग्राहक गुस्से में भाग जाएंगे। यदि आप और आपका साथी एक ही समय में पैसा निकालते हैं और सीमा से अधिक हो जाते हैं तो क्या होगा? "आप दोनों पैसे प्राप्त करेंगे, और हम इसे बाद में ठीक कर देंगे।" एक अन्य उदाहरण तस्वीर में दिखाया गया होटल आरक्षण है। ऑनलाइन स्टोर, जिनकी डेटा के साथ काम करने की नीति में अंतिम स्थिरता शामिल है, ऐसी स्थितियों (संघर्ष का स्वत: समाधान, रोलबैक संचालन, अन्य डेटा के साथ अद्यतन) के मामले में उपाय प्रदान करने के लिए बाध्य हैं। व्यवहार में, होटल हमेशा अप्रत्याशित घटना के लिए मुफ्त कमरे का "पूल" रखने की कोशिश करते हैं, और यह एक विवादास्पद स्थिति का समाधान हो सकता है।

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

5. वितरित सिस्टम, साझा संसाधनों के बिना (शेयर कुछ भी नहीं)।

फिर, यह एक डेटाबेस ग्राफ पर लागू नहीं होता है, जिसकी संरचना, परिभाषा के अनुसार, खराब नोड्स में वितरित की जाती है।

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

प्रतिकृति - उन्नयन के दौरान अन्य नोड्स में डेटा की प्रतिलिपि बनाना। यह दोनों को अधिक मापनीयता प्राप्त करने और डेटा की उपलब्धता और सुरक्षा को बढ़ाने की अनुमति देता है। इसे दो प्रकारों में उपविभाजित करना स्वीकार किया जाता है:
गुरु-दास :



और सहकर्मी से सहकर्मी :



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

शेयरिंग - नोड्स द्वारा डेटा पृथक्करण:



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

6. NoSQL डेटाबेस ज्यादातर खुले स्रोत हैं और 21 वीं सदी में बनाए गए हैं।

यह दूसरे आधार पर है कि सदलज और फाउलर ने ऑब्जेक्ट डेटाबेस को नोएसक्यूएल के रूप में वर्गीकृत नहीं किया था (हालांकि http://nosql-database.org/ उन्हें सामान्य सूची में शामिल करता है), क्योंकि वे 90 के दशक में वापस बनाए गए थे और उन्हें बहुत लोकप्रियता मिली है। ।

इसके अलावा, मैं NoSQL डेटाबेस के वर्गीकरण पर ध्यान केंद्रित करना चाहता था, लेकिन, शायद, मैं अगले लेख में ऐसा करूंगा, अगर यह हैब्रोर्स के लिए दिलचस्प होगा।

सारांश।

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