तो, सीधे सवालों के जवाब देने के लिए...
स्कीमालेस स्टोरेज निश्चित रूप से मोंगोडीबी के साथ जाने का एक अनिवार्य कारण है, लेकिन जैसा कि आपने बताया है, जेएसओएन को आरडीबीएमएस में भी स्टोर करना काफी आसान है। MongoDB के पीछे की शक्ति स्कीमालेस स्टोरेज के खिलाफ समृद्ध प्रश्नों में है।
यदि मैं JSON फ़ील्ड को अपडेट करने के बारे में चित्रण में एक छोटी सी खामी को इंगित कर सकता हूं, तो यह केवल वर्तमान मान प्राप्त करने, दस्तावेज़ को अपडेट करने और फिर इसे डेटाबेस में वापस धकेलने की बात नहीं है। प्रक्रिया को सभी लेनदेन में लपेटा जाना चाहिए। लेन-देन काफी सरल होते हैं, जब तक कि आप अपने डेटाबेस को असामान्य बनाना शुरू नहीं करते। फिर अपवोट रिकॉर्ड करने जितना आसान कुछ आपके पूरे स्कीमा में टेबल लॉक कर सकता है।
MongoDB के साथ, कोई लेनदेन नहीं है। लेकिन संचालन लगभग हमेशा इस तरह से संरचित किया जा सकता है जो परमाणु अद्यतनों की अनुमति देता है। इसमें आमतौर पर SQL प्रतिमानों से कुछ नाटकीय बदलाव शामिल होते हैं, लेकिन मेरी राय में जब आप वस्तुओं को तालिकाओं में बाध्य करने की कोशिश करना बंद कर देते हैं तो वे काफी स्पष्ट होते हैं। कम से कम, बहुत से अन्य लोगों ने भी उन्हीं समस्याओं का सामना किया है जिनका आप सामना कर रहे हैं, और मोंगो समुदाय उन चुनौतियों के बारे में काफी खुला और मुखर है, जिन पर उन्होंने विजय प्राप्त की है।
"सुरक्षित लेखन" से मुझे लगता है कि आपका मतलब प्रत्येक लेखन के बाद स्वचालित "getLastError ()" चालू करने का विकल्प है। हमारे पास DBCollection पर एक बहुत पतला आवरण है जो हमें getLastError() कहे जाने पर बारीक नियंत्रण की अनुमति देता है। हालांकि, हमारी नीति इस बात पर आधारित नहीं है कि "महत्वपूर्ण" डेटा कैसा है, बल्कि यह है कि क्या क्वेरी का अनुसरण करने वाला कोड किसी भी संशोधन की अपेक्षा कर रहा है जो निम्नलिखित में तुरंत दिखाई देगा।
सामान्यतया, यह अभी भी एक खराब संकेतक है, और इसके बजाय हमने उसी व्यवहार के लिए findAndModify () में माइग्रेट किया है। उस अवसर पर जहां हम अभी भी getLastError() को स्पष्ट रूप से कॉल करते हैं, यह तब होता है जब डेटाबेस एक लेखन को अस्वीकार कर सकता है, जैसे कि जब हम एक _id के साथ सम्मिलित करते हैं ( जो एक डुप्लिकेट हो सकता है।
मुझे डर है कि मैं इस बारे में बात नहीं कर सकता कि क्या हमारी बैकअप/पुनर्स्थापना नीति प्रभावी है क्योंकि हमें अभी तक पुनर्स्थापित नहीं करना पड़ा है। हम बैकअप के लिए MongoDB अनुशंसाओं का पालन कर रहे हैं; @ मार्क-हिलिक ने उनको सारांशित करने का एक अच्छा काम किया है। हम प्रतिकृति सेट का उपयोग कर रहे हैं, और हमने MongoDB संस्करणों के साथ-साथ नए प्रतिकृति सदस्यों को भी माइग्रेट किया है। अभी तक हमारे पास कोई डाउनटाइम नहीं है, इसलिए मुझे यकीन नहीं है कि मैं इस बिंदु पर अच्छी तरह से बोल सकता हूं।
इसलिए, मेरे अनुभव में, MongoDB स्कीमा रहित डेटा के भंडारण की पेशकश करता है जिसमें क्वेरी प्राइमेटिव का एक सेट पर्याप्त समृद्ध है कि लेनदेन को अक्सर परमाणु संचालन द्वारा प्रतिस्थापित किया जा सकता है। 10+ साल के SQL अनुभव को अनलर्न करना कठिन रहा है, लेकिन मैंने जो भी समस्या का सामना किया है, उसे सीधे समुदाय या 10gen द्वारा संबोधित किया गया है। हमने डेटा नहीं खोया है या कोई डाउनटाइम नहीं है जिसे मैं याद कर सकता हूं।
सीधे शब्दों में कहें तो, MongoDB सबसे अच्छा डेटा स्टोरेज इकोसिस्टम है जिसका मैंने कभी भी क्वेरी, रखरखाव, मापनीयता और विश्वसनीयता के मामले में उपयोग किया है। जब तक मेरे पास ऐसा एप्लिकेशन नहीं था जो इतना स्पष्ट रूप से संबंधपरक था कि मैं अच्छे विवेक में SQL के अलावा किसी अन्य चीज का उपयोग नहीं कर सकता, मैं MongoDB का उपयोग करने के लिए हर संभव प्रयास करूंगा।
मैं 10gen के लिए काम नहीं करता, लेकिन मैं उन लोगों के लिए बहुत आभारी हूं जो ऐसा करते हैं।
