"NoSQL" की विनम्र व्याख्या Not Only SQL बन गई है . यदि आपके पास डेटा है जो वास्तव में रिलेशनल है, या यदि आपकी कार्यक्षमता जॉइन और एसिडिटी जैसी चीजों पर निर्भर करती है, तो आपको उस डेटा को रिलेशनल तरीके से स्टोर करना चाहिए। इस पोस्ट में, मैं समझाऊंगा कि कैसे मैं दो . के साथ MySQL का उपयोग करता हूं नोएसक्यूएल डेटा स्टोर। आधुनिक, वेब-स्केल डेटा संग्रहण यह समझने के बारे में है कि नौकरी के लिए सबसे अच्छा टूल कैसे चुनें।
उस ने कहा, नोएसक्यूएल वास्तव में इस तथ्य की प्रतिक्रिया है कि रिलेशनल विधि और सोचने का तरीका उन समस्याओं पर लागू किया गया है जहां यह वास्तव में बहुत अच्छा फिट नहीं है (आमतौर पर लाखों पंक्तियों या अधिक के साथ विशाल टेबल)। एक बार जब टेबल इतने बड़े हो जाते हैं, तो विशिष्ट SQL "सर्वोत्तम अभ्यास" मैन्युअल रूप से shard . किया गया है डेटा - यानी, तालिका ए में रिकॉर्ड 1 से 10,000,000, तालिका बी में 10,000,001 से 20,000,001 तक, और इसी तरह। फिर, आमतौर पर अनुप्रयोग मॉडल परत में, लुकअप इस योजना के अनुसार किया जाता है। इसे कहते हैं application-aware स्केलिंग। यह समय-गहन और त्रुटि प्रवण है, लेकिन लंबे टेबल स्टोर के लिए MySQL को बनाए रखते हुए कुछ बढ़ाने के लिए, यह कम या ज्यादा मानक एमओ बन गया है। मेरे लिए NoSQL application-unaware . का प्रतिनिधित्व करता है वैकल्पिक।
कुंजी-मूल्य
जब मेरे पास एक MySQL प्रोटोटाइप अपने स्वयं के अच्छे के लिए बहुत बड़ा होना शुरू हो गया, तो मैंने व्यक्तिगत रूप से जितना संभव हो उतना डेटा लाइटनिंग-फास्ट Membase में स्थानांतरित कर दिया। , जो मेमकैच्ड से बेहतर प्रदर्शन करता है और दृढ़ता जोड़ता है। मेम्बेस एक वितरित की-वैल्यू स्टोर है जो एक क्लस्टर में अधिक कमोडिटी सर्वर जोड़कर अधिक या कम रैखिक रूप से स्केल करता है (ज़िंगा इसका उपयोग आधा मिलियन ऑप्स प्रति सेकंड को संभालने के लिए करता है) - इसलिए यह एक महान Amazon EC2 के क्लाउड युग के लिए फ़िट , जॉयंट , आदि.
यह सर्वविदित है कि वितरित की-वैल्यू स्टोर विशाल, रैखिक पैमाने प्राप्त करने का सबसे अच्छा तरीका है। की-वैल्यू की कमजोरी क्वेरीबिलिटी और इंडेक्सिंग है। लेकिन रिलेशनल दुनिया में भी, स्केलेबिलिटी के लिए सबसे अच्छा अभ्यास है जितना संभव हो सके एप्लिकेशन सर्वर पर अधिक से अधिक प्रयास करना, केंद्रीय आरडीबी क्लस्टर को उस तर्क को संभालने के लिए कहने के बजाय कमोडिटी ऐप सर्वर पर मेमोरी में जुड़ना। चूंकि simple select प्लस application logic बड़े पैमाने पर हासिल करने का वास्तव में सबसे अच्छा तरीका है यहां तक कि MySQL, Membase (या इसके प्रतिस्पर्धियों जैसे Riak
जैसी किसी चीज़ में संक्रमण ) वास्तव में बहुत बुरा नहीं है।
दस्तावेज़ स्टोर
कभी-कभी - हालांकि मैं कई लोगों की तुलना में कम बार बहस करता हूं - एक एप्लिकेशन के डिज़ाइन को स्वाभाविक रूप से माध्यमिक सूचकांक, श्रेणी क्वेरी योग्यता, आदि की आवश्यकता होती है। इसके लिए NoSQL दृष्टिकोण document store के माध्यम से है जैसे MongoDB
. मेम्बेस की तरह, कुछ क्षेत्रों में मोंगो बहुत अच्छा है जहां संबंधपरक डेटाबेस विशेष रूप से कमजोर हैं, जैसे application-unaware स्केलिंग, auto-sharding , और maintaining flat response times even as dataset size balloons . यह मेम्बेस की तुलना में काफी धीमा है और शुद्ध क्षैतिज पैमाने पर करने के लिए थोड़ा मुश्किल है, लेकिन लाभ यह है कि यह अत्यधिक पूछताछ योग्य है। आप वास्तविक समय में पैरामीटर और श्रेणियों पर क्वेरी कर सकते हैं, या आप वास्तव में विशाल डेटा सेट पर जटिल बैच संचालन करने के लिए मानचित्र/कम करें का उपयोग कर सकते हैं।
उसी प्रोजेक्ट पर जिसका मैंने ऊपर उल्लेख किया है, जो लाइव प्लेयर डेटा के टन की सेवा के लिए मेम्बेस का उपयोग करता है, हम एनालिटिक्स/मेट्रिक्स डेटा स्टोर करने के लिए मोंगोडीबी का उपयोग करते हैं, जो वास्तव में मोंगोडीबी चमकता है।
चीजों को SQL में क्यों रखें
मैंने इस तथ्य पर संक्षेप में बात की कि 'वास्तव में संबंधपरक' जानकारी संबंधपरक डेटाबेस में रहनी चाहिए। जैसा कि टिप्पणीकार डैन के। बताते हैं, मैंने उस हिस्से को याद किया जहां मैं आरडीबीएमएस छोड़ने के नुकसान पर चर्चा करता हूं, या कम से कम इसे पूरी तरह से छोड़ देता हूं।
सबसे पहले, स्वयं SQL है। एसक्यूएल प्रसिद्ध है और लंबे समय से एक उद्योग मानक रहा है। कुछ "NoSQL" डेटाबेस जैसे Google का App Engine
डेटास्टोर (बिग टेबल पर निर्मित) अपनी स्वयं की SQL जैसी भाषा को लागू करते हैं (Google को Google Query Language के लिए, क्यूटली, GQL कहा जाता है) ) MongoDB अपने रमणीय JSON क्वेरी ऑब्जेक्ट
के साथ क्वेरी समस्या के लिए एक नया दृष्टिकोण लेता है। . फिर भी, SQL अपने आप में डेटा से जानकारी प्राप्त करने के लिए एक शक्तिशाली उपकरण है, जो अक्सर शुरू करने के लिए डेटाबेस का संपूर्ण बिंदु होता है।
RDBMS के साथ बने रहने का सबसे महत्वपूर्ण कारण है ACID
, या Atomicity, Consistency, Isolation, Durability . मैं एसिड-नोएसक्यूएल की स्थिति को फिर से हैश नहीं करूंगा, क्योंकि यह यह पोस्ट
इतने पर। यह कहने के लिए पर्याप्त है, एक तर्कसंगत कारण है Oracle's RDBMS
इतना बड़ा बाजार है जो कहीं नहीं जा रहा है:कुछ डेटा को शुद्ध एसीआईडी अनुपालन की आवश्यकता है . यदि आपका डेटा करता है (और यदि ऐसा होता है, तो आप शायद उस तथ्य से अच्छी तरह वाकिफ हैं), तो आपका डेटाबेस भी ऐसा ही करता है। इसे pH
रखें कम!
संपादित करें: एरोनॉट की पोस्ट यहां देखें। वह व्यवसाय-से-व्यवसाय के दृष्टिकोण का मुझसे कहीं बेहतर प्रतिनिधित्व करता है, आंशिक रूप से क्योंकि मैंने अपना पूरा करियर उपभोक्ता क्षेत्र में बिताया है।
