MongoDB डेटा मॉडलिंग के दौरान विचार करने के लिए परिचालन कारक

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

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

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

1. मापनीयता
2. परमाणुता
3. प्रदर्शन और डेटा उपयोग
4. साझा करना
5. अनुक्रमण
6. संग्रहण अनुकूलन
7. दस्तावेज़ संरचना और विकास
8. डेटा जीवनचक्र

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

2. परमाणुता

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

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

आइए उदाहरण के लिए नीचे दिए गए डेटा सेट पर विचार करें

{
    childId : "535523",
    studentName : "James Karanja",
    parentPhone : 704251068,
    age : 12,
    settings : {
        location : "Embassy",
        address : "420 01",
        bus : "KAZ 450G",
        distance : "4"
      }
}

अगर हम उम्र को 1 से बढ़ाकर अपडेट करना चाहते हैं और स्थान को लंदन में बदलना चाहते हैं तो हम यह कर सकते हैं:

db.getCollection(‘students’).update({childId: 535523},{$set:{'settings.location':'London'}, $inc:{age:1}}).

उदाहरण के लिए यदि $set ऑपरेशन विफल हो जाता है, तो स्वचालित रूप से $inc ऑपरेशन लागू नहीं किया जाएगा और सामान्य तौर पर पूरा ऑपरेशन विफल हो जाता है।

दूसरी ओर, आइए संदर्भित डेटा पर विचार करें जैसे कि 2 संग्रह हैं एक छात्र के लिए और दूसरा सेटिंग्स के लिए।

छात्र संग्रह

{
    childId : "535523",
    studentName : "James Karanja",
    parentPhone : 704251068,
    age : 12
}

सेटिंग संग्रह

{
  childId : "535523",  
  location : "Embassy",
  address : "420 01",
  bus : "KAZ 450G",
  distance : "4"
}

इस मामले में आप उम्र और स्थान के मूल्यों को अलग-अलग लेखन कार्यों के साथ अपडेट कर सकते हैं। यानी

db.getCollection(‘students’).update({childId: 535523},{$inc:{age:1}})
db.getCollection('settings’).update({childId: 535523 } , {$set: { 'settings.location':'London'}})

यदि एक ऑपरेशन विफल हो जाता है, तो यह जरूरी नहीं कि दूसरे को प्रभावित करे क्योंकि वे अलग-अलग संस्थाओं के रूप में किए जाते हैं।

एकाधिक दस्तावेज़ों के लिए लेन-देन

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

आप एक से अधिक लेन-देन में जितना अधिक दस्तावेज़ अपडेट कर सकते हैं, यह एकल दस्तावेज़ लिखने की तुलना में कम प्रदर्शन के झटके के साथ आता है। इसके अलावा, यह दृष्टिकोण केवल WiredTiger स्टोरेज इंजन के लिए समर्थित है, इसलिए इन-मेमोरी और MMAPv1 स्टोरेज इंजन के लिए एक नुकसान है।

3. प्रदर्शन और डेटा उपयोग

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

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

4. साझा करना

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

5. अनुक्रमण

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

6. संग्रहण अनुकूलन

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

{ Lname : "Briston", score : 5.9 }

उपयोग करने के बजाय प्रति दस्तावेज़ 9 बाइट बचाएगा

{ last_name : "Briston", high_score: 5.9 }

स्पष्ट रूप से _id फ़ील्ड का प्रयोग करें। डिफ़ॉल्ट रूप से, MongoDB क्लाइंट इस फ़ील्ड के लिए एक अद्वितीय 12-बाइट ObjectId निर्दिष्ट करके प्रत्येक दस्तावेज़ में एक _id फ़ील्ड जोड़ते हैं। इसके अलावा, _id फ़ील्ड को अनुक्रमित किया जाएगा। यदि दस्तावेज़ बहुत छोटे हैं, तो यह परिदृश्य समग्र दस्तावेज़ संख्या में महत्वपूर्ण मात्रा में स्थान के लिए जिम्मेदार होगा। भंडारण अनुकूलन के लिए, आपको संग्रह में दस्तावेज़ सम्मिलित करते समय स्पष्ट रूप से _id फ़ील्ड के लिए मान निर्दिष्ट करने की अनुमति है। हालांकि, सुनिश्चित करें कि मान विशिष्ट रूप से पहचाना गया है क्योंकि यह संग्रह में दस्तावेज़ों के लिए प्राथमिक कुंजी के रूप में कार्य करता है।

7. दस्तावेज़ संरचना और विकास

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

8. डेटा जीवनचक्र

ऐसे एप्लिकेशन के लिए जो केवल हाल ही में सम्मिलित किए गए दस्तावेज़ों का उपयोग करता है, एक कैप्ड संग्रह का उपयोग करने पर विचार करें जिसकी विशेषताओं पर ऊपर चर्चा की गई है।

आप अपने संग्रह के लिए लाइव टू टाइम फीचर भी सेट कर सकते हैं। यह किसी एप्लिकेशन के लिए पासवर्ड रीसेट सुविधा में एक्सेस टोकन के लिए काफी लागू है।

टाइम टू लाइव (TTL)

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

उदाहरण:

db.log_events.createIndex( { "createdAt": 1 }, { expireAfterSeconds: 3600 } )

हमने बनाया एक इंडेक्स बनाया है और 3600 के कुछ एक्सपायर आफ्टरसेकंड वैल्यू को निर्दिष्ट किया है जो निर्माण के समय के 1 घंटे बाद है। अब यदि हम कोई दस्तावेज़ सम्मिलित करते हैं जैसे:

db.log_events.insert( {
   "createdAt": new Date(),
   "logEvent": 2,
   "logMessage": "This message was recorded."
} )

प्रविष्टि के 1 घंटे बाद यह दस्तावेज़ हटा दिया जाएगा।

जब आप दस्तावेज़ को हटाना चाहते हैं तो आप एक घड़ी विशिष्ट समय भी सेट कर सकते हैं। ऐसा करने के लिए, पहले एक इंडेक्स बनाएं यानी:

db.log_events.createIndex( { "expireAt": 1 }, { expireAfterSeconds: 0 } )

अब हम एक दस्तावेज़ सम्मिलित कर सकते हैं और उस समय को निर्दिष्ट कर सकते हैं जब इसे हटाया जाना चाहिए।

db.log_events.insert( {
   "expireAt": new Date(December 12, 2018 18:00:00'),
   "logEvent": 2,
   "logMessage": "Success!"
} )

यह दस्तावेज़ स्वचालित रूप से हटा दिया जाएगा जब समय सीमा समाप्त होने पर मान समाप्ति के बाद सेकंड में निर्दिष्ट सेकंड की संख्या से पुराना है, यानी इस मामले में 0।

निष्कर्ष

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