कई JSON फ़ील्ड के साथ MongoDB बनाम MySQL का उपयोग कर?

Question

एक माइक्रोब्लॉगिंग प्रकार का आवेदन है। शून्य पर दो मुख्य मूल डेटाबेस स्टोर हैं: MySQL या MongoDB।

मैं बहुत सारे डेटा को denormalize करने की योजना बना रहा हूँ Ie. किसी पोस्ट पर किए गए वोट को मतदान तालिका में संग्रहीत किया जाता है, मुख्य पोस्ट तालिका में भी गणना की जाती है। पोस्ट के साथ अन्य क्रियाएं भी शामिल हैं (जैसे, वोट करें)।

यदि मैं MySQL का उपयोग करता हूं, तो कुछ डेटा तेजी से लुकअप के लिए निश्चित स्कीमा से JSON के रूप में बेहतर सूट।

उदा।

POST_ID | activity_data 

213423424 | { 'likes': {'count':213,'recent_likers' : 
      ['john','jack',..fixed list of recent N users]} , 'smiles' : 
      {'count':345,'recent_smilers' : 
      ['mary','jack',..fixed list of recent N users]} } 

आवेदन के अन्य घटक भी हैं, जहां JSON का उपयोग प्रस्तावित किया जा रहा है। तो, एक JSON क्षेत्र अद्यतन करने के लिए, अनुक्रम है:

1. अजगर स्क्रिप्ट में JSON पढ़ें।

2. JSON अपडेट करें

3. स्टोर JSON वापस MySQL में।

यह $push, $inc, $pull आदि जैसे परमाणु संचालन के साथ MongoDB में एक ऑपरेशन हो गया होता भी MongoDB के दस्तावेज़ संरचना अच्छी तरह से अपने डेटा सूट।

डेटा स्टोर चुनते समय मेरे विचार।

MySQL के बारे में:

1. स्थिर और परिचित।
2. बैकअप और पुनर्स्थापित करना आसान है।
3. कुछ भविष्य स्कीमा परिवर्तनों को कुछ क्षेत्रों का उपयोग स्कीमालेस जेएसओएन के रूप में टाला जा सकता है।
4. को मेमकैच की शुरुआत में परत का उपयोग करना पड़ सकता है।
5. जेएसओएन ब्लब्स मुख्य पदों जैसे कुछ तालिकाओं में स्थिर होंगे, हालांकि पोस्ट वोट और पसंद जैसे कुछ अन्य तालिकाओं में बहुत कुछ अपडेट किया जाएगा।

MongoDB के बारे में:

1. बेहतर दुकान स्कीमा कम दस्तावेजों के रूप में डेटा के लिए अनुकूल।
2. कैशिंग को बाद के चरण तक टाला जा सकता है।
3. कभी-कभी ऐप लिखने में गहन हो सकता है, मोंगो डीबी उन बिंदुओं पर बेहतर प्रदर्शन कर सकता है जहां असुरक्षित लिखना कोई मुद्दा नहीं है।
4. स्थिरता और विश्वसनीयता के बारे में निश्चित नहीं है।
5. यह सुनिश्चित नहीं है कि बैकअप और पुनर्स्थापित करना कितना आसान है।

सवाल:

1. हम MongoDB चुना दूँ, तो डेटा के आधे स्कीमा-है, और अगर MySQL का उपयोग कर JSON के रूप में जमा किया जा रहा है?

2. मुख्य पदों जैसे कुछ डेटा महत्वपूर्ण हैं, इसलिए इसे सुरक्षित लिखने, काउंटर इत्यादि का उपयोग करके सहेजा जाएगा असुरक्षित लिखने का उपयोग करके सहेजा जाएगा। क्या यह नीति डेटा के महत्व पर आधारित है, और तीव्रता सही लिखती है?

