एक रिलेशनल डीबी पर एक कुंजी-मूल्य डेटा स्टोर कब चुनता है? एक या दूसरे का निर्णय लेने में क्या विचार चलते हैं? दोनों बेहतरीन मार्गों का मिश्रण कब होता है? यदि आप कर सकते हैं तो उदाहरण प्रदान करें।एक कुंजी-मूल्य डेटा स्टोर बनाम एक और पारंपरिक संबंध डीबी का उपयोग कब करें?
मेरे अनुभव में, यदि आप पारंपरिक बनाम गूढ़ अभ्यासों का उपयोग करना चाहते हैं या नहीं, तो पारंपरिक पूछें। जबकि गूढ़ प्रथाएं सेक्सी, चुनौतीपूर्ण और मजेदार हैं, 99.9 99% आवेदन पारंपरिक दृष्टिकोण के लिए कहते हैं।
के साथ संबंध है केवी बनाम संबंधपरक करने, प्रश्न आप पूछ किया जाना चाहिए:
क्यों मैं इस स्थिति के लिए एक संबंधपरक मॉडल का उपयोग नहींचाहेगा: ...
चूंकि आपने परिदृश्य का वर्णन नहीं किया है, इसलिए किसी के लिए यह बताना असंभव है कि आपको इसका उपयोग क्यों नहीं करना चाहिए। केवी के लिए "सभी को पकड़ें" कारण स्केलेबिलिटी है, जो अब कोई समस्या नहीं है। क्या आप अनुकूलन के नियम जानते हैं?
केवी एक अत्यधिक scalability कि सबसे अधिक संभावना आपके आवेदन के लिए पूरी तरह से अनावश्यक हो जाएगा करने के लिए अनुकूलित समाधान है।
यह टिप्पणी प्रश्न का उत्तर देने में विफल रहता है। किसी और रिलेशनल डीबी पर केवी स्टोर का उपयोग कब और क्यों करेगा? – aridlehoover
एक पारंपरिक संबंधपरक डेटाबेस में एक बिंदु से परे स्केलिंग समस्याएं हैं। जहां वह बिंदु है, उस पर निर्भर करता है कि आप क्या करने की कोशिश कर रहे हैं।
क्लाउड कंप्यूटिंग के आपूर्तिकर्ताओं के सभी (अधिकांश?) कुंजी-मूल्य डेटा स्टोर प्रदान कर रहे हैं।
हालांकि, यदि आपके पास एक जटिल डेटा संरचना के साथ एक उचित आकार का आवेदन है, तो एक रिलेशनल डेटाबेस का उपयोग करने से प्राप्त समर्थन आपके विकास लागत को कम कर सकता है।
मैं इंगित करता हूं कि यह बिंदु बहुत बड़ा है, मुझे कई बहु-टेराबाइट डेटाबेस पता है जो बहुत अच्छी तरह से चलते हैं (उन्हें उचित रूप से डिज़ाइन और प्रबंधित करना होगा और सही हार्डवेयर को स्केल करना होगा)। – HLGEM
कुंजी-मूल्य, हेरार्किकल, मानचित्र-कमी, या ग्राफ डेटाबेस सिस्टम कार्यान्वयन रणनीतियों के बहुत करीब हैं, वे भौतिक प्रतिनिधित्व से भारी बंधे हैं। इनमें से किसी एक को चुनने का प्राथमिक कारण यह है कि यदि कोई आकर्षक प्रदर्शन तर्क है और यह आपकी डेटा प्रोसेसिंग रणनीति को बहुत करीब से फिट करता है। सावधान रहें, आमतौर पर इन प्रणालियों के लिए व्यावहारिक व्यावहारिक नहीं हैं, और आप समय से पहले अपने प्रश्नों का निर्णय लेने से बेहतर हैं।
रिलेशनल डाटाबेस सिस्टम अंतर्निहित भौतिक प्रतिनिधित्व और प्रसंस्करण रणनीतियों से तार्किक, व्यापार उन्मुख मॉडल अलग करने की कोशिश। यह अलगाव अपूर्ण है, लेकिन अभी भी काफी अच्छा है। तथ्यों को संभालने और तथ्यों के संग्रह से विश्वसनीय जानकारी निकालने के लिए रिलेशनल सिस्टम बहुत अच्छे हैं। संबंधपरक सिस्टम भी एड-हॉक क्वेरी, जो अन्य प्रणालियों पर बेहद खराब हैं पर महान हैं। यह व्यापारिक दुनिया और कई अन्य स्थानों में एक अच्छा फिट है। यही कारण है कि रिलेशनल सिस्टम इतने प्रचलित हैं।
यदि यह एक व्यावसायिक अनुप्रयोग है, एक संबंधपरक प्रणाली लगभग हमेशा जवाब है। अन्य प्रणालियों के लिए, यह शायद इस सवाल का जवाब है। यदि आप एक डाटा प्रोसेसिंग समस्या के और अधिक, बातें होती हैं की जरूरत है कि के कुछ पाइप लाइन की तरह है और आप डेटा का भारी मात्रा में है, और आप सामने आपके प्रश्नों के सभी जानते हैं, तो एक और प्रणाली आप के लिए सही हो सकता है।
यदि आपका डेटा बस चीजों की एक सूची है और आप प्रत्येक आइटम के लिए एक अद्वितीय पहचानकर्ता प्राप्त कर सकते हैं, तो एक केवीएस एक अच्छा मैच है। वे ताजा कंप्यूटर विज्ञान में सीखे गए सरल डेटा संरचनाओं के करीबी कार्यान्वयन हैं और जटिल संबंधों की अनुमति नहीं देते हैं।
एक साधारण परीक्षण: क्या आप अपने डेटा और उसके सभी रिश्तों को एक लिंक्ड सूची या हैश टेबल के रूप में प्रस्तुत कर सकते हैं? यदि हां, तो एक केवीएस काम कर सकता है। यदि नहीं, तो आपको एक आरडीबी चाहिए।
आपको अभी भी एक केवीएस खोजने की ज़रूरत है जो आपके पर्यावरण में काम करेगी। केवीएस के लिए समर्थन, यहां तक कि प्रमुख भी, पोस्टग्रेएसक्यूएल और माईएसक्यूएल/मारियाडीबी के कहने के लिए कहीं भी नहीं है।
मुझे उपरोक्त टिप्पणी पसंद नहीं है। ऐसा लगता है कि आप Google/याहू/ट्विटर को छोड़कर किसी को भी सुझाव नहीं दे रहे हैं NOSQL का उपयोग करना चाहिए। क्या बकवास है। –