NoSQL का उपयोग करें केस परिदृश्य या जब NoSQL का उपयोग करें [बंद]

Question

सभी प्रचार के साथ यह कब उपयोग करने के लिए विश्वसनीय जानकारी प्राप्त करना वास्तव में कठिन लगता है। इसलिए मैंने निम्नलिखित प्रश्नों का उत्तर दिया, और मुझे खेद है कि ये वास्तव में पहले से गूंगे प्रश्न हैं:

1. क्या मुझे उपयोगकर्ता डेटा के लिए NoSQL का उपयोग करना चाहिए? जैसे प्रोफाइल, यूजरनेम + पासवर्ड इत्यादि।
2. क्या मुझे महत्वपूर्ण सामग्री के लिए NoSQL का उपयोग करना चाहिए? जैसे लेख, ब्लॉग पोस्ट, उत्पाद सूची इत्यादि।

मैं नहीं मान रहा हूँ? और मुझे लगता है कि NoSQL बस जल्दी से सुलभ चीजों के लिए है जिसमें से डेटा खोना ठीक है। लेकिन मैंने यह भी पढ़ा कि NoSQL ऐप में बिल्ट-इन अतिरेक है ताकि मैं डेटा खो न दूं?

इसके अलावा अगर उपरोक्त 2 उदाहरण खराब हैं, तो क्या आप मुझे विशिष्ट व्यावसायिक उपयोग के मामले दे सकते हैं जहां मैं NoSQL का उपयोग करूंगा? मैं बहुत सारे सामान्य विवरण देखता हूं लेकिन वास्तविक दुनिया के बहुत सारे उदाहरण नहीं हैं। केवल वही चीजें जो मैं सोच सकता हूं वे उपयोगकर्ता-से-उपयोगकर्ता संदेश और विश्लेषण हैं।

धन्यवाद!

Answer 1

यह वास्तव में एक "यह निर्भर करता है" थोड़े सवाल है। कुछ सामान्य बिंदु:

• NoSQL आम तौर पर असंरचित / "स्कीमालेस" डेटा के लिए अच्छा है - आमतौर पर, आपको अपने स्कीमा को स्पष्ट रूप से सामने परिभाषित करने की आवश्यकता नहीं होती है और बिना किसी समारोह के बस नए फ़ील्ड शामिल कर सकते हैं
• NoSQL आमतौर पर RDBMS दुनिया में JOINs के लिए कोई समर्थन नहीं होने के कारण एक असामान्य स्कीमा का पक्षधर है। तो आप आमतौर पर एक चपटा, अपने डेटा का निरूपित प्रतिनिधित्व करेंगे।
• NoSQL का उपयोग करने का मतलब यह नहीं है कि आप डेटा खो सकते हैं। अलग-अलग डीबी की अलग-अलग रणनीति होती है। जैसे MongoDB - आप अनिवार्य रूप से यह चुन सकते हैं कि डेटा हानि के लिए प्रदर्शन बनाम संभावित व्यापार को किस स्तर पर रखा जाए - सर्वश्रेष्ठ प्रदर्शन = डेटा हानि के लिए अधिक गुंजाइश।
• NoSQL सॉल्यूशंस को स्केल करना अक्सर बहुत आसान होता है। डेटा को दोहराने के लिए अधिक नोड्स जोड़ने का एक तरीका है a) अधिक स्केलेबिलिटी की पेशकश करता है और बी) यदि एक नोड डाउन होता है तो डेटा हानि के खिलाफ अधिक सुरक्षा प्रदान करता है। लेकिन फिर से, NoSQL DB / कॉन्फ़िगरेशन पर निर्भर करता है। NoSQL का मतलब यह नहीं है कि आप "डेटा लॉस" का अनुमान लगाते हैं।
• आईएमएचओ, जटिल / गतिशील प्रश्नों / रिपोर्टिंग को आरडीबीएमएस से सबसे अच्छी सेवा दी जाती है। अक्सर NoSQL DB के लिए क्वेरी कार्यक्षमता सीमित है।
• इसमें 1 या दूसरी पसंद नहीं है। मेरा अनुभव कुछ उपयोग मामलों के लिए NoSQL के साथ संयोजन में RDBMS का उपयोग कर रहा है।
• NoSQL DBs में अक्सर कई "तालिकाओं" में परमाणु संचालन करने की क्षमता का अभाव होता है।

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

एक उदाहरण के रूप में MongoDb के लिए, अपने उपयोग मामलों की जाँच करें कि वे "अच्छी तरह से अनुकूल" होने का सुझाव देते हैं और MongoDb के "कम अच्छी तरह से अनुकूल" उपयोग करते हैं।

Comments

