MongoDB क्या है?

Scrapeless Web Unlocker सार्वजनिक वेब सामग्री प्राप्त करता है जिसे संग्रह सेवाएँ मान्य कर सकती हैं और MongoDB दस्तावेज़ों के रूप में स्टोर कर सकती हैं।

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

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

दस्तावेज़ और कलेक्शन डेटा को व्यवस्थित करते हैं

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

MongoDB स्टोर किए गए दस्तावेज़ों के लिए BSON का उपयोग करता है। BSON, साधारण JSON की तुलना में प्रकारों के व्यापक सेट का समर्थन करता है, इसलिए कोई तारीख या पहचानकर्ता ड्राइवर और एप्लिकेशन की सीमा के पार अपना इच्छित प्रकार बनाए रखना चाहिए। JSON जैसे सुविधाजनक डिस्प्ले का होना इस बात का प्रमाण नहीं है कि हर मान बस एक JSON स्ट्रिंग या संख्या है।

" JSON इंटरचेंज फॉर्मेट " तब भी प्रासंगिक रहता है जब दस्तावेज़ API या एक्सपोर्ट्स के माध्यम से आते हैं। किसी दस्तावेज़ को JSON में बदलने के लिए समृद्ध डेटाबेस प्रकारों के बारे में स्पष्ट निर्णयों की आवश्यकता हो सकती है। इन निर्णयों को एक्सपोर्ट अनुबंध का हिस्सा बनाएं ताकि कोई अन्य उपभोक्ता इच्छित अर्थ का पुनर्निर्माण कर सके।

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

लचीले स्कीमा को स्थिर अर्थों की आवश्यकता होती है

लचीला स्कीमा विकसित होते रिकॉर्ड्स का समर्थन करता है, जबकि स्थिर फ़ील्ड अर्थ उन रिकॉर्ड्स को उपयोगी बनाए रखते हैं। कोई स्रोत अवलोकन एक नया वैकल्पिक फ़ील्ड जोड़ सकता है, बिना यह माँग किए कि हर पुराना दस्तावेज़ उसे शामिल करे। उपभोक्ता को फिर भी यह जानने की ज़रूरत होती है कि अनुपस्थिति का अर्थ अनुपलब्ध, संग्रहीत नहीं, या लागू नहीं है।

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

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

एम्बेडिंग और रेफरेंसिंग एक्सेस पैटर्न का पालन करते हैं

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

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

डुप्लिकेशन को अपडेट नीति की आवश्यकता होती है। यदि किसी श्रेणी लेबल को कई दस्तावेज़ों में कॉपी किया जाता है, तो श्रेणी बदलने पर कलेक्शन में अलग-अलग संस्करण छूट सकते हैं। कभी-कभी वह वांछनीय ऐतिहासिक संदर्भ होता है; कभी-कभी वह आकस्मिक असंगति होती है। तय करें कि एम्बेड किया गया मान एक स्नैपशॉट है या वर्तमान संबंध।

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

इंडेक्स क्वेरीज़ का समर्थन करते हैं और लिखने का काम बढ़ाते हैं

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

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

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

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

एक सार्वजनिक उत्पाद प्रेक्षण का मॉडल बनाना

किसी उत्पाद प्रेक्षण दस्तावेज़ को स्रोत इकाई को उसे देखने की क्रिया से अलग पहचानना चाहिए। उत्पाद की पहचान क्रमिक प्रेक्षणों को जोड़ती है, जबकि प्रेक्षण की पहचान अलग‑अलग संग्रह घटनाओं को अलग करती है। यह अनुप्रयोग को यह दिखावा किए बिना बदलावों की तुलना करने देता है कि हर डाउनलोड एक नया उत्पाद वर्णन करता है।

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

अनुपस्थित कीमत एक ऐसा प्रेक्षण परिणाम बनी रहनी चाहिए जिसे अनुप्रयोग समझा सके। यह किसी अनुपलब्ध फ़ील्ड, अस्वीकृत प्रतिक्रिया, या ऐसे स्रोत पृष्ठ को दर्शा सकती है जो कीमत प्रकाशित नहीं करता। इन स्थितियों के ऐतिहासिक रुझान के लिए अलग‑अलग निहितार्थ हैं और इन्हें सभी को एक संख्यात्मक शून्य नहीं बना देना चाहिए।

अपडेट, ट्रांज़ैक्शन, और समवर्ती लेखक

MongoDB एकल दस्तावेज़ पर परमाणु (atomic) संचालन का समर्थन करता है और उपयुक्त वर्कलोड के लिए मल्टी‑दस्तावेज़ लेनदेन प्रदान करता है। फिर भी अनुप्रयोग को ऐसा अपडेट सीमा‑क्षेत्र चुनना होता है जो उसकी स्थिरता आवश्यकता से मेल खाता हो। किसी फ़ीचर का उपलब्ध होना यह निर्धारित नहीं करता कि हर कलेक्टर को उसे कैसे इस्तेमाल करना चाहिए।

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

एक ऐतिहासिक प्रेक्षण संग्रह स्वीकृत प्रेक्षणों को अलग‑अलग रखकर कुछ ओवरराइट अस्पष्टता से बच सकता है। वर्तमान दृश्य तब स्वीकृत इतिहास से प्रलेखित नियम के तहत व्युत्पन्न किया जा सकता है। यह मॉडलिंग की जिम्मेदारी जोड़ता है, लेकिन यह समझाना आसान बनाता है कि प्रदर्शित मान कैसे चुना गया।

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

रेप्लिकेशन, शार्डिंग और रिटेंशन के अलग‑अलग काम हैं

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

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

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

कच्ची सामग्री और स्वीकृत प्रेक्षणों के अलग‑अलग रिटेंशन पीरियड हो सकते हैं। केवल वही साक्ष्य रखें जिसकी अनुप्रयोग को ज़रूरत है, उसे उचित रूप से सुरक्षित रखें, और समाप्त हो चुकी डायग्नोस्टिक सामग्री को जानबूझकर हटा दें। परिचालन योजना में संग्रह माँग और Scrapeless pricing को शामिल करें ताकि स्रोत कवरेज बढ़ाने का लागत प्रभाव नया कार्य निर्धारित होने से पहले समझा जा सके।

निष्कर्ष

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