MongoDB स्कीमा योजना युक्तियाँ

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

आपके आवेदन के अनुरूप सर्वोत्तम स्कीमा डिज़ाइन का पता लगाना कभी-कभी कठिन हो सकता है। यहां कुछ बिंदु दिए गए हैं जिन पर आप अपना स्कीमा तैयार करते समय विचार कर सकते हैं।

दस्तावेज़ों को विकसित करने से बचें

यदि आपकी स्कीमा लगातार आकार में बढ़ने वाले दस्तावेज़ बनाने की अनुमति देती है तो आपको इससे बचने के लिए कदम उठाने चाहिए क्योंकि इससे डीबी और डिस्क आईओ प्रदर्शन में गिरावट आ सकती है। डिफ़ॉल्ट रूप से, MongoDB प्रति दस्तावेज़ 16MB आकार की अनुमति देता है। यदि आपके दस्तावेज़ का आकार समय के साथ 16 एमबी से अधिक बढ़ जाता है, तो यह खराब स्कीमा डिज़ाइन का संकेत है। यह कभी-कभी प्रश्नों की विफलता का कारण बन सकता है। इस स्थिति से बचने के लिए आप दस्तावेज़ बकेट या दस्तावेज़ पूर्व-आवंटन तकनीकों का उपयोग कर सकते हैं। यदि आपके आवेदन को 16 एमबी से अधिक आकार के दस्तावेजों को संग्रहीत करने की आवश्यकता है तो आप मोंगोडीबी ग्रिडएफएस एपीआई का उपयोग करने पर विचार कर सकते हैं।

संपूर्ण दस्तावेज़ों को अपडेट करने से बचें

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

एप्लिकेशन-लेवल जॉइन से बचने की कोशिश करें

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

उचित अनुक्रमण का उपयोग करें

खोज या एकत्रीकरण करते समय, व्यक्ति अक्सर डेटा को सॉर्ट करता है। भले ही आप पाइपलाइन के अंतिम चरण में सॉर्ट करने के लिए आवेदन करते हैं, फिर भी आपको सॉर्ट को कवर करने के लिए एक इंडेक्स की आवश्यकता होती है। यदि सॉर्टिंग फ़ील्ड पर अनुक्रमणिका उपलब्ध नहीं है, तो MongoDB को बिना अनुक्रमणिका के सॉर्ट करने के लिए बाध्य किया जाता है। सॉर्ट ऑपरेशन में शामिल सभी दस्तावेज़ों के कुल आकार की मेमोरी सीमा 32MB है। यदि MongoDB उस सीमा को हिट करता है तो यह या तो एक त्रुटि उत्पन्न कर सकता है या एक खाली सेट लौटा सकता है।

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

किसी अनुक्रमणिका के उपयोग को अनुकूलित करने का एक और तरीका डिफ़ॉल्ट _id फ़ील्ड को ओवरराइड करना है। इस क्षेत्र का एकमात्र उद्देश्य प्रति दस्तावेज़ एक अद्वितीय फ़ील्ड रखना है। यदि आपके डेटा में टाइमस्टैम्प या कोई आईडी फ़ील्ड है तो आप _id फ़ील्ड को ओवरराइड कर सकते हैं और एक अतिरिक्त अनुक्रमणिका सहेज सकते हैं।

v/s लिखें अनुपात पढ़ें

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

बीएसओएन डेटा प्रकार

सुनिश्चित करें कि आप स्कीमा डिजाइन करते समय सभी क्षेत्रों के लिए बीएसओएन डेटा प्रकारों को ठीक से परिभाषित करते हैं। क्योंकि जब आप किसी भी फ़ील्ड के डेटा प्रकार को बदलते हैं, तो MongoDB पूरे दस्तावेज़ को एक नए मेमोरी स्पेस में फिर से लिख देगा। उदाहरण के लिए, यदि आप (float)0.0 फ़ील्ड के स्थान पर (int)0 स्टोर करने का प्रयास करते हैं, तो MongoDB BSON डेटा प्रकार में परिवर्तन के कारण पूरे दस्तावेज़ को एक नए पते पर फिर से लिखता है।

निष्कर्ष

संक्षेप में, अपने Mongo डेटाबेस के लिए स्कीमा डिज़ाइन करना बुद्धिमानी है क्योंकि यह केवल आपके एप्लिकेशन के प्रदर्शन में सुधार करेगा। संस्करण 3.2 से शुरू होकर, MongoDB ने दस्तावेज़ सत्यापन का समर्थन करना शुरू कर दिया है जहाँ आप परिभाषित कर सकते हैं कि एक नया दस्तावेज़ सम्मिलित करने के लिए किन क्षेत्रों की आवश्यकता है। संस्करण 3.6 से, MongoDB ने JSON स्कीमा सत्यापन का उपयोग करके स्कीमा सत्यापन को लागू करने का एक अधिक सुंदर तरीका पेश किया। इस सत्यापन पद्धति का उपयोग करके, आप आवश्यक फ़ील्ड जाँच के साथ-साथ डेटा प्रकार जाँच को लागू कर सकते हैं। आप उपरोक्त तरीकों का उपयोग यह जांचने के लिए कर सकते हैं कि सभी दस्तावेज़ एक ही प्रकार के स्कीमा का उपयोग कर रहे हैं या नहीं।