तथाकथित "NoSQL" डेटाबेस में डेटा मॉडल स्केलेबिलिटी और प्रदर्शन को कितना प्रभावित करता है?


13

सीएपी प्रमेय (संगति, उपलब्धता, विभाजन: उठाएं) को लाए बिना आप कभी भी तथाकथित "NoSQL" डेटाबेस के बारे में बात नहीं कर सकते। अगर आपको MongoDB (विभाजन, संगति) और CouchDB (उपलब्धता, विभाजन) के बीच कहना है, तो आपको सबसे पहले यह सोचना होगा कि "क्या मुझे सही डेटा चाहिए या मुझे हर समय एक्सेस की आवश्यकता है?"

उन नए डेटाबेस को विभाजन के लिए बनाया गया था । लेकिन क्या होगा अगर मैं नहीं ? क्या होगा अगर मैं सिर्फ एक कुंजी / मूल्य, कॉलम, दस्तावेज़, एक रिलेशनल के बजाय जो भी डेटाबेस हो, और बस एक सर्वर इंस्टेंस बनाने के लिए और इसे कभी भी शार्द करने के लिए अपने सुंदर शांत नहीं लगता? उस स्थिति में, क्या मेरे पास उपलब्धता और स्थिरता दोनों नहीं होगी? MongoDB को कुछ भी दोहराने की आवश्यकता नहीं होगी, इसलिए यह उपलब्ध होगा। और CouchDB में डेटा का केवल एक स्रोत होगा, इसलिए यह बहुत संगत होगा।

तो इसका मतलब यह होगा कि, उस स्थिति में, MongoDB और CouchDB के उपयोग के मामले में थोड़ा अंतर होगा? ठीक है, पाठ्यक्रम के प्रदर्शन, एपीआई और अल को छोड़कर, लेकिन यह पोस्टग्रेक्यूएल और माईएसक्यूएल के बीच दो मूलभूत आवश्यकताओं के अलग-अलग सेटों को चुनने की तुलना में अधिक पसंद करेगा।

क्या मैं यहीं हूँ? क्या मैं एक से अधिक इंस्टेंस नहीं बनाकर एक एपी या सीपी डेटाबेस को एक एसी में बदल सकता हूं? या कुछ ऐसा है जो मुझे याद आ रहा है?

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

संक्षेप में: अंतर्निहित डेटा मॉडल की तुलना में कैप प्रमेय में आप क्या देने के लिए तैयार हैं, इसके बारे में मापनीयता है? क्या कॉलम, डॉक्यूमेंट, की वैल्यू, जो किसी रिलेशनल मॉडल पर स्केलेबिलिटी को बढ़ावा देते हैं? क्या हम विभाजन सहिष्णुता के लिए जमीन से डिज़ाइन किया गया एक संबंधपरक डेटाबेस तैयार कर सकते हैं? (शायद यह पहले से मौजूद है)। क्या हम NoSQL डेटाबेस ACID का अनुपालन कर सकते हैं?

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

जवाबों:


8

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

उदाहरण के लिए विचार करें कि आप Google ड्राइव, ड्रॉपबॉक्स या बॉक्स के समान क्लाउड फ़ाइल स्टोरेज सिस्टम बना रहे हैं, लेकिन वास्तविक फ़ाइल सिस्टम का उपयोग करने के बजाय आप तय करते हैं कि फ़ाइल सिस्टम का वर्चुअलाइजेशन करना आपके लिए अधिक लाभदायक होगा। अब आपको एक समस्या है क्योंकि आपका डेटा मॉडल अचानक पेड़ की संरचना है जो RDBMS में बुरी तरह से अक्षम है (इस तथ्य के बावजूद कि सब कुछ अनुक्रमित है)। क्योंकि अब आपके पास Name, User, और Parent के साथ एक 3 कॉलम टेबल है। उपयोगकर्ता एक उपयोगकर्ता तालिका के लिए एक विदेशी कुंजी है और माता-पिता एक आत्म-संदर्भित अशांत विदेशी कुंजी है (अशक्त क्योंकि रूट निर्देशिका में माता-पिता नहीं हो सकते)। तो प्राथमिक कुंजी क्या है? इस उदाहरण में यह सभी कॉलमों में एक कंपाउंड की हुई कुंजी है ... जो अभिभावकों को अचानक हमारा सबसे बड़ा दुश्मन बना देती है।