3. MySQL की तुलना में MongoDB की निगरानी, ​​बैकअप और पुनर्स्थापित करना कितना आसान है? हमें आवधिक बैकअप (दैनिक कहने) की योजना बनाने की आवश्यकता है, और आपदा के मामले में उन्हें आसानी से बहाल करना होगा। आवेदन के लिए इसे सुरक्षित शर्त बनाने के लिए मोंगो डीबी के साथ मेरे पास सबसे अच्छे विकल्प क्या हैं।

स्थिरता, बैकअप, फोटो, बहाल करने, व्यापक गोद लेने I.e.database स्थायित्व मुझे ओर इशारा करते हुए के रूप में आरडीबीएमएस + NoSQL MySQL का उपयोग करने के भले ही एक NoSQL दस्तावेज़ संग्रहण मेरा उद्देश्य बेहतर सेवा कर सकता है कारण हैं।

कृपया मेरे विचारों को ध्यान में रखते हुए डेटाबेस डिज़ाइन पर विचार करते हुए MySQL और MongoDB के बीच की पसंद पर अपने विचारों पर ध्यान केंद्रित करें। मुझे पता है कि आरडीबीएमएस या मोंगोडीबी दस्तावेजों के साथ डेटाबेस डिजाइन की योजना बनाने के बेहतर तरीके हो सकते हैं। लेकिन यह मेरे प्रश्न का वर्तमान फोकस नहीं है।

अद्यतन: MySQL 5.7 के बाद से, MySQL एक अमीर देशी JSON डेटाप्रकार जो डेटा लचीलापन के साथ ही अमीर JSON क्वेरी प्रदान करता है समर्थन करता है।

https://dev.mysql.com/doc/refman/5.7/en/json.html

Answer 1

तो, सीधे सवालों का जवाब देना ...

हम MongoDB चुना दूँ, तो डेटा के आधे स्कीमा-है, और अगर MySQL का उपयोग कर JSON के रूप में जमा किया जा रहा है?

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

यदि मैं JSON फ़ील्ड को अपडेट करने के बारे में चित्रण में एक छोटी सी त्रुटि बता सकता हूं, तो यह केवल वर्तमान मान प्राप्त करने, दस्तावेज़ को अद्यतन करने और फिर डेटाबेस पर वापस धक्का देने का विषय नहीं है। प्रक्रिया को सभी लेनदेन में लपेटा जाना चाहिए। जब तक आप अपने डेटाबेस को denormalizing शुरू नहीं करते हैं, लेनदेन काफी सरल होते हैं। फिर एक अपवॉट रिकॉर्डिंग के रूप में सरल कुछ आपके स्कीमा पर टेबल लॉक कर सकते हैं।

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

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

"सुरक्षित लिखने" से मुझे लगता है कि आप प्रत्येक लिखने के बाद स्वचालित "getLastError()" चालू करने का विकल्प मानते हैं। हमारे पास डीबीसीओलेक्शन पर बहुत पतला आवरण होता है जो हमें GetLastError() कहा जाता है जब हमें ठीक से दाग नियंत्रण की अनुमति देता है। हालांकि, हमारी नीति इस बात पर आधारित नहीं है कि "महत्वपूर्ण" डेटा कैसा है, बल्कि यह है कि क्वेरी के बाद कोड निम्न पढ़ने में किसी भी संशोधन को तत्काल दिखाई देने की उम्मीद कर रहा है या नहीं।

आम तौर पर, यह अभी भी एक गरीब संकेतक है, और हम इसके बजाय उसी व्यवहार के लिए ANDModify() खोजने के लिए माइग्रेट किए गए हैं। इस अवसर पर जहां हम अभी भी getLastError() को स्पष्ट रूप से कॉल करते हैं, यह तब होता है जब डेटाबेस एक लिखने को अस्वीकार कर सकता है, जैसे कि जब हम _id के साथ डालें() जो डुप्लिकेट हो।

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

