मैं वेब अनुप्रयोगों को विकसित करने के लिए PHP का उपयोग कर रहा हूं। मैंने MySQL का उपयोग अपने आरडीएमएस के रूप में किया है। कई चीजों के लिए एक आरडीएमएस काम करता है, और अन्य चीजों के साथ सामान्यीकरण द्वारा कई समस्याओं का समाधान किया जा सकता है। लेकिन कुछ स्थितियां सिर्फ आरडीएमएस के साथ अच्छी तरह से काम नहीं करती हैं, इसलिए नोएसक्यूएल जैसे अन्य समाधान तैयार किए गए हैं।क्या मुझे MySQL के बजाय NoSQL का उपयोग करना चाहिए?
मुझे यह स्पष्ट नहीं है कि कौन सी परिस्थितियां नोएसक्यूएल बेहतर फिट होंगी। विभिन्न अलग-अलग NoSQL विकल्पों में से कुछ अलग-अलग कैसे होते हैं, किसी दूसरे की तुलना में कौन सी स्थितियां बेहतर हो सकती हैं, और जो PHP 5.3 या ऊपर (API wise) के साथ संगत हैं?
तो मैं नोएसक्यूएल सर्वर सॉफ़्टवेयर की एक सूची की तलाश कर रहा हूं जिसका उपयोग मैं कर सकता हूं (जैसे कि MySQL को आरडीएमएस के रूप में) और मैं दूसरे (किसी भी हाइब्रिड?) पर एक का उपयोग क्यों करूंगा। RDMS के बजाय NoSQL का उपयोग करके हल की गई समस्याओं के विशिष्ट उदाहरण भी।
अंत में, मुझे पता है कि अगर एक NoSQL सर्वर इस स्थिति में बेहतर काम करेगा हैं:
डेटा जहां प्रत्येक पंक्ति विभिन्न स्तंभों/क्षेत्रों में हो सकता है की एक तालिका। एक पंक्ति में 5 कॉलम हो सकते हैं, दूसरे में 5 पूरी तरह से अलग कॉलम हो सकते हैं, और दूसरे के पास 10 हो सकते हैं। लेकिन इन सभी पंक्तियों में से एक प्राथमिक ऑटो-वर्धित संख्यात्मक आईडी है। लाखों "पंक्तियां"।
(बस उपर्युक्त के साथ मैं मान रहा हूं कि नोएसक्यूएल सही है क्योंकि यह वस्तुओं का संग्रह है, तालिका में पंक्तियां नहीं। एआई प्राथमिक कुंजी के बारे में निश्चित नहीं है)।
एक आरडीएमएस में आप सबसे अधिक इस्तेमाल किए जाने वाले कॉलम बना सकते हैं, फिर PHP के क्रमबद्ध/अन्य कॉलम स्टोर करने के लिए unserialize का उपयोग करें .. लेकिन यह बहुत अक्षम है और जटिलताओं को जटिल करता है जब आपको इस कॉलम पर मौजूद कॉलम पर रिपोर्ट चलाने पड़ते हैं " serialized सरणी ", जैसे कि" birthday_pledge "नामक कॉलम की सभी पंक्तियों पर एक एसयूएम (प्रत्येक पंक्ति के साथ जहां इसका उपयोग किया जाता है)।
मेरी स्थिति में प्राथमिक 0 के अलावा प्रत्येक "कॉलम" कस्टम और उपयोगकर्ता परिभाषित है। लेकिन मुझे इन "कॉलम" पर रिपोर्ट (रकम, फ़िल्टर, खोज) चलाने में सक्षम होना चाहिए। इसलिए यदि नोएसक्यूएल समाधान नहीं है, तो केवल एक चीज जिसे मैं करने के बारे में सोच सकता हूं वह उपयोगकर्ता के लिए कस्टम टेबल बना रहा है (हालांकि जटिल हो सकता है)।
मैं यह भी इंगित करना चाहता हूं कि स्केलेबिलिटी (एकाधिक डेटाबेस सर्वर, रिडंडेंसी और फेलओवर) बहुत महत्वपूर्ण है।
यहां देखें: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis – zerkms
मैं सुझाव दूंगा कि आपके द्वारा वर्णित डेटा के लिए एक संबंधपरक डेटा मॉडल में डेटा के मिलान से कई तालिकाओं की संभावना होगी आईडी द्वारा विभिन्न प्रकार। एक उच्च सामान्य अर्थ (जिसे मैं सीधे इस्तेमाल नहीं किया जाएगा) में, आपके पास एक तालिका 'integer_values', 'text_values', आदि हो सकती है जो आइटमों से उनकी प्राथमिक कुंजी से जुड़े होते हैं। –
हम वास्तव में वर्तमान में एक सामान्यीकृत तालिका का उपयोग करते हैं जो 'आईडी',' टेक्स्ट' है, लेकिन तालिका में लाखों पंक्तियां हैं और रिपोर्ट करना असंभव है। मैं ऐप को कस्टम टेबल बनाने पर विचार कर रहा हूं, जब तक कि हमारी स्थिति के लिए आरडीएमएस के लिए नोएसक्यूएल बेहतर समाधान न हो। – Luke