NoSQL SQL से अधिक तेज़ क्यों है?

48

हाल ही में मुझसे पूछा गया था:

NoSQL SQL से अधिक तेज़ क्यों है?

मैं प्रश्न के आधार से सहमत नहीं था ... यह मेरे लिए व्यक्तिगत रूप से बकवास है। मैं SQL के बजाय NoSQL का उपयोग करके किसी भी प्रदर्शन को बढ़ावा नहीं देख सकता। हो सकता है कि एसक्यूएल नॉएसक्यूएल पर हो, लेकिन उस तरह से नहीं।

क्या मुझे NoSQL के बारे में कुछ याद आ रहा है?

performance nosql

— CND
स्रोत

3

यदि आप एक प्रदर्शन को बढ़ावा नहीं देख सकते हैं, तो आप यही कहते हैं। तथ्य यह है कि अधिकांश NoSQL समाधान एक संबंधपरक डेटाबेस के ACID गुणों में से एक (या अधिक) को छोड़ देते हैं, इसलिए वे कम करते हैं।

— ओड

1

कुछ वर्कफ़्लोज़ (और डेटा संरचनाएँ) हैं जिन्हें आसानी से पारंपरिक ACID- सक्षम रिलेशनल डेटाबेस में मैप नहीं किया जा सकता है। उन लोगों के लिए, आप NoSQL डेटाबेस का उपयोग करके बहुत बड़ा प्रदर्शन बढ़ा सकते हैं । यदि, हालांकि, आप बस एक मौजूदा (अच्छी तरह से डिजाइन) SQL DB लेते हैं और इसे NoSQL डेटाबेस में डालते हैं, तो आपका प्रदर्शन निश्चित रूप से पीड़ित होगा।

— जोकिम सॉउर

1

इसका उत्तर है: क्या यह तेजी से स्थापित किया गया है? और किस तेजी से? विकास का समय? समय पढ़ें? समय लिखें? किस प्रकार का लेखन? हम इसकी तुलना किससे कर रहे हैं? बहु-तालिका प्रश्न? में शामिल?

— रॉल्फ

65

आसपास कई NoSQL समाधान हैं, प्रत्येक अपनी ताकत और कमजोरियों के साथ, इसलिए निम्नलिखित को नमक के एक दाने के साथ लिया जाना चाहिए।

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

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

इसके अलावा, कई NoSQL समाधानों में, मनमाने ढंग से जुड़ना असंभव है, इसलिए मनमाने ढंग से प्रश्न करना। कुछ डेटाबेस, जैसे CouchDB, आपको उन प्रश्नों से आगे सोचने की आवश्यकता है, जिनकी आपको आवश्यकता है और उन्हें DB के अंदर तैयार करेंगे।

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

— एंड्रिया
स्रोत

4

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

— मुर्दाघर।

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

— एंड्रिया

3

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

— मुर्दाघर।

1

क्या होगा अगर आपके पास 5,000,000 मिलियन डेटा की पंक्तियाँ हैं और आप उन सभी से किसी न किसी शर्त पर टिप्पणी प्राप्त करना चाहते हैं। यदि आप एसक्यूएल के साथ तालिका के टिप्पणी क्षेत्र पर कोई सूचकांक रखते हैं तो क्या यह तेज नहीं होगा? पूर्ण-पाठ अनुक्रमण इसमें और सुधार करेगा।

— jwize

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

— जूल्स

27

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

इसलिए अगर कोई आपसे इंटरव्यू पर ऐसा सवाल करता है, तो इसका जवाब होना चाहिए।

— जश्न
स्रोत

4

अगर NoSQL की एक हत्यारा सुविधा है, तो मैं कहूंगा कि यह स्केलेबिलिटी है। इसीलिए फेसबुक और गुगल्स इसका इस्तेमाल करते हैं। डेटा की विशाल मात्रा के कारण। NoSQL: जब आपको भारी मात्रा में डेटा से निपटना होता है।

— Pieter B

16

'NoSQL' (या अधिक सटीक: गैर-संबंधपरक) डेटाबेस गति के लिए पारंपरिक डेटाबेस की कुछ विशेषताओं को छोड़ देते हैं, लेकिन क्षैतिज स्थिरता के लिए अधिक महत्वपूर्ण हैं।

लापता विशेषताएं ठोस उत्पाद पर निर्भर करती हैं, सामान्य रूप से पूर्ण एसीआईडी संपत्तियों में या यहां तक कि परिचालन में शामिल होने का समर्थन नहीं किया जाता है। यह बढ़े हुए प्रदर्शन के लिए मूल्य है।

— कार्ल
स्रोत

1

NoSQL को गैर-संबंधपरक बताना अधिक सटीक नहीं है। अन्य पुराने गैर-संबंधपरक DB हैं जो NoSQL श्रेणी में नहीं आते हैं। NoSQL का मतलब केवल गैर-संबंधपरक से बहुत अधिक है। इसे आगे की जानकारी के लिए पढ़ें: martinfowler.com/bliki/NosqlDefinition.html

— eddyP23

8

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

— Eelco
स्रोत

हां, यह एक कंबल का बयान है, और अगर हम इसे सच मानते हैं, तो सवाल का जवाब है: यह निर्भर करता है।

— रॉल्फ

5

NoSQL डेटाबेस आमतौर पर केवल तभी समझ में आता है जब आप अपने डेटा को उनके आसपास डिज़ाइन करते हैं।

यदि आप उन्हें केवल RDBMS रिप्लेसमेंट के रूप में उपयोग करने का इरादा रखते हैं, तो आपको अधिक के बजाय कम प्रदर्शन मिल सकता है, खासकर यदि आपके पास पर्याप्त मात्रा में रैम के साथ सर्वर के लिए भुगतान करने के लिए पर्याप्त बजट नहीं है।

इस लेख को देखें जिसमें MongoDB के साथ MySQL डिस्क स्थान उपयोग की तुलना की गई है: http://blog.trackerbird.com/content/mysql-vs-mongodb-disk-space-usage

— क्लिफर्ड
स्रोत

3

कौन सा NoSQL डेटाबेस? कौन सा SQL डेटाबेस? अगर कोई आपसे कहे कि NoSQL SQL से तेज है तो आपको चलना चाहिए। या बेहतर अभी तक यह वीडियो देखें:

http://www.youtube.com/watch?v=b2F-DItXtZs

मैं यह नहीं कहूंगा कि NoSQL के बारे में दावा की गई आधी बातें गलत हैं, लेकिन मैं कहूंगा कि वहाँ NoSQL बहुत से लोग हैं, जो वास्तव में इसे बहुत अच्छी तरह से नहीं समझते हैं।

एसक्यूएल की अपनी सीमाएं (बेशक) हैं, लेकिन यह एक बहुत ही परिपक्व तकनीक है, जिसे अच्छी तरह से समझा जाता है, और इसमें डेवलपर्स का एक बड़ा पूल है जो समझते हैं कि इसका उपयोग कैसे किया जाए। मैं NoSQL के सभी रूपों के लिए एक ही नहीं कह सकता।

— ज़चारी का
स्रोत

-2

NoSql स्तंभ उन्मुख डेटाबेस द्वारा समर्थित जहां RDBMS पंक्ति उन्मुख डेटाबेस है ... और उदाहरण के लिए कहें कि हमारे पास नाम, आयु, वेतन, पता, EmployeeId आदि के साथ एक कर्मचारी तालिका है ... हम MySql (RDBMS समर्थन) और HBase में एक ही तालिका रखते हैं (NoSQL समर्थन)। यदि कोई ग्राहक / ग्राहक 1Lakh कर्मचारियों के रिकॉर्ड से औसत आयु या वेतन विवरण प्राप्त करने के लिए एक प्रश्न लिखता है ... तो क्या होता है?

RDBMS में यह प्रत्येक पंक्ति के चारों ओर जाएगा और मूल्य और राशि एकत्र करेगा और परिणामस्वरूप विभाजित करेगा। जब यह Columnar डेटाबेस की बात आती है तो सभी एक लाख पंक्ति पुनरावृत्तियों के बारे में चिंता करने की कोई आवश्यकता नहीं है। लेकिन केवल एक पंक्ति से निपटें जो गणना करने के लिए तेज़ है। तो इस तरह कभी-कभी NoSQL SQL की तुलना में तेज होता है। इस मामले में NoSQL ACID शिकायतों के लायक नहीं है!

— किरन तेजा अविवरु
स्रोत

2

मैंने फॉर्मेटिंग थोड़ी तय कर ली है, हालांकि मुझे यकीन नहीं है कि आप दोनों के बीच क्या करने की कोशिश कर रहे हैं। और ACID हमेशा RDBMS द्वारा समर्थित नहीं है।

-3

डेटाबेस के आसपास के सिद्धांत को भूल जाओ .... बिंदु एक बार जब आप अपनी क्वेरी को समझते हैं, तो आप डेटा को एक सटीक तरीके से nosql डेटाबेस में सहेज सकते हैं जिसमें वे वास्तव में आपके आवेदन में उपयोग किए जाते हैं ...।

उदाहरण के लिए इस उदाहरण को लें, यू के पास कई ऑर्डर के साथ एक ग्राहक मॉडल है और प्रत्येक ऑर्डर के साथ कई आइटम जुड़े हैं, तो उनके पास बाद की खरीदारी के लिए कई सहेजे गए आइटम भी हैं ... यदि आप एक बड़े ईकॉमर्स स्टोर हैं, जिसमें 10 मिलियन ग्राहक और 50 हैं मिलियन ऑर्डर। और वह ग्राहक अपने डैशबोर्ड में प्रवेश करता है जो इस सटीक डेटा को प्रदर्शित करता है कि ग्राहक को खोजने, ऑर्डर और प्रत्येक लाइन आइटम और सहेजे गए आइटम से जुड़ने के लिए एक sql डेटाबेस को कितना काम करने की आवश्यकता है। एक sql डेटाबेस में यह सभी डेटा किसी न किसी तरह से जुड़ने की आवश्यकता होगी ... या u, urc डेटाबेस में एक संग्रह बना सकता है जिसे userache कहा जाता है और इस डेटा को वास्तव में आप इसे वास्तविक जीवन में कैसे उपयोग करते हैं, इसे बचा सकते हैं। इसलिए यह सभी डेटा को वापस लाने के लिए किसी एकल फ़ील्ड [आईडी] पर एक ही क्वेरी हो सकती है। उसके ऊपर nosql डेटाबेस नहीं है '

तो क्या एक sql db क्वेरी एक एकल Id फ़ील्ड को उतनी ही तेजी से कर सकती है यदि nosql से तेज़ नहीं है? हां, लेकिन एक तालिका और एक क्षेत्र को क्वेरी करके एक sql डेटाबेस आपको आवश्यक सभी डेटा वापस कर सकता है? नहीं, जब तक कि आप कुछ नहीं करते हैं जैसे कि बड़े टेक्स्ट फ़ील्ड के अंदर Json में डेटा को सहेजना। लेकिन अब वह डेटा संभावित भविष्य के उपयोग के लिए क्वेरी-सक्षम नहीं है।

— स्टीफन पेरी
स्रोत