सबसे पहले, प्रत्येक नोएसक्यूएल स्टोर अलग है। तो यह ओरेकल या एसक्यूएल सर्वर या MySQL के बीच चयन करने की तरह नहीं है। उनके बीच मतभेद विशाल हो सकते हैं।
उदाहरण के लिए, कॉच डीबी के साथ आप विज्ञापन-संबंधी प्रश्न निष्पादित नहीं कर सकते हैं (यदि आप चाहें तो गतिशील प्रश्न)। यह ऑनलाइन - ऑफ़लाइन परिदृश्य में बहुत अच्छा है, और अधिकांश उपकरणों पर चलाने के लिए पर्याप्त छोटा है। इसमें एक विश्वसनीय इंटरफ़ेस है, इसलिए कोई ड्राइवर नहीं, कोई ADO.NET लाइब्रेरी नहीं है। इसे पूछने के लिए आप नक्शा बनाने के लिए मैपराइडस (अब यह नोएसक्यूएल स्पेस में बहुत आम है, लेकिन सर्वव्यापी नहीं है), और ये कई भाषाओं में लिखे गए हैं, हालांकि अधिकांश दस्तावेज जावास्क्रिप्ट के लिए हैं। कोच डीबी को भी दुर्घटनाग्रस्त करने के लिए डिज़ाइन किया गया है, जो कहता है कि कुछ गलत हो जाता है, यह केवल प्रक्रिया को पुनरारंभ करता है (एरलांग प्रक्रिया, या लिंक की गई प्रक्रियाओं का समूह जो कि पूरे कॉच डीबी उदाहरण नहीं है)।
मोंगोडीबी को अत्यधिक प्रदर्शन करने के लिए डिज़ाइन किया गया है, ड्राइवर हैं, और इस वजह से .NET दुनिया में बहुत से लोगों के लिए छलांग लगती है। मेरा मानना है कि हालांकि दुर्घटना स्थितियों में डेटा खोना संभव है (यह कॉच डीबी करता है लिखने के आसपास लेनदेन संबंधी गारंटी के समान स्तर की पेशकश नहीं करता है)।
अब ये दोनों दस्तावेज़ डेटाबेस हैं, और इस तरह वे साझा करते हैं कि उनका डेटा असंगठित है। कोई सारणी नहीं है, कोई परिभाषित स्कीमा नहीं है - वे स्कीमालेस हैं। हालांकि वे एक महत्वपूर्ण मूल्य स्टोर की तरह नहीं हैं, क्योंकि वे जोर देते हैं कि आपके द्वारा जारी किए जाने वाले डेटा उनके लिए समझदार हैं। कॉच डीबी के साथ इसका मतलब है जेएसओएन का उपयोग, और मोंगोडीबी के साथ इसका मतलब है बीएसओएन का उपयोग।
मोंगोडीबी और कॉच डीबी के बीच कई अन्य अंतर हैं और इन्हें नोएसक्यूएल स्पेस में उनके डिजाइन में बहुत करीब माना जाता है!
दस्तावेज़ डेटाबेस के अलावा, उनके नेटवर्क उन्मुख समाधान जैसे नियो 4 जे, कॉलमर स्टोर्स (कॉलम उन्मुख पंक्ति के बजाय ओरिएंटेड हैं, वे डेटा कैसे जारी रखते हैं), और कई अन्य।
मैपरेडस के अलावा, अधिकांश नोएसक्यूएल समाधानों में जो कुछ आम है, वह यह है कि वे डेटाबेस से संबंधित नहीं हैं, और बहुमत एसक्यूएल स्टाइल सिंटैक्स का उपयोग नहीं करते हैं। विशिष्ट रूप से पूछताछ एसक्यूएल की घोषणात्मक शैली की बजाय प्रोग्रामिंग के एक अनिवार्य तरीके का पालन करती है।
एक और आम तौर पर आम विशेषता यह है कि पूर्ण स्थिरता, आमतौर पर संबंधपरक डेटाबेस द्वारा प्रदान की जाती है, स्थिरता के अंतिम मॉडल के लिए व्यापार की जाती है।
नोएसक्यूएल समाधान का उपयोग करने वाले किसी को भी मेरी सलाह सबसे पहले वास्तव में उनकी आवश्यकताओं को समझना होगा, एसएलए को समझें (विलंबता का किस स्तर की आवश्यकता है; यह विलंबता समाधान समाधान के रूप में कैसे रहनी चाहिए; किस पैमाने का भार अनुमानित है; लोड लगातार संगत है या यह स्पाइक होगा; उपयोगकर्ताओं को डेटा के बारे में कितना सुसंगत होना चाहिए, जब वे पूछते हैं तो वे हमेशा अपने स्वयं के लिखते हैं, क्या उनके लेखन तुरंत अन्य सभी उपयोगकर्ताओं के लिए दृश्यमान होना चाहिए; आदि। ..)। समझें कि आपके पास यह सब नहीं हो सकता है, ब्रूअर्स सीएपी थोरम पर पढ़ें, जो मूल रूप से कहता है कि आप पूर्ण स्थिरता, 100% उपलब्धता नहीं हो सकते हैं, और विभाजन सहिष्णु हो सकते हैं (नोड्स संवाद नहीं कर सकते हैं)। फिर विभिन्न नोएसक्यूएल समाधानों को देखें और उन लोगों को खत्म करना शुरू करें जो आपकी आवश्यकताओं को पूरा करने के लिए डिज़ाइन नहीं किए गए हैं, समझते हैं कि एक रिलेशनल डेटाबेस से कदम छोटा नहीं है और इसके साथ जुड़ी लागत है (मुझे एक संगठन को स्थानांतरित करने की लागत मिली है उस दिशा में, बैठकों, चर्चाओं, आदि के संदर्भ में ... खुद को बहुत अधिक है, संभावित लाभ के अन्य क्षेत्रों पर ध्यान केंद्रित करना)। अधिकांश समय आपको ओआरएम की आवश्यकता नहीं होगी (उस समीकरण का आर भाग अभी गायब हो गया है), कभी-कभी केवल बाइनरी सीरियलाइजेशन ठीक हो सकता है (उदाहरण के लिए डीबी 4 ओ जैसे कुछ या एक कुंजी-मूल्य स्टोर के साथ), न्यूटॉन्सॉफ्ट JSON जैसी चीजें/बीएसओएन लाइब्रेरी ऑटोमैपर के रूप में मदद कर सकता है। मुझे लगता है कि सी # 3 थीरे के साथ काम करना एक गतिशील भाषा के साथ काम करने की तुलना में एक निश्चित लागत है, जैसे कि पाइथन कहते हैं। सी # 4 के साथ यह डीएलआर से ExpandoObject और गतिशील जैसी चीजों के साथ थोड़ा सुधार कर सकता है।
अपने 3 विशिष्ट प्रश्न पर देखने के लिए, सभी के साथ यह NoSQL समाधान आप को अपनाने पर निर्भर करता है, इसलिए कोई भी जवाब है, संभव है बहुत सामान्य शब्दों में हालांकि कि चेतावनी के साथ,:
तो बने ऑब्जेक्ट (या कुल मिलाकर अधिक संभावना), आपके जॉइन आमतौर पर कोड में होंगे, हालांकि आप MapReduce के माध्यम से इनमें से कुछ कर सकते हैं।
फिर, यह निर्भर करता है, लेकिन सोफे के साथ आप किसी विशिष्ट संसाधन के विरुद्ध या मैपरेडस व्यू के विरुद्ध HTTP पर एक GET निष्पादित करेंगे।
अधिकतर कुछ भी नहीं। सीरियलाइजेशन, deserialisation परिदृश्यों के लिए बस एक नजर रखें। मुझे मिली कठिनाई यह है कि आप अपने कोड के संस्करणों को कैसे प्रबंधित करते हैं। यदि संपत्ति पूरी तरह से एक इंटरफेस (जीयूआई, वेब सेवा) को धक्का देने के लिए है तो यह एक समस्या से कम हो जाती है। यदि संपत्ति आंतरिक स्थिति का एक रूप है जो व्यवहार पर भरोसा करेगी, तो यह अधिक कठिन हो सकती है।
उम्मीद है कि यह मदद करता है, शुभकामनाएँ!
इस उत्तर में अपना समय निवेश करने के लिए धन्यवाद। आपने कुछ चीजों को स्पष्ट करने में मदद की है। मैं सीखने की अवस्था के कारण मोंगो डीबी पर बारीकी से देख रहा हूं। मैं वास्तव में MapReduce में आने की उम्मीद कर रहा हूँ। मजाक जैसा लगता है। –
मदद करने में खुशी हुई, मैं ट्विटर @NeilRobbins पर हूं, यह जानने में रुचि हो कि आप कैसे प्राप्त करते हैं :) – Neil