2.1 शब्द NoSQL का उद्भव
हाल ही में, "NoSQL" शब्द बहुत फैशनेबल और लोकप्रिय हो गया है, इस संकेत के तहत सभी प्रकार के सॉफ़्टवेयर समाधान सक्रिय रूप से विकसित और प्रचारित किए जा रहे हैं। NoSQL बड़ी मात्रा में डेटा, लीनियर स्केलेबिलिटी, क्लस्टर्स, फॉल्ट टॉलरेंस, नॉन-रिलेशनलिटी का पर्याय बन गया है। हालाँकि, कुछ लोगों को इस बात की स्पष्ट समझ है कि NoSQL स्टोरेज क्या है, यह शब्द कैसे प्रकट हुआ और उनकी क्या सामान्य विशेषताएँ हैं। आइए इस अंतर को भरने का प्रयास करें।
इस शब्द के बारे में सबसे दिलचस्प बात यह है कि इस तथ्य के बावजूद कि यह पहली बार 90 के दशक के अंत में इस्तेमाल किया गया था, इसने वास्तविक अर्थ केवल उस रूप में प्राप्त किया जिसमें अब इसका उपयोग 2009 के मध्य में किया जाता है। प्रारंभ में, यह एक खुले का नाम था कार्लो स्ट्रोज़ी द्वारा बनाया गया स्रोत डेटाबेस, जो सभी डेटा को ASCII फ़ाइलों के रूप में संग्रहीत करता है और डेटा तक पहुँचने के लिए SQL के बजाय शेल स्क्रिप्ट का उपयोग करता है। इसका अपने मौजूदा रूप में "NoSQL" से कोई लेना-देना नहीं था।
जून 2009 में आईटी भंडारण और प्रसंस्करण बाजार में नए रुझानों पर चर्चा करने के लिए जोहान ऑस्करसन ने सैन फ्रांसिस्को में एक बैठक आयोजित की। बैठक के लिए मुख्य प्रेरणा बिगटेबल और डायनेमो जैसे नए ओपन सोर्स उत्पाद थे। बैठक के लिए एक उज्ज्वल संकेत के लिए, एक संक्षिप्त और संक्षिप्त शब्द खोजना आवश्यक था जो ट्विटर हैशटैग में पूरी तरह से फिट हो। इन शर्तों में से एक रैकस्पेस - "नोएसक्यूएल" से एरिक इवांस द्वारा प्रस्तावित किया गया था। यह शब्द केवल एक बैठक के लिए नियोजित किया गया था और इसमें गहरा शब्दार्थ भार नहीं था, लेकिन ऐसा हुआ कि यह एक वायरल विज्ञापन की तरह पूरे वैश्विक नेटवर्क में फैल गया और आईटी उद्योग में एक संपूर्ण प्रवृत्ति का वास्तविक नाम बन गया। वैसे, वोल्डेमॉर्ट (अमेज़ॅन डायनमो क्लोन), कैसेंड्रा, एचबेस (गूगल बिगटेबल के एनालॉग्स), हाइपरटेबल, कॉचडीबी, मोंगोडीबी ने सम्मेलन में बात की।
यह एक बार फिर जोर देने योग्य है कि "नोएसक्यूएल" शब्द मूल रूप से पूरी तरह से सहज है और इसके पीछे आम तौर पर स्वीकृत परिभाषा या वैज्ञानिक संस्था नहीं है। बल्कि यह नाम रिलेशनल डेटाबेस से दूर आईटी विकास के वेक्टर की विशेषता बताता है। यह न केवल SQL के लिए खड़ा है, हालाँकि SQL की प्रत्यक्ष परिभाषा के समर्थक हैं। प्रमोद सदालज और मार्टिन फाउलर ने अपनी हालिया पुस्तक "नोएसक्यूएल डिस्टिल्ड" में एनओएसक्यूएल दुनिया के बारे में ज्ञान को समूहबद्ध और व्यवस्थित करने की कोशिश की।
2.2 NoSQL डेटाबेस की मूलभूत विशेषताएँ
सभी NoSQL के लिए कुछ सामान्य विशेषताएँ हैं, क्योंकि कई विषम प्रणालियाँ अब NoSQL लेबल के अंतर्गत छिपी हुई हैं (शायद सबसे पूरी सूची http://nosql-database.org/ पर पाई जा सकती है)। कई विशेषताएँ केवल कुछ NoSQL डेटाबेस के लिए विशिष्ट हैं, मैं निश्चित रूप से सूचीबद्ध करते समय इसका उल्लेख करूँगा।
1. किसी SQL का उपयोग नहीं किया जाता है
मेरा मतलब एएनएसआई एसक्यूएल डीएमएल है, क्योंकि कई डेटाबेस प्रसिद्ध पसंदीदा सिंटैक्स के समान क्वेरी भाषाओं का उपयोग करने की कोशिश करते हैं, लेकिन कोई भी इसे पूरी तरह से लागू करने में कामयाब नहीं हुआ है और सफल होने की संभावना नहीं है। हालाँकि ऐसी अफवाह वाले स्टार्टअप हैं जो SQL को लागू करने की कोशिश कर रहे हैं, उदाहरण के लिए हडप में ( 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"यदि हम एप्लिकेशन लॉजिक को बदलते हैं, तो हम पढ़ते समय एक नए क्षेत्र की भी अपेक्षा करते हैं। लेकिन डेटा स्कीमा की कमी के कारण, टोटलसम फ़ील्ड पहले से मौजूद अन्य ऑर्डर ऑब्जेक्ट्स से गायब है। ऐसी स्थिति में आगे की कार्रवाई के लिए दो विकल्प हैं।
सबसे पहले सभी दस्तावेज़ों को क्रॉल करना और सभी मौजूदा दस्तावेज़ों में इस फ़ील्ड को अपडेट करना है। डेटा की मात्रा के कारण, यह प्रक्रिया बिना किसी लॉक के होती है (परिवर्तन तालिका नाम बदलें कॉलम कमांड की तुलना में), इसलिए अद्यतन के दौरान, पहले से मौजूद डेटा को अन्य प्रक्रियाओं द्वारा पढ़ा जा सकता है। इसलिए, दूसरा विकल्प - आवेदन कोड में जाँच - अपरिहार्य है:
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और पहले से ही जब हम फिर से रिकॉर्ड करते हैं, तो हम इस क्षेत्र को एक नए प्रारूप में डेटाबेस में लिखेंगे।
स्कीमा की अनुपस्थिति का एक सुखद परिणाम विरल डेटा के साथ काम करने की क्षमता है। यदि एक दस्तावेज़ में date_published फ़ील्ड है और दूसरे में नहीं है, तो दूसरे दस्तावेज़ के लिए कोई खाली date_published फ़ील्ड नहीं बनाया जाएगा। यह, सिद्धांत रूप में, तार्किक है, लेकिन एक कम स्पष्ट उदाहरण स्तंभ-परिवार NoSQL डेटाबेस है, जो तालिकाओं / स्तंभों की परिचित अवधारणाओं का उपयोग करते हैं। हालांकि, स्कीमा की कमी के कारण, कॉलम को घोषणात्मक रूप से घोषित नहीं किया जाता है और इसे उपयोगकर्ता के डेटाबेस सत्र के दौरान बदला/जोड़ा जा सकता है। यह विशेष रूप से, सूचियों के कार्यान्वयन के लिए गतिशील स्तंभों के उपयोग की अनुमति देता है।
असंरचित स्कीमा में इसकी कमियां हैं - डेटा मॉडल को बदलते समय एप्लिकेशन कोड में उपर्युक्त ओवरहेड के अलावा - आधार से सभी प्रकार के प्रतिबंधों की अनुपस्थिति (शून्य, अद्वितीय, चेक बाधा, आदि नहीं), साथ ही वहाँ समानांतर में विभिन्न परियोजनाओं के डेटाबेस के साथ काम करते समय संरचना डेटा को समझने और नियंत्रित करने में अतिरिक्त कठिनाइयाँ हैं (डेटाबेस के पक्ष में कोई शब्दकोश नहीं हैं)। हालांकि, तेजी से बदलती आधुनिक दुनिया में, ऐसा लचीलापन अभी भी एक फायदा है। एक उदाहरण ट्विटर है, जो पांच साल पहले, ट्वीट के साथ, केवल थोड़ी अतिरिक्त जानकारी (समय, ट्विटर हैंडल और मेटा-जानकारी के कुछ और बाइट्स) संग्रहीत करता था, लेकिन अब, संदेश के अलावा, कुछ और मेटाडेटा के किलोबाइट्स को डेटाबेस में संग्रहीत किया जाता है।
(इसके बाद, हम मुख्य रूप से कुंजी-मूल्य, दस्तावेज़ और स्तंभ-परिवार डेटाबेस के बारे में बात कर रहे हैं, ग्राफ़ डेटाबेस में ये गुण नहीं हो सकते हैं)
2.3। समुच्चय (समुच्चय) के रूप में डेटा का प्रतिनिधित्व
रिलेशनल मॉडल के विपरीत, जो सामान्यीकरण उद्देश्यों के लिए एप्लिकेशन की तार्किक व्यावसायिक इकाई को विभिन्न भौतिक तालिकाओं में संग्रहीत करता है, NoSQL स्टोर इन संस्थाओं पर समग्र वस्तुओं के रूप में काम करते हैं:
यह उदाहरण एक मानक ई-कॉमर्स वैचारिक संबंधपरक मॉडल "ऑर्डर - ऑर्डर आइटम - भुगतान - उत्पाद" के लिए एकत्रीकरण प्रदर्शित करता है। दोनों ही मामलों में, आदेश को एक तार्किक वस्तु में पदों के साथ जोड़ा जाता है, जबकि प्रत्येक स्थिति उत्पाद और उसके कुछ गुणों के लिए एक लिंक संग्रहीत करती है, उदाहरण के लिए, नाम (इस तरह के अपसामान्यीकरण आवश्यक है ताकि पुनर्प्राप्त करते समय उत्पाद वस्तु का अनुरोध न किया जा सके एक आदेश - वितरित प्रणालियों का मुख्य नियम वस्तुओं के बीच "जुड़ना" है)। एक कुल में, भुगतान आदेश के साथ संयुक्त होते हैं और वस्तु का एक अभिन्न अंग होते हैं, दूसरे में उन्हें एक अलग वस्तु में रखा जाता है। यह NoSQL डेटाबेस में डेटा संरचना को डिजाइन करने के मुख्य नियम को प्रदर्शित करता है - इसे एप्लिकेशन की आवश्यकताओं का पालन करना चाहिए और सबसे लगातार अनुरोधों के लिए जितना संभव हो उतना अनुकूलित होना चाहिए।
कई लोग आपत्ति करेंगे, यह देखते हुए कि बड़े, अक्सर असामान्य वस्तुओं के साथ काम करना डेटा पर मनमानी प्रश्नों की कोशिश करते समय कई समस्याओं से भरा होता है जब प्रश्न समुच्चय की संरचना में फिट नहीं होते हैं। क्या होगा यदि हम ऑर्डर लाइन आइटम और भुगतान के साथ ऑर्डर का उपयोग करते हैं (ऐप इस तरह काम करता है), लेकिन व्यवसाय हमसे यह गिनने के लिए कहता है कि पिछले महीने किसी विशेष उत्पाद की कितनी इकाइयाँ बेची गईं? इस मामले में, ऑर्डरआइटम तालिका (रिलेशनल मॉडल के मामले में) को स्कैन करने के बजाय, हमें NoSQL स्टोरेज में पूरे ऑर्डर को पुनः प्राप्त करना होगा, हालाँकि हमें इस जानकारी की अधिक आवश्यकता नहीं होगी। दुर्भाग्य से, यह एक समझौता है जिसे एक वितरित प्रणाली में करना पड़ता है: हम पारंपरिक एकल-सर्वर प्रणाली की तरह डेटा को सामान्य नहीं कर सकते हैं,
मैंने तालिका में दोनों दृष्टिकोणों के पेशेवरों और विपक्षों को समूहित करने का प्रयास किया:
