क्या MongoDB मेरे मामले में सही विकल्प है? [बन्द है]

Question

मैं रेल में अपनी पहली वास्तविक परियोजना बनाने जा रहा हूं जिसमें 3 मुख्य भाग से बने वेब ऐप शामिल हैं:

• वह स्थैतिक भाग जहाँ कोई डेटाबेस उपयोग नहीं किया जाता है
• उपयोगकर्ता पंजीकरण भाग जिसे डेटाबेस की आवश्यकता होगी और मैं MySQL का उपयोग कर सकता हूं क्योंकि प्रत्येक उपयोगकर्ता की पंक्ति में समान फ़ील्ड होंगे
• "ऐप" जहां उपयोगकर्ता संग्रह में आइटम बनाने, व्यवस्थित करने, संपादित करने ... उन्हें अन्य उपयोगकर्ताओं के साथ साझा करने में सक्षम होंगे

कई आइटम प्रकार होंगे और प्रत्येक के लिए अलग-अलग विकल्प होंगे उदाहरण के लिए मेरे पास निम्नलिखित विकल्पों के साथ "वीडियो" आइटम हो सकते हैं:

• आईडी
• यूज़र आईडी
• collection_id
• शीर्षक
• मंच (यदि एम्बेडेड)
• url (यदि एम्बेडेड है)
• फ़ाइल नाम (यदि मेरे ऐप पर होस्ट किया गया है)
• फ़ाइल का आकार (आईडी मेरे ऐप पर होस्ट की गई)

और "नक्शा" आइटम:

• आईडी
• यूज़र आईडी
• collection_id
• शीर्षक
• मंच (गूगल मैप्स, बिंग मैप्स ...)
• स्थान
• यूआरएल
• नक़्शे का आकार

जैसा कि आप उपयोगकर्ताओं के लिए कर सकते हैं जब मैं आइटम के लिए MySQL का उपयोग कर सकता हूं, तो MongoDB का लचीलापन उपयोगी हो सकता है क्योंकि प्रत्येक आइटम को अलग-अलग विकल्पों की आवश्यकता हो सकती है तब अन्य आइटम

अब तक मैंने हमेशा PHP और MySQL (छोटी परियोजनाओं के लिए साझा होस्टिंग पर) का उपयोग किया है और स्केलेबिलिटी मेरे लिए एक बिल्कुल नया शब्द है।

मेरे पास सीखने के लिए समय है लेकिन मैं 1 महीने की तरह कुछ करने में सक्षम होना चाहूंगा।

मैंने MongoDB और NoSQL बनाम RDMS और MySQL के बारे में बहुत कुछ पढ़ा है और इसे आज़माने के बाद मुझे यह कहना है कि मुझे पसंद है कि MongoDB कैसे काम करता है: कोई तालिका नहीं, कोई पंक्तियाँ और इसके दस्तावेज़ नहीं जैसे JSON:

• मेरी स्थिति में आप क्या सलाह देंगे? क्यों?
• स्केलेबिलिटी के बारे में MongoDB के साथ समस्याएं हो सकती हैं? यदि हाँ, तो (DB आकार की अवधि में) और क्या ये समस्याएं मेरे ऐप को धीमा कर सकती हैं?

संपादित करें: ऐप कैसे काम करेगा

चूंकि कई लोगों ने यह पूछा है कि मैं ऐप को कैसे काम करना चाहूंगा:

1. एक उपयोगकर्ता साइन अप
2. वह लॉग इन है
3. वह अपना पहला संग्रह बनाता है, जिसमें वह अनंत वस्तुएं बना सकता है
4. आइटम विभिन्न प्रकार के होते हैं और प्रत्येक प्रकार को डेटाबेस में सहेजने के लिए अलग-अलग डेटा की आवश्यकता होती है और आइटम के प्रकार को जोड़ा या संशोधित किया जा सकता है

उपयोगकर्ता इसके अंदर अन्य संग्रह और आइटम बना सकते हैं।

इसलिए हमारे पास उनके अंदर संग्रह और आइटम के लिए CRUD है और प्रत्येक संग्रह / आइटम को एक विशिष्ट उपयोगकर्ता को संदर्भित किया जाता है

MySQL के साथ मुख्य समस्या यह है कि यह एक लचीला स्कीमा नहीं है, इसे हल करने का एक तरीका है (वर्कअराउंड?)।

NoSQL के बारे में सोचकर मुझे केवल संदेह है कि मैं इसमें शामिल होने के बारे में हूं, उदाहरण के लिए एक निश्चित सामंजस्य दिया गया है जिसे मैं उपयोगकर्ता से संबंधित डेटा = संग्रह में user_id फ़ील्ड के साथ पुनर्प्राप्त करना चाहता हूं

संपादित करें: MySQL का उपयोग करने के लिए विचार

वैकल्पिक सेटिंग्स के साथ "आइटम" तालिका में एक फ़ील्ड बनाएं, प्रत्येक सेटिंग को ए द्वारा विभाजित किया गया है | या एक और प्रतीक।

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

तुम क्या सोचते हो? उस समाधान के साथ कोई समस्या है? क्या आपके पास अन्य विचार हैं?

Comments

जब तक आप हमें एक विशेष समस्या के साथ हल करने की कोशिश कर रहे हैं, तब तक प्रौद्योगिकी की सिफारिशों पर मैट्टो प्रश्न विषय से दूर हैं। आपको अपनी परियोजना के बारे में हमें थोड़ी और जानकारी देने की आवश्यकता होगी, और इस कारण से आपको लगता है कि आपको MySQL के अलावा किसी अन्य डेटाबेस का उपयोग करने की आवश्यकता है (जो आप परिचित हैं)। उदाहरण के लिए: क्या कोई मापनीयता संबंधी चिंताएँ हैं, और नई तकनीकों की जाँच के लिए आपके पास कितना समय है। अपने प्रश्न को संशोधित करने पर विचार करें और यदि आप करते हैं, तो इसे मॉडरेशन के लिए ध्वजांकित करें ताकि हम आपके संपादन की समीक्षा कर सकें।

— यनीस

Answer 1

हम आपको तब तक मदद करने में सक्षम नहीं हो सकते जब तक आप हमें यह नहीं बताते कि आप ऐप के साथ क्या करना चाहते हैं। रिलेशनल डेटाबेस कुछ चीजों के लिए अच्छे होते हैं, और NoSQL डेटाबेस दूसरों के लिए अच्छे होते हैं।

जैसा कि किसी ने एक बार मुझे एसओ के यहाँ कहा था:

एक संबंधपरक DB का संबंधपरक भाग कुछ अन्य भागों की तुलना में कहीं अधिक अनुकूलित है

इसका मतलब है कि आप एक रिलेशनल डेटाबेस का उपयोग कर सकते हैं, भले ही वह आपके उपयोग के मामलों में फिट हो। बस इसके लचीलेपन / स्केलेबिलिटी के कारण MongoDB के साथ आगे नहीं बढ़ें। यह विकिपीडिया पर MongoDB के बारे में पहली पंक्ति है:

MongoDB ("विनम्र" से) एक खुला स्रोत दस्तावेज़-उन्मुख NoSQL डेटाबेस सिस्टम है।

क्या आप वास्तव में एक दस्तावेज़-उन्मुख DB का उपयोग करने का इरादा रखते हैं? यदि आपके उपयोग के मामलों में कुछ ग्राफ़िनेस है, तो आप बहुत अच्छी तरह से Neo4j जैसे ग्राफ़ डेटाबेस के लिए जा सकते हैं। या आप बहुत अच्छी तरह से SQL और NoSQL दोनों का एक साथ उपयोग कर सकते हैं जैसा कि कुछ लोग करते हैं।

BTW, मैं एक प्रोजेक्ट भी कर रहा हूं जिसमें मैं SQL और NoSQL दोनों के सर्वश्रेष्ठ भागों का उपयोग करता हूं।

संपादित करें: मैं एक बार फिर कहता हूं:

की जाँच करें Neo4j बनाम Hadoop पर अनुभाग इस लेख। इसे कहते हैं:

सिद्धांत रूप में, Hadoop और अन्य की-वैल्यू स्टोर अपेक्षाकृत फ्लैट डेटा संरचनाओं के साथ संबंधित हैं । यही है, वे साधारण वस्तुओं की पुनरावृत्ति के बारे में अत्यंत तेज और स्केलेबल हैं, जैसे मान, दस्तावेज़ या ऑब्जेक्ट भी।

उसी लेख का उल्लेख करते हुए, क्या आपको वास्तव में एक फ्लैट डेटा संरचना की आवश्यकता है जिसके लिए आप MongoDB जा रहे हैं? यह अंततः आपके विस्तृत उपयोग के मामलों पर निर्भर करता है कि चरण 3 और 4 कैसे प्रदर्शन किया जाएगा।

इसके अतिरिक्त, आप इन प्रश्नों को संदर्भित करना चाहते हैं:

/programming/2124274/mongodb-what-to-know-before-using

/programming/1476295/when-to-use-mongodb-or-other-document-oriented-database-systems

( सुनिश्चित करने के लिए दूसरे प्रश्न के शीर्ष / चयनित उत्तर को देखें। आप इस दुविधा में हैं कि यह अभी हल हो सकता है। )

मुझे लगता है कि इन सवालों में वह सब जानकारी है जो आप जानना चाहते थे। अंत में, यह आप ही हैं, जिन्हें यह तय करना होगा कि यह MongoDb है या कुछ और, हम सिर्फ सिफारिश कर सकते हैं। केवल वे लोग जो आपके विस्तृत उपयोग के मामलों को जानते हैं, आप और आपकी टीम हैं।

संपादित करें (MySQL के भाग के लिए): जैसा कि मैंने समझा है, आप db में कुछ स्टोर करने और उन्हें एक विभाजक के माध्यम से अलग करने की योजना बना रहे हैं। यह 2 समस्याएं प्रस्तुत करता है:

1. आपको किसी भी इनपुट को अतिरिक्त रूप से संभालना होगा जिसमें विभाजक होगा।
2. एक रिलेशनल डेटाबेस का रिलेशनल स्टोरेज भाग स्ट्रिंग मिलान वाले भाग की तुलना में कहीं अधिक अनुकूलित है। मैं ऐसी योजना के लिए नहीं जाऊँगा जहाँ मुझे कुछ विशिष्ट परिणाम प्राप्त करने के लिए डेटाबेस में स्ट्रिंग मिलान करने की आवश्यकता हो। फिर से मैं जोर दे रहा हूं:

   एक संबंधपरक DB का संबंधपरक भाग कुछ अन्य भागों की तुलना में कहीं अधिक अनुकूलित है (जैसे स्ट्रिंग मिलान)

3. बहुस्तरीय विशेषताओं का उपयोग न करें। लोग आमतौर पर उन्हें डराते हैं।

Comments

मुख्य रूप से मैं इसके लचीले स्कीमा के लिए MongoDB का उपयोग करने जा रहा था, लेकिन मुझे कुछ संदेह है क्योंकि इसमें शामिल नहीं है। वैसे भी मेरे ऐप में मेरे पास उपयोगकर्ताओं के लिए एक dtabase होगा और फिर एक मूल creud जहां प्रत्येक तत्व एक उपयोगकर्ता और तत्वों के संग्रह से जुड़ा होता है

— Matteo Pagliazzi

आपको मोंगो के लिए जुड़ने की आवश्यकता नहीं होगी, लेकिन आपको अपने स्कीमा की योजना बनाने की आवश्यकता होगी। यदि आप मोंगो का उपयोग करते हैं तो तालिकाओं के बजाय वस्तुओं के शब्द में सोचें। फिर सोचें कि आप अपनी वस्तुओं तक कैसे पहुंचेंगे।

— ltfishie

Answer 2

मैं इस सवाल को बहुत देखता हूं। यह हमेशा / या के रूप में सोचा जा रहा है। MongoDB एक शानदार नया टूल है। यह कभी-कभी सब कुछ के लिए चमकदार उपकरण के रूप में भी प्रतीत होता है और यह मेरे अनुभव में एक खराब विकल्प हो सकता है।

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

'बड़ी संख्या में आइटम' टुकड़े के लिए, यह वह जगह है जहां आप मूंगफीडीबी का उपयोग करने पर विचार करना चाहते हैं यदि आपकी मात्रा अधिक है, और / या यह ज्यादातर पढ़ता है और / या यह असंरचित डेटा है।

मैं मानगो के स्कीमा-कम लचीलेपन पर आपके निर्णय को आधार नहीं बनाने की सलाह दूंगा। SQL और sql-schemas संरचित डेटा की आवश्यकता से उत्पन्न हुई और ऐसी संरचना के साथ केवल गणना और रूपांतरण करने में सक्षम हैं। मैंने इसे डेटा वेयरहाउस रोल में काम करने के 5 साल से सीखा है। मैं केवल प्रदर्शन के मुद्दे के लिए MongoBD को देखूंगा। यदि आप उपयोगकर्ताओं और अनुरोधों की उच्च मात्रा की उम्मीद कर रहे हैं, तो 100,000 उपयोगकर्ताओं और 20 अनुरोधों को एक सेकंड में कहें, मैं mongoDB का उपयोग करूंगा, अन्यथा मैं कोशिश करूंगा और sql के साथ रहूंगा। कई मामलों में मैं कम मात्रा के लिए mySQL का उपयोग करता हूं, और फिर, वॉल्यूम, आय और बुनियादी ढांचे के रूप में इसका समर्थन करते हैं, ऑरेगॉन पर स्विच करते हैं, मोंगोबीडी में मिश्रण करने से पहले। मैं मानता हूं कि आपको अनुभव करने से पहले वॉल्यूम की समस्याओं से निपटने की कोशिश नहीं करनी चाहिए, हालांकि अगर आपके पास यह विचार है कि आप कहां जा रहे हैं और डॉन ' टी चीजों को फिर से लिखना चाहते हैं आधे रास्ते में यह सही तकनीक को बाहर की तरफ लेने के लिए बहुत मायने रखता है। बस याद रखें कि यदि आपके पास वास्तव में उच्च मात्रा है, तो ढेर के सभी स्तरों पर विकल्पों और प्रौद्योगिकियों की एक बड़ी मात्रा है जो आप उपयोग करने के लिए देखेंगे।

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

स्कीमा डिज़ाइन पहलू शायद पारंपरिक mysql उपयोगकर्ताओं के लिए सबसे बड़ी बाधा होगी। मुझे लगता है कि स्कीमा डिजाइन पर MongoDb पेज इसके साथ मदद करता है। मेरा अंतिम बिंदु यह है कि मिश्रण में आपके द्वारा जोड़ी गई प्रत्येक तकनीक जटिलता जोड़ती है। किसी भी दिए गए टुकड़े के लिए अक्सर बहुत बड़े वकील होते हैं जो इसे इस्तेमाल करने के लिए "आपके पास" कहेंगे, लेकिन मैंने पाया है कि वास्तव में एक बड़ा कारक सिर्फ कितने टुकड़े हैं। इसका मतलब है कि असफलता के अधिक संभावित बिंदु और किसी और के लिए आवश्यक ज्ञान के आधार के अधिकांश हिस्से को इस पर काम करने के लिए जानना होगा।

फी रिक रिकोर्न के पास एक अद्भुत अद्भुत तुलना आरेख है जो काफी अद्वितीय है!

Comments

रेल में यह मेरी पहली वास्तविक परियोजना है: यह एक शौक है और अब के लिए मुझे नहीं पता कि क्या यह सफल होने जा रहा है या असफल मेरा पहला उद्देश्य यहां रेल के साथ जाना जाता है, इसलिए मैं यातायात की बात नहीं कर सकता।

— प्रतिक्रियाएं

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

— केविन

मेरे -1 या क्यों 0 बुरी सलाह या असहमत के बारे में निश्चित नहीं है?

— माइकल ड्यूरेंट

वैसे भी, अगर यह रेल में आपकी पहली परियोजना है तो मैं mySQL के साथ रहना चाहूंगा। रेल में सीखने के लिए बहुत कुछ है, जब तक आप पर्दे वापस खींचना शुरू करते हैं तब तक 1 महीने से अधिक समय तक चलने लायक है।

— माइकल डुरंट

@michael मेरा अंतिम अपडेट देखें

— Matteo Pagliazzi

Answer 3

मुझे NoSQL बनाम MySQL के लिए बहुत सारे मान्य तर्क दिखाई देते हैं। एक मिसिंग लिंक हालांकि स्केल के बारे में है: यदि आप वास्तव में स्केल करना चाहते हैं और इसे घर के डेटाबेस में करना चाहते हैं, तो आपको डेटाबेस के बारे में बहुत सारे ज्ञान की आवश्यकता होगी। वहाँ बहुत सी डरावनी कहानियाँ हैं जहाँ लोग एक ऐसी प्रणाली को लागू करने की कोशिश में असफल रहे हैं जो असीम पैमाने पर होगी।

यदि आप वास्तव में NoSQL मार्ग पर जाना चुनते हैं (और इसके साथ आने वाली लागत लेने के लिए तैयार हैं - जैसे कोई जोड़ नहीं), तो AWS DynamoDB (http://aws.amazon.com/dynamodb/) पर विचार करें। यहाँ आप इसके बारे में पूरे डेटाबेस स्केलिंग भाग के बारे में भूल सकते हैं, और अपने आवेदन पर ध्यान केंद्रित कर सकते हैं। सौभाग्य।

डिस्क्लेमर: मैं AWS डायनॉम्बीडी टीम में एक डेवलपर हूं, लेकिन मुझे वास्तव में हमारे उत्पाद पर विश्वास है। इसे आज़माएं :)

Answer 4

तो, आपका डिज़ाइन आपके डेटाबेस में दो अलग-अलग तरह की वस्तुओं को सहेजने के लिए मिलता है:

• उपयोगकर्ता ऑब्जेक्ट (जिसमें हमेशा फ़ील्ड होते हैं)।
• ऐप्स ऑब्जेक्ट (जिसमें अलग-अलग फ़ील्ड हो सकते हैं)। एक ऐप केवल एक उपयोगकर्ता का होगा।

एक संग्रह मुझे एक अलग वस्तु के रूप में बना सकता है या नहीं कर सकता है, जैसा कि अलग-अलग ऐप को समूहीकृत करने के लिए सिर्फ एक टैग है। तर्क के लिए, मान लें कि कोई संग्रह नहीं है और उपयोगकर्ताओं के पास केवल आवेदनों की एक सूची है।

जब तक मुझे लगता है कि MySQL पर प्राप्त होता है, MongoDB में आपके पास ऐप ऑब्जेक्ट्स की संरचना के संदर्भ में अधिक लचीलापन होगा, और शायद यह डेटाबेस में आपके प्रतिनिधित्व को अधिक स्वाभाविक रूप से मैप करेगा, जिससे कोड सरल हो जाएगा।

MySQL में आपको विभिन्न ऐप्स के लिए अलग-अलग प्रारूपों से निपटने में समस्याएँ होंगी, लेकिन यह संभव है। कुछ विचार:

• आप सभी वस्तुओं (आईडी, user_id, शीर्षक, आदि) के बीच सभी सामान्य जानकारी के साथ एक मध्यवर्ती तालिका बना सकते हैं, फिर टाइप करें, इसलिए आप उस प्रारूप के लिए केवल गैर-सामान्य फ़ील्ड के साथ किसी अन्य तालिका पर खोज कर सकते हैं (जैसे file_name और files के लिए file_size)। आपको प्रत्येक भिन्न प्रारूप के लिए एक अलग तालिका बनाने की आवश्यकता होगी। यदि दोनों तालिकाओं को app_id (प्राथमिक कुंजी) द्वारा अनुक्रमित किया जाता है, तो यह पर्याप्त तेज होगा, क्योंकि अनुक्रमित मान द्वारा तालिका तक पहुंचना तेज है।
• आप डेटा को कुछ प्रारूप में संग्रहीत कर सकते हैं और मानकीकृत स्टोर कर सकते हैं। उदाहरण के लिए, JSON में गैर-सामान्य डेटा को एक स्ट्रिंग के रूप में एन्कोड करें और इसे VARCHAR फ़ील्ड पर संग्रहीत करें। उस क्षेत्र के आकार के साथ सावधान रहें ताकि आप अंतरिक्ष से बाहर न भागें। प्रारूप जटिल हो सकता है (JSON) या सरल (अल्पविराम द्वारा अलग किए गए मान)
• आप विभिन्न "जेनेरिक" फ़ील्ड बना सकते हैं, जैसे int1, int2, str1, str2, और परिभाषित करते हैं कि एक ऐप प्रकार के लिए str1 "file_name" है जबकि एक अलग प्रकार के लिए "स्थान" हो सकता है।

MongoDB पर, यह केवल दो MongoDB संग्रह का उपयोग करने के रूप में सरल हो सकता है, एक उपयोगकर्ताओं के लिए और दूसरा ऐप्स के लिए। कुछ प्रकार की सीमा को मानते हुए (जो कि मामला नहीं है, जैसा कि आपने वर्णित किया है, लेकिन सिर्फ कहने के लिए), आप सूची के रूप में उपयोगकर्ता ऑब्जेक्ट के अंदर एप्लिकेशन भी स्टोर कर सकते हैं। डेटा संग्रहीत और पुनर्प्राप्त करना अधिक स्वाभाविक है, क्योंकि आप किसी भी प्रकार की वस्तु को स्टोर कर सकते हैं, चाहे वह कोई भी क्षेत्र हो। आप उन सभी ऐप्स को प्राप्त करने के लिए user_id द्वारा खोज सकते हैं जो किसी उपयोगकर्ता के हैं। MongoDB पर आप वैसे भी प्रश्नों से जुड़ने की संभावना को कम कर सकते हैं, लेकिन इस मामले में मुझे लगता है कि बुनियादी प्रश्न उपयोगकर्ता को पुनः प्राप्त करेंगे और उपयोगकर्ता से संबंधित ऐप्स को पुनः प्राप्त करेंगे। यदि आप बहुत सारी चीजें करने की योजना बनाते हैं, जैसे "मुझे उन उपयोगकर्ताओं को दें जिनके पास तीन अनुप्रयोगों के साथ दो से अधिक संग्रह हैं या प्रत्येक पर कम", तो आपको इसे सम्मिलित क्वेरी के रूप में नहीं उत्पन्न करना होगा, लेकिन कोड में एक प्रक्रिया के रूप में, और एक रिलेशनल डेटाबेस की तुलना में कम प्राकृतिक होगा और प्रक्रिया के लिए अधिक समय ले सकता है। यदि आप मापदंडों की खोज करना चाहते हैं (जैसे मुझे वे सभी ऐप्स दें जो किसी विशेष उपयोगकर्ता के हैं, तो मुझे वे सभी ऐप्स दें जो एक्स के प्रकार हैं), यह MongoDB पर काफी आसान है और इसमें जॉइन का उपयोग करने की आवश्यकता नहीं है।

मैं रेल पर MongoDB के समर्थन के बारे में निश्चित नहीं हूं। मैंने इसे पायथन और जावास्क्रिप्ट में उपयोग किया है।

संपादित करें: दो तालिकाओं और एक अन्य MySQL विकल्प का उपयोग करते समय समय के बारे में टिप्पणी जोड़ा गया

Comments

मुझे वैकल्पिक सेटिंग्स संग्रहीत करने के लिए MySQL का उपयोग करने के लिए दूसरा विकल्प पसंद नहीं है क्योंकि मुझे लगता है कि यह प्रत्येक पंक्ति को बहुत अधिक आवश्यक बाइट्स के साथ लोड नहीं कर सकता है ... दूसरे के लिए: यह दो पंक्तियों को लोड करने के लिए मेरे ऐप को बहुत धीमा कर देगा। एक आइटम लोड करने के लिए दो अलग-अलग तालिकाओं से?

— मत्तेयो पगलियाज़ी

कृपया मेरा अंतिम अपडेट देखें

— मट्टियो पगलियाज़ी

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

— खेलाबेन

Answer 5

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

यह कहने के बाद, आपके मामले में MongoDB के साथ जाने का एक अच्छा कारण आपका डेटा है। जैसा कि आपने उल्लेख किया है, आपके पास अपने संग्रह के लिए कई अलग-अलग प्रकार के प्रवेश होंगे: नक्शा, वीडियो और आगे। यदि आप RDBMS का उपयोग करके इसे लागू करने वाले थे, तो आपके पास 3 दृष्टिकोण हैं:

• तालिका-प्रति-प्रकार: प्रत्येक तालिका में प्रत्येक प्रकार की वस्तुओं के लिए विशिष्ट कॉलम होते हैं

  नुकसान : सभी डेटा प्रकारों में खोज करने के लिए एन क्वेरी।

  लाभ : अच्छा OO डिजाइन, आसानी से बनाए रखने के लिए

• एकल तालिका: सभी प्रकार के लिए सभी संभावित विशेषताओं वाली एक विशाल तालिका, उनमें से अधिकांश किसी विशेष प्रविष्टि के लिए अशक्त हैं

  नुकसान : किसी भी वस्तु में परिवर्तन के लिए परिवर्तन तालिका की आवश्यकता होगी, दर्दनाक एक बार तालिका बड़ी हो जाए। बनाए रखना मुश्किल है।

  लाभ : लागू करने में आसान।

• मेटा-डेटा के साथ कोर तालिका: आपके पास मुख्य विशेषताओं के साथ एक एकल तालिका है, शीर्षक, दिनांक और अतिरिक्त विशेषताओं के लिए मुख्य-मूल्य जोड़े वाली मेटाडेटा तालिका है

  नुकसान : एक एकल ऑब्जेक्ट के लिए सभी डेटा प्राप्त करने के लिए दो क्वेरी।

  लाभ : बेहद लचीला, लागू करने के लिए बहुत मुश्किल नहीं है।

मैंने इनमें से प्रत्येक दृष्टिकोण का उपयोग किया है, और मैं कह सकता हूं कि कोई भी मोंगो के साथ काम करना स्वाभाविक नहीं है। आपका डेटा संभवतः कुछ इस तरह दिखाई देगा:

{_id:"collection1",
 name:"My first Collection",
 owner: "user123243342",
 entries: [
    {type:"video",
     url: "http://www.youtube.com/234324",
     tags: ["roadtrip", "fun", "camera"]
     },
    {type:"map",
     coordinates: [LOC: [38, –102], LOC: [43, –33], LOC: [228, –102]],
     description: "Road trip to nowhere",
 ]
}

लेकिन आपको वास्तव में स्कीमा डिज़ाइन के बारे में चिंता करने की ज़रूरत नहीं होगी, क्योंकि आपके डोमेन ऑब्जेक्ट को सीधे इस तरह से बनाए रखा जा सकता है। MongoDB अनिवार्य रूप से आपका ऑब्जेक्ट स्टोर है जिसके खिलाफ आप क्वेरी कर सकते हैं।

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

संपादित करें

MySQL का उपयोग करने और उसी फ़ील्ड में "" | यह मत करो। यह दृष्टिकोण आपको हल करने की तुलना में अधिक समस्या देगा। सबसे पहले, आप MySql का उपयोग करके व्यक्तिगत विशेषताओं के खिलाफ क्वेरी नहीं कर पाएंगे। दूसरा यह आपके डेटा एक्सेसिंग लेयर में बहुत अधिक जटिलता जोड़ता है। इसके बजाय टाइप-प्रति-तालिका या मेटा-डेटा दृष्टिकोण का उपयोग करें। यदि आपने पहले वर्डप्रेस के साथ काम किया था, तो यह मेटा-डेटा दृष्टिकोण का उपयोग करता है:

• उपयोगकर्ता के लिए उपयोगकर्ता तालिका + usemeta
• पोस्ट टेबल + पोस्टमेटा टेबल पोस्ट

यह उचित संरचना के साथ डेटा संरचना को बेहद लचीला और अभी भी क्वेरी-सक्षम बनाता है।

Comments

मुझे मेटाडेटा विकल्प पसंद नहीं है ... लेकिन मैं खेतों के साथ एकल तालिका पर सोच रहा हूं कि अगर उपयोग नहीं किया जाता है, तो

— मतलबी

एकल तालिका दृष्टिकोण संभवतः गुच्छा का सबसे खराब है। जब आप एक ही क्वेरी में सब कुछ कर सकते हैं, तो किसी भी एकल डेटा प्रकार में किसी भी बदलाव के लिए परिवर्तन तालिका की आवश्यकता होगी। और आपकी मेज बड़ी हो जाने के बाद यह mysql में दर्द होता है।

— ltfishie

Answer 6

डेटाबेस में डेटा की मात्रा और पुनर्प्राप्त डेटा की मात्रा पर विचार करते हुए नीचे दिया गया लेख MySQL और MongoDB की तुलना में अच्छे परिणाम प्रदान करता है। परिणाम "आवेषण" के बारे में MongoDB के लिए बहुत बढ़िया प्रदर्शन करते हैं, लेकिन अन्य मामले MySQL जीतते हैं। निचे देखो:

http://www.moredevs.ro/mysql-vs-mongodb-performance-benchmark/

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