कुंजी-मूल्य आधारित डेटाबेस, क्या कोई मुझे बता सकता है कि व्यावहारिक रूप से उनका उपयोग कैसे करें?

Question

कुंजी/मूल्य आधारित डेटाबेस के लिए एक बड़ा धक्का प्रतीत होता है, जो मुझे लगता है कि memcache होना चाहिए।

क्या मूल्य आमतौर पर कुछ प्रकार के संग्रह या एक्सएमएल फ़ाइल है जो अधिक सार्थक डेटा रखेगा?

यदि हां, तो क्या यह आमतौर पर डेटा को deserialize करने के लिए तेजी से तेजी से जुड़ता है और परंपरागत रूप से जॉइन करने के लिए और एक पंक्ति आधारित परिणाम सेट लौटने वाली टेबल पर चयन करता है?

Answer 1

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

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

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

Answer 2

मुझे कुंजी/मूल्य डीबीएस के साथ बहुत अधिक अनुभव नहीं है, इसलिए नमक के अनाज के साथ मैं जो कहता हूं उसे ले लो।

इसके साथ, पहली बात यह है कि मुझे यह इंगित करना चाहिए कि memcached एक कुंजी/मान डेटाबेस नहीं है। एक डेटाबेस का मतलब है कि किसी प्रकार की सतत दुकान, जो memcached नहीं है। मेमकैच का उद्देश्य एक डेटाबेस को वास्तविक डेटाबेस में सहेजने के लिए एक अस्थायी स्टोर होना है।

उसके अलावा, मेरी समझ है कि आप एक कुंजी/मान डेटाबेस के साथ अपने आरडीबीएमएस को बदलने के लिए सक्षम होने के लिए नहीं जा रहे हैं है। वे असंगठित डेटा या अन्य डेटा के लिए सबसे अच्छे होते हैं जहां आप संग्रहीत करने की आवश्यकता वाले सभी विशेषताओं को नहीं जानते हैं। यदि आपको अत्यधिक संरचित डेटा स्टोर करने की आवश्यकता है, तो आप पारंपरिक आरडीबीएमएस से ज्यादा बेहतर नहीं कर सकते हैं।

Answer 3

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

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

ये अनुमान दोनों गलत हैं: (वेब ​​साइटों के पीछे वाले भी) सभी डेटाबेस की 99.9% अमेज़न और गूगल के रूप में ही गेंद पार्क में नहीं हैं - परिमाण के कई आदेशों के भीतर नहीं। इस 99.9% के लिए, कुछ भी नहीं बदला है, रिलेशनल डेटाबेस अभी भी ठीक काम करते हैं।

Answer 4

वे जटिल संरचित डेटा हो सकते हैं जिन्हें deserialization की आवश्यकता है। वे आपके आरडीबीएमएस की तरह ही सरल निश्चित आकार के रिकॉर्ड भी हो सकते हैं। लाभ का एक हिस्सा यह है कि आप स्वयं को यह निर्णय लेते हैं। जब आप अपने डेटाबेस को अनुकूलित कर रहे हों, तो आप SQL तक क्या कर सकते हैं तक सीमित नहीं हैं।

जिस तरह से आप पूछते हैं वह इसे शामिल होने की तरह लगता है या deserialization हमेशा बाधा होगी। लेकिन किसी भी डेटाबेस में, चीजें कभी भी सरल नहीं होती हैं। यदि आप वास्तव में चाहते हैं, तो आप अपने आरडीबीएमएस में भी डिमॉर्मलाइज्ड डेटा डाल सकते हैं, या एक कुंजी-वैल्यू डेटाबेस के शीर्ष पर आरडीबीएमएस इंटरफ़ेस लिख सकते हैं।