MongoDB में योजना और प्रबंधन योजनाएँ (भले ही यह बिना योजना के हो)

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

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

एक से कुछ मॉडलिंग (एम्बेडिंग)

यह डिज़ाइन दस्तावेज़ एम्बेड करने का एक बहुत अच्छा उदाहरण है। इस मॉडलिंग को स्पष्ट करने के लिए व्यक्ति संग्रह के इस उदाहरण पर विचार करें।

{
  name: "Amy Cooper",
  hometown: "Seoul",
  addresses: [
    { city: 'New York', state: 'NY', cc: 'USA' },
    { city: 'Jersey City', state: 'NJ', cc: 'USA' }
  ]
}

पेशेवरों:

• आप एक ही प्रश्न में सारी जानकारी प्राप्त कर सकते हैं।

विपक्ष:

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

वन-टू-मैनी मॉडलिंग (संदर्भ)

इस प्रकार के मॉडलिंग में, मूल दस्तावेज़ में चाइल्ड दस्तावेज़ों का संदर्भ आईडी (ऑब्जेक्ट आईडी) होगा। दस्तावेज़ों को पुनः प्राप्त करने के लिए आपको एप्लिकेशन लेवल जॉइन (आवेदन स्तर पर डीबी से पुनर्प्राप्त करने के बाद दो दस्तावेज़ों को मिलाकर) का उपयोग करने की आवश्यकता है, इसलिए कोई डेटाबेस स्तर शामिल नहीं होता है। इसलिए, डेटाबेस पर लोड कम हो जाएगा। इस उदाहरण पर विचार करें:

// Parts collection
{
  _id: ObjectID(1234),
  partno: '1',
  name: ‘Intel 100 Ghz CPU',
  qty: 100,
  cost: 1000,
  price: 1050
}
// Products collection
{
  name: 'Computer WQ-1020',
  manufacturer: 'ABC Company',
  catalog_number: 1234,
  parts: [
    ObjectID(‘1234’), <- Ref. for Part No: 1
    ObjectID('2345'),
    ObjectID('3456')
  ]
}

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

पेशेवरों:

• इस प्रकार के मॉडलिंग में, प्रत्येक भाग एक अलग दस्तावेज़ है ताकि आप इन दस्तावेज़ों पर सभी भाग संबंधी प्रश्नों को लागू कर सकें। मूल दस्तावेज़ पर निर्भर होने की आवश्यकता नहीं है।
• प्रत्येक दस्तावेज़ पर स्वतंत्र रूप से CRUD (क्रिएट, रीड, अपडेट, राइट) ऑपरेशन करना बहुत आसान है।

विपक्ष:

• इस पद्धति के साथ एक बड़ी कमी यह है कि आपको भाग विवरण प्राप्त करने के लिए एक अतिरिक्त प्रश्न करना होगा। ताकि आप आवश्यक परिणाम सेट प्राप्त करने के लिए उत्पाद दस्तावेज़ के साथ एप्लिकेशन-लेवल जॉइन कर सकें। तो इससे डीबी प्रदर्शन में गिरावट आ सकती है।

एक-से-लाखों मॉडलिंग (माता-पिता का संदर्भ)

जब आपको प्रत्येक दस्तावेज़ में टन डेटा संग्रहीत करने की आवश्यकता होती है, तो आप उपरोक्त किसी भी दृष्टिकोण का उपयोग नहीं कर सकते क्योंकि MongoDB की आकार सीमा 16MB प्रति दस्तावेज़ है। इस तरह के परिदृश्य का एक आदर्श उदाहरण एक इवेंट लॉगिंग सिस्टम हो सकता है जो विभिन्न प्रकार की मशीनों से लॉग एकत्र करता है और उन्हें लॉग और मशीन संग्रह में संग्रहीत करता है।

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

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

// Machines collection
{
  _id : ObjectID('AAA'),
  name : 'mydb.example.com',
  ipaddr : '127.66.0.4'
}
// Logs collection
{
  time : ISODate("2015-09-02T09:10:09.032Z"),
  message : 'WARNING: CPU usage is critical!',
  host: ObjectID('AAA')       -> references Machine document
}

मान लीजिए कि आप मशीन 127.66.0.4 के नवीनतम 3000 लॉग ढूंढना चाहते हैं:

machine = db.machines.findOne({ipaddr : '127.66.0.4'});
msgs = db.logmsg.find({machine: machine._id}).sort({time : -1}).limit(3000).toArray()

दोतरफा संदर्भ

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

// person
{
  _id: ObjectID("AAAA"),
  name: "Bear",
  tasks [ 
    ObjectID("AAAD"),
    ObjectID("ABCD"), -> Reference of child document
    ObjectID("AAAB")
  ]
}
// tasks
{
  _id: ObjectID("ABCD"),
  description: "Read a Novel",
  due_date:  ISODate("2015-11-01"),
  owner: ObjectID("AAAA") -> Reference of parent document
}

निष्कर्ष

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

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