अब इसके बजाय आप इस बारे में सोचें कि आप इसे किसी दस्तावेज़ की दुकान में कैसे रखेंगे? डेटा से लड़ने के बजाय आप इसके साथ काम कर सकते हैं और इसे पेड़ की संरचना के रूप में संग्रहीत कर सकते हैं जो बदले में आपके विकास के समय के साथ-साथ रखरखाव लागतों को भी कम करेगा। यदि आप लागत कम कर रहे हैं तो यह एक अलग तरह की मापनीयता के लिए अनुमति नहीं देता है? इसके अलावा इस उदाहरण में आप सिस्टम को सही ढंग से जमीन से ऊपर बना रहे हैं, जो कि एप्लिकेशन को अधिक लचीलापन दे। वर्तमान में मैं MongoDB का उपयोग करके एक एकल सर्वर पर इसे चला रहा हूं, जैसा कि आपने समझाया कि मुझे एक उपलब्ध, सुसंगत मॉडल है जो MySQL या पोस्टग्रेज के अंतर को देखने से बहुत अलग नहीं है।

MongoDB के साथ कम से कम आप परिभाषित कर सकते हैं कि किसी सर्वर को क्वेरी के लिए संवाद करने के लिए कितने सफल होने की आवश्यकता है, हाँ यदि आप सभी सर्वर इंस्टेंसेस के साथ संवाद करने के लिए सभी प्रश्न बताते हैं, तो आप इसे एक सुसंगत, उपलब्ध मॉडल में बदल सकते हैं।

इसलिए मुझे लगता है कि आपके पास इसका अधिकार है कि डेटा कैसे संग्रहीत किया जाता है, इसमें एक बड़ा लाभ है। ऐसी चीजें हैं जो एक संबंधपरक मॉडल में अच्छी तरह से फिट नहीं होती हैं जो अन्य मॉडलों में अच्छी तरह से फिट होती हैं (एक अन्य संक्षिप्त उदाहरण के रूप में, अमेज़ॅन उत्पादों के लिए अपने सिफारिश इंजन के लिए ग्राफ़ डेटाबेस के कुछ रूप का उपयोग करता है)।

क्या मैंने आपके प्रश्न को सही ढंग से समझा?

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

आप इनमें से किसी भी डेटाबेस में डेटा को कैसे स्टोर करते हैं, यह प्रदर्शन को प्रभावित करेगा (यदि आप आरडीबीएमएस में गलत तरीके से डेटा स्टोर करते हैं तो यह प्रदर्शन को प्रभावित करेगा)। तो उम्मीद है कि इसे और अधिक स्पष्ट करने के लिए: आपको यह जानने की जरूरत है कि आपको उस डेटाबेस सिस्टम में डेटा स्टोर करने के लिए किस डेटाबेस सिस्टम का उपयोग करना चाहिए।


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

उस स्थिति में यह आपके द्वारा उपयोग किए जा रहे डेटाबेस सिस्टम पर निर्भर करने वाला है। मेरे उपरोक्त क्लाउड फ़ाइल सिस्टम उदाहरण के लिए, मैं वास्तव में फ़ाइलों को संग्रहीत करने के लिए रेडिस का उपयोग कर रहा हूं, और वे 100,000 प्रश्नों / सेकंड को संभालने में सक्षम होने का दावा करते हैं (क्योंकि यह मेमोरी कुंजी / मूल्य स्टोर में एक के रूप में बनाया गया था)। अब मैंने वास्तव में यह देखने के लिए अपने आवेदन का परीक्षण नहीं किया है कि यह वास्तव में क्या संभाल सकता है, लेकिन रेडिस वेबसाइट का कहना है। यह कहा जा रहा है कि याद रखें कि डेटा के विभिन्न प्रकारों के आधार पर आपके द्वारा उपयोग किए जाने वाले दृश्यों के पीछे विभिन्न प्रकार के डेटाबेस सिस्टम का प्रतिनिधित्व किया जा रहा है। उचित db के साथ niches भरें।
6'13

1
मैंने अपनी प्रतिक्रिया संपादित की क्योंकि यह अधिक टिप्पणियों को जोड़ने से आसान था।
harageth

2
+1 यह P.SE में एक शानदार शुरुआत है, आशा है कि आप थोड़ी देर के लिए रुकेंगे और इस तरह की गुणवत्ता वाली सामग्री जोड़ते रहेंगे!
जिम्मी हॉफ

1
बिल्कुल सही, संपादित के साथ यह मुझे बहुत अंतर्दृष्टि देता है। धन्यवाद!
बजे लॉरेंट बॉरगुल्ट-रॉय
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.