जॉइन न करने वाले NoSQL के बारे में दावा भ्रामक है। कुछ NoSQL डेटाबेस वास्तव में रिलेशनल डेटाबेस की तुलना में जुड़ने में बहुत बेहतर हैं। कुछ उन्हें बिल्कुल भी समर्थन नहीं करते हैं। यह उत्तर विशेष रूप से NoSQL के बारे में विशेष रूप से MongoDB के बारे में अधिक लगता है।

— एलन प्लम

महान सारांश। @AlanPlum, आप किस विशिष्ट NoSQL डेटाबेस का उल्लेख कर रहे हैं?

— ब्रायन

@ बायरन मैं अरंगबीडीबी ( आरंगोडब.कॉम ) का योगदानकर्ता हूं , जो एक डॉक्यूमेंट डेटाबेस (मोंगोबीडी) और एक ग्राफ डेटाबेस (थिंक नियो 4 जे) का एक मिश्रण है, जिसमें न केवल सस्ते जोड़ हैं, बल्कि असली लेनदेन भी हैं। उस ने कहा, NoSQL डेटाबेस एक सजातीय समूह नहीं हैं और किसी भी NoSQL डेटाबेस से पूरे "श्रेणी" के लिए सामान्यीकरण करना असंभव है।

— एलन प्लम

यदि आप खुद को आरडीबी का उपयोग करने पर विचार कर रहे हैं क्योंकि NoSQL में "जॉइन सपोर्ट नहीं हैं", तो मैं अत्यधिक AWS फिर से इस वीडियो को देखने का सुझाव देता हूं: आविष्कार। संपूर्ण NoSQL दृष्टिकोण को तोड़ता है! मेरी बहुत मदद की। youtu.be/HaEPXoXVf2k

— dillon.harless

Answer 2

मुझे लगता है कि कम से कम इन परिदृश्यों में नोस्कल "अधिक उपयुक्त" है (अधिक अनुपूरक का स्वागत है)

1. अधिक नोड्स जोड़कर क्षैतिज रूप से स्केल करना आसान है।

2. बड़े डेटा सेट पर क्वेरी

   हर दिन ट्विटर पर पोस्ट किए गए कई ट्वीट्स की कल्पना करें। RDMS में, पंक्तियों के लाखों (या अरबों?) के साथ तालिकाओं हो सकती हैं, और आप उन तालिकाओं पर सीधे क्वेरी नहीं करना चाहते हैं, यहां तक ​​कि उल्लेख भी नहीं करते हैं, ज्यादातर समय, जटिल प्रश्नों के लिए टेबल जॉइन की भी आवश्यकता होती है।

3. डिस्क I / O अड़चन

   यदि किसी वेबसाइट को उपयोगकर्ताओं की वास्तविक समय की जानकारी के आधार पर विभिन्न उपयोगकर्ताओं को परिणाम भेजने की आवश्यकता होती है, तो हम शायद दसियों या सैकड़ों हजारों SQL प्रति सेकंड पढ़ने / लिखने के अनुरोध के बारे में बात कर रहे हैं। तब डिस्क i / o एक गंभीर अड़चन होगी।

Comments

मुझे समझ नहीं आया कि # 2 के लिए RDBMS के साथ क्या समस्या हो सकती है। और NoSQL में # 3 के अनुसार कम डिस्क I / O है?

— avi

बकौल @avi, मुझे लगता है कि # 2 के लिए कोई समस्या नहीं है जब तक आप सूचकांक पर तालिकाओं को क्वेरी करते हैं। लाखों पंक्तियाँ? ठीक है, केवल उन अनुक्रमणिकाओं को पुनः प्राप्त करें जिन्हें मैं उपयोग करना चाहता हूं

— Xtreme बाइकर

# 2 और 3 दोनों झूठे हैं। 2 के लिए, मैंने डेटा के आयात / निर्यात पर प्रदर्शन परीक्षण किए हैं और बड़े डेटा आयात और निर्यात पर SQL Server 2014 क्रश मोंगो को देखा है। 3 के लिए, SQL में दृढ़ता से टाइप किया गया डेटा आमतौर पर लेता है (मैंने संपीड़न से पहले 50% से अधिक देखा है) दस्तावेज़ डेटाबेस की तुलना में बहुत कम जगह।

— ब्रायन

हाँ, और यहां तक ​​कि # 1 के लिए, मैं इसे प्राप्त नहीं करता हूं। स्केलिंग अनुबंध सभी प्रमुख rdbms प्रस्ताव के क्लस्टरिंग का हिस्सा है

— सेबस

अगर आपके पास असीमित पैसा है, तो ये तीनों गलत हैं

— Chazt3n