मुझे डर है कि मैं बात नहीं कर सकता कि हमारी बैकअप/पुनर्स्थापना नीति प्रभावी है क्योंकि हमें अभी तक पुनर्स्थापित नहीं करना है। हम बैक अप के लिए मोंगोडीबी सिफारिशों का पालन कर रहे हैं; @ मार्क-हिलिक ने उनको सारांशित करने का एक अच्छा काम किया है। हम प्रतिकृति सेट का उपयोग कर रहे हैं, और हमने मोंगोडीबी संस्करणों के साथ-साथ नए प्रतिकृति सदस्यों को पेश किया है। अब तक हमारे पास कोई डाउनटाइम नहीं है, इसलिए मुझे यकीन नहीं है कि मैं इस बिंदु पर अच्छी तरह से बात कर सकता हूं।

स्थिरता, बैकअप, स्नैपशॉट्स, बहाल करना, व्यापक गोद लेने यानी।डेटाबेस स्थायित्व कारण हैं कि मुझे MySQL का उपयोग RDBMS + NoSql के रूप में करने के लिए इंगित करने के कारण हैं, भले ही कोई NoSQL दस्तावेज़ संग्रहण मेरे उद्देश्य को बेहतर तरीके से पूरा कर सके।

तो, मेरे अनुभव में, मोंगोडीबी क्वेरी प्राइमेटिव्स के एक सेट के साथ स्कीमलेस डेटा का भंडारण प्रदान करता है जो लेन-देन अक्सर परमाणु संचालन द्वारा प्रतिस्थापित किया जा सकता है। 10+ साल के एसक्यूएल अनुभव को अनदेखा करना मुश्किल हो गया है, लेकिन मुझे जिस समस्या का सामना करना पड़ा है उसे समुदाय या 10gen से सीधे संबोधित किया गया है। हमने डेटा खो दिया है या कोई डाउनटाइम नहीं है जिसे मैं याद कर सकता हूं।

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

मैं 10gen के लिए काम नहीं करता, लेकिन मैं जो लोग करता हूं उनके लिए मैं बहुत आभारी हूं।

Answer 2

मैं तुलना पर टिप्पणी करने के लिए (मैं 10gen के लिए काम करते हैं और यह उपयुक्त है मुझे ऐसा करने के लिए नहीं लग रहा है), तथापि, मैं विशिष्ट MongoDB सवालों का जवाब देंगे नहीं जा रहा हूँ ताकि आप बेहतर निर्णय ले सकते हैं।

द बैक-अप

प्रलेखन here, बहुत ही गहन है कई पहलुओं को कवर:

• ब्लॉक स्तर के तरीके (एलवीएम यह बहुत आसान है और काफी लोक का एक बहुत यह कर बनाता है)
• जर्नलिंग के साथ/बिना
• ईबीएस स्नैपशॉट्स
• सामान्य स्नैपशॉट्स
• प्रतिकृति (तकनीकी रूप से बैक अप नहीं है, तथापि, उनके अतिरेक और के लिए लोक उपयोग प्रतिकृति सेट का एक बहुत बैक अप - यह सिफारिश करने नहीं, लेकिन यह किया जाता है)

अभी हाल तक, वहाँ का कोई MongoDB बराबर है mylvmbackup लेकिन एक अच्छे लड़के ने एक लिखा :) उसके शब्दों में

शुरुआती दिनों तक: यह सिर्फ एक गौरवशाली शैल स्क्रिप्ट है और इसे और अधिक त्रुटि जांचने की आवश्यकता है। लेकिन पहले से ही यह मेरे लिए काम करता है और मुझे लगा कि मैं खुशी साझा करूंगा। बग रिपोर्ट, पैच & सुझावों का स्वागत है।

अपने आप को here से एक प्रति प्राप्त करें।

पुनर्स्थापित करता

• Formats etc

mongodump पूरी तरह से here प्रलेखित है और mongorestore here है।

mongodump में इंडेक्स नहीं होंगे लेकिन इसमें सिस्टम.इंडेक्स संग्रह होता है, इसलिए जब आप बीएसओ फ़ाइल को पुनर्स्थापित करते हैं तो मैंगोरस्टोर इंडेक्स का पुनर्निर्माण कर सकता है। bson फ़ाइल जबकि mongoexport/mongoimport वास्तविक डेटा टाइप-सुरक्षित नहीं कर रहे हैं तो यह कुछ भी हो सकता (techically बोल) :)

निगरानी

here प्रलेखित है।

मुझे कैक्टि पसंद है लेकिन afaik, कैक्टि टेम्पलेट्स ने मोंगोडीबी में बदलावों को नहीं रखा है और इसलिए पुराने वाक्यविन्यास पर भरोसा है, इसलिए 2.0.4 के बाद, मेरा मानना ​​है कि समस्याएं हैं।

नागियो अच्छी तरह से काम करता है लेकिन यह नागियो है ताकि आप या तो उससे प्यार करें या नफरत करें। बहुत सारे लोग नागोस का उपयोग करते हैं और ऐसा लगता है कि उन्हें महान दृश्यता प्रदान की जाती है।

मैंने ज़ैप्पिक्स को देख रहे कुछ लोगों के बारे में सुना है लेकिन मैंने इसका कभी भी उपयोग नहीं किया है, इसलिए टिप्पणी नहीं कर सकता।

इसके अतिरिक्त, आप एमएमएस का उपयोग कर सकते हैं, जो मुफ़्त है और बाहरी रूप से होस्ट किया गया है। आपके मोंगोडीबी उदाहरण एक एजेंट चलाते हैं और उन एजेंटों में से एक https से mms.10gen.com पर https पर पाइथन कोड का उपयोग करते हैं। हम मोंगोडीबी उदाहरणों पर सभी प्रदर्शन आंकड़ों को देखने के लिए एमएमएस का उपयोग करते हैं और यह उच्च स्तरीय व्यापक दृश्य से बहुत फायदेमंद है और साथ ही ड्रिल करने की क्षमता भी प्रदान करता है। यह स्थापित करना आसान है और इसके लिए आपको कोई हार्डवेयर चलाने की ज़रूरत नहीं है। कई ग्राहक इसे चलाते हैं और कुछ इसे कैक्टि/नागियोस के साथ तारीफ करते हैं।

एमएमएस पर सहायता जानकारी here मिल सकती है (यह एक बहुत विस्तृत, समावेशी दस्तावेज़ है)।

Answer 3

संग्रहीत json के साथ एक mysql समाधान का नुकसान यह है कि आप कुशलतापूर्वक json डेटा पर खोज करने के लिए सक्षम नहीं होगा है। यदि आप इसे सभी को मोंगोडब में संग्रहीत करते हैं, तो आप जेसन सहित अपने सभी डेटा पर इंडेक्स और/या क्वेरी बना सकते हैं।

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

मोंगोडबी मूल कुंजी जैसे कुछ डीबी संरचनाओं के मूल प्रवर्तन या कैस्केडिंग प्रदान नहीं करता है, इसलिए आपको स्वयं को प्रबंधित करना होगा (जैसे या तो रचना के माध्यम से, जो कि मोन्गो के स्ट्रेनघट्स में से एक है), या dbrefs के उपयोग के माध्यम से।

तुम सच में लेनदेन समर्थन और मजबूत 'सुरक्षित' की जरूरत है लिखते हैं, फिर भी अभी भी इच्छा NoSQL द्वारा प्रदान की लचीलापन, आप एक संकर समाधान पर विचार हो सकता है। यह आपको MySQL को अपने मुख्य पोस्ट स्टोर के रूप में उपयोग करने की अनुमति देगा, और उसके बाद mongodb को 'स्कीमालेस' स्टोर के रूप में उपयोग करें।हाइब्रिड मोंगो/rdbms समाधानों पर चर्चा करने वाले डॉक्टर के लिए यहां एक लिंक दिया गया है: http://www.10gen.com/events/hybrid-applications आलेख 10gen की साइट से है, लेकिन आप त्वरित Google खोज करके अन्य उदाहरण पा सकते हैं।