स्केलेबिलिटी समस्याओं वाले रिलेशनल डेटाबेस क्यों हैं?

Question

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

धन्यवाद।

Answer 1

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

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

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

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

Answer 2

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

Answer 3

एक बिंदु मुझे नहीं लगता कि लोग सोचते हैं कि एसक्यूएल पार्सिंग में महत्वपूर्ण ओवरहेड है।

यह में से एक कारण है कि तैयार कथन बहुत उपयोगी हैं। हालांकि, सीजीआई शैली अनुप्रयोगों (लघु रनटाइम, कई उदाहरण) जैसे कि अधिकांश PHP अनुप्रयोगों में, तैयार बयानों को अभी भी एक बार पार्स किया जाना है।

अक्सर डेटाबेस सर्वर स्वयं वास्तव में पर्याप्त तेज़ होते हैं, यह सिर्फ SQL पार्सिंग में ओवरहेड होता है। योशिनोरी मत्सुन्नोबू के पास article है जो handlerSocket को लागू करने के बारे में है, जो MySQL + InnoDB के लिए एक नोएसक्यूएल कनेक्टर है जो कथित रूप से प्राथमिक कुंजी लुकअप के लिए प्रति सेकंड 750,000 प्रश्न प्राप्त कर सकता है, जो प्रति सेकंड ~ 420,000 प्रश्नों से बेहतर है, जिसे उन्होंने memcached के लिए कहा था।

Answer 4

दो अलग-अलग प्रकार के चौराहे की कल्पना करो।

एक यातायात रोशनी या यातायात रोशनी या पुलिस अधिकारी यातायात को विनियमित करते हैं, चौराहे पर गति सीमित गति पर है, और वहां एक घड़ी है जो सटीक रूप से किस कार पर चली गई है, और किस दिशा में यह चल रहा है।

दूसरे में से कोई भी नहीं है और जो कोई भी गति से चलने पर क्रॉस रोड पर आता है, बस इसमें डाइव्स और जितनी जल्दी हो सके से गुजरना चाहता है।

पूर्व कोई पारंपरिक डेटाबेस इंजन है। चौराहे डेटा ही है। कारें लेन-देन हैं जो डेटा तक पहुंचना चाहते हैं। यातायात रोशनी या पुलिस अधिकारी डीबीएमएस है। वॉचडॉग लॉग और पत्रिकाओं को रखता है।

उत्तरार्द्ध एक नोएसिड प्रकार का इंजन है।

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

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

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

एक स्पष्टीकरण के रूप में रंगीन पर्याप्त?