MySQL और Mongodb का उपयोग करके

मैंने मोंगोडीबी से अधिक MySQL के साथ काम किया है, लेकिन जो मुझे मैंने मोंगोडीबी से सीखा है, वही है जो मुझे चाहिए, लेकिन इसकी सीमाएं भी हैं जो MySQL कर सकती है (उदाहरण के लिए ऑटो वृद्धि)MySQL और Mongodb का उपयोग करके

क्या सब कुछ के लिए MongoDB का उपयोग करना स्मार्ट होगा, और केवल कुछ चीजों के लिए MySQL का उपयोग करें?

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

स्रोत

2012-05-20 unlucky4ever

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

हाँ, मैं इसे सिर्फ इतना से अधिक उपयोग कर रहा हूं, मैं बस एक उदाहरण दे रहा था। धन्यवाद। – unlucky4ever

यह एक परियोजना में दो डेटाबेस प्रौद्योगिकियों का उपयोग करने के लिए पूरी तरह से उचित लगता है। बस सुनिश्चित करें कि आप नौकरी के लिए सही उपकरण का उपयोग करें।

माइस्क्लुएल को प्राथमिक भंडारण और मोंगोडीबी को गति के लिए कैशिंग/इंटरमीडिएट स्टोरेज के रूप में उपयोग करना आम बात है।

उदाहरण के लिए आप मोंगोडीबी में पढ़ने-गहन डेटा प्राप्त कर सकते हैं। रिपोर्ट बनाने के लिए डेटा MySQL जैसे रिलेशनल सिस्टम के लिए बिल्कुल सही है।

स्रोत

2012-05-20 19:18:51 ilanco

क्या दो अलग-अलग डेटाबेस का उपयोग करना आम है? – unlucky4ever

दो अलग-अलग प्रकार के डेटाबेस, उदाहरण के लिए एक ऑब्जेक्ट उन्मुख और एक रिलेशनल ... – aleroot

धन्यवाद, अब मुझे पता चला है कि मुझे MySQL का उपयोग अपने मुख्य डेटाबेस के रूप में करना चाहिए, और अन्य चीजों के लिए मोंगोडीबी का उपयोग करना चाहिए, मैं अपना रूपांतरण बदलना शुरू कर दूंगा आवेदन :) (चिंता न करें यह छोटा है) – unlucky4ever

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

MongoDB के लिए अच्छा मामले उपयोग इस प्रकार हैं: 1) आपका डेटा एक दस्तावेज़ स्वरूप में है, यानी एक दस्तावेज में अनियमित संरचना (कि डेटा में शामिल हो गए करने की आवश्यकता नहीं है) 2) आप एक का उपयोग कर विचार कर रहे हैं है फ्लैट फ़ाइल सिस्टम (फिर से आपके डेटा की संरचना के कारण), लेकिन आप डेटा को इंडेक्स/क्वेरी करने की क्षमता के मामले में 'अधिक' चाहते हैं। 3) आपकी परियोजना एक ऐसे राज्य में है जहां आप वास्तव में नहीं जानते कि आपके डेटा की स्कीमा या संरचना अंततः क्या होगी। 4) आपके पास भौगोलिक-स्थानिक डेटा जैसे विशिष्ट डेटा प्रकार हैं, और आप इसके खिलाफ पूछने में सक्षम होना चाहते हैं। 5) आपको अपने डेटा संग्रहण स्थान को तेज़ी से और सस्ते पैमाने पर स्केल करने की आवश्यकता हो सकती है।

स्रोत

2012-05-20 21:32:21

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

@ जॉनहार्डिंग इतना आसान नहीं है। मैंने खुद को एक ऐसे प्रोजेक्ट में पाया जहां मॉडल को पूरी तरह वर्णित नहीं किया जा सकता है, और निरंतर अपडेट की आवश्यकता है। इस मामले में मैंने मोंगो के साथ काम करना बहुत आसान पाया। –

यहाँ MongoDB उपयोग के एक अच्छी तरह से टाइप किया चर्चा, किसी के द्वारा जो MongoDB पाठ्यक्रम लिया

Considerations for choosing or not choosing MongoDB

है ब्लॉगर मुख्य रूप से कहना है कि अन्य डीबी सिस्टम के साथ MongoDB का उपयोग कर बिल्कुल ठीक है, फिर भी यह प्रणाली विस्तृत का उपयोग कर , कुछ निश्चित परिदृश्यों में सबसे चुनौतीपूर्ण और लगभग असंभव हो सकता है।

कारण

दस्तावेज़ उन्मुख और स्कीमा-
क्षैतिज अनुमापकता और उच्च उपलब्धता
फास्ट राईट आग-और-में मोंगो चयन करने के लिए:

यहाँ कुछ उपशीर्षक हैं मोड भूलें
व्यापक क्वेरीिंग और एग्ग्रे gation फ्रेमवर्क
तुलनात्मक रूप से सहज ज्ञान युक्त वास्तुकला

मोंगो चयन करने के लिए नहीं
कारण

कोई एसक्यूएल = नहीं शामिल
नहीं एसिड लेनदेन
आपका अनुक्रमित स्मृति में फिट नहीं होगा

स्रोत

2014-01-03 23:48:29 kommradHomer

उत्तर

संबंधित मुद्दे