नेवला आबाद बनाम वस्तु घोंसला बनाना

नेवले की आबादी के बारे में समझने वाली पहली बात यह है कि यह कोई जादू नहीं है, बल्कि एक सुविधाजनक तरीका है जो आपको बिना सब कुछ किए संबंधित जानकारी प्राप्त करने की अनुमति देता है।

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

"जादू नहीं" भाग यह है कि अनिवार्य रूप से कवर के तहत क्या होता है कि जब आप किसी अन्य स्रोत को "संदर्भित" करते हैं, तो पॉप्युलेट फ़ंक्शन माता-पिता के उन परिणामों को "विलय" करने के लिए उस "संबंधित" संग्रह के लिए एक अतिरिक्त क्वेरी/प्रश्न करता है। वस्तु जिसे आपने पुनः प्राप्त किया है। आप इसे स्वयं कर सकते हैं, लेकिन कार्य को सरल बनाने की सुविधा के लिए विधि मौजूद है। स्पष्ट "प्रदर्शन" विचार यह है कि सभी जानकारी पुनर्प्राप्त करने के लिए डेटाबेस (मोंगोडीबी इंस्टेंस) के लिए एक भी राउंड ट्रिप नहीं है। हमेशा एक से अधिक होते हैं।

एक नमूने के रूप में, दो संग्रह लें:

{ 
    "_id": ObjectId("5392fea00ff066b7d533a765"),
    "customerName": "Bill",
    "items": [
        ObjectId("5392fee10ff066b7d533a766"),
        ObjectId("5392fefe0ff066b7d533a767")
    ]
}

और आइटम:

{ "_id": ObjectId("5392fee10ff066b7d533a766"), "prod": "ABC", "qty": 1 }
{ "_id": ObjectId("5392fefe0ff066b7d533a767"), "prod": "XYZ", "qty": 2 }

"सर्वश्रेष्ठ" जो "संदर्भित" मॉडल द्वारा किया जा सकता है या पॉप्युलेट (हुड के नीचे) का उपयोग यह है:

var order = db.orders.findOne({ "_id": ObjectId("5392fea00ff066b7d533a765") });
order.items = db.items.find({ "_id": { "$in": order.items } ).toArray();

तो उस डेटा को "जुड़ने" के लिए स्पष्ट रूप से "कम से कम" दो प्रश्न और संचालन हैं।

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

डेटा तो इस तरह दिखता है (उपरोक्त उदाहरण की तुलना में):

{ 
    "_id": ObjectId("5392fea00ff066b7d533a765"),
    "customerName": "Bill",
    "items": [
        { "_id": ObjectId("5392fee10ff066b7d533a766"), "prod": "ABC", "qty": 1 },
        { "_id": ObjectId("5392fefe0ff066b7d533a767"), "prod": "XYZ", "qty": 2 }
    ]
}

इसलिए वास्तव में डेटा लाना केवल एक मामला है:

db.orders.findOne({ "_id": ObjectId("5392fea00ff066b7d533a765") });

दोनों में से किसी एक के फायदे और नुकसान हमेशा आपके आवेदन के उपयोग पैटर्न पर निर्भर करते हैं। लेकिन एक नज़र में:

एम्बेडिंग

• एम्बेड किए गए डेटा के साथ कुल दस्तावेज़ का आकार आम तौर पर 16 एमबी स्टोरेज (बीएसओएन सीमा) से अधिक नहीं होगा या अन्यथा (दिशानिर्देश के रूप में) में एरे होते हैं जिनमें 500 या अधिक प्रविष्टियां होती हैं।

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

• संबंधित डेटा अक्सर माता-पिता के सहयोग से उपयोग किया जाता है। जिसका अर्थ है कि यदि आपके "पढ़ने/लिखने" के मामलों को माता-पिता और बच्चे दोनों को हमेशा "पढ़ने/लिखने" की आवश्यकता होती है तो परमाणु संचालन के लिए डेटा एम्बेड करना समझ में आता है।

संदर्भित करना

• संबंधित डेटा हमेशा 16MB BSON सीमा से अधिक होने वाला है। आप हमेशा "बकेटिंग" के एक संकर दृष्टिकोण पर विचार कर सकते हैं, लेकिन मुख्य दस्तावेज़ की सामान्य कठोर सीमा का उल्लंघन नहीं किया जा सकता है। सामान्य मामले "पोस्ट" और "टिप्पणियां" हैं जहां "टिप्पणी" गतिविधि बहुत बड़ी होने की उम्मीद है।

• संबंधित डेटा को नियमित रूप से अपडेट करने की आवश्यकता है। या अनिवार्य रूप से वह मामला जहां आप "सामान्यीकरण" करते हैं क्योंकि वह डेटा कई माता-पिता के बीच "साझा" होता है और "संबंधित" डेटा को अक्सर इतना बदल दिया जाता है कि हर "माता-पिता" में एम्बेडेड आइटम को अपडेट करना अव्यावहारिक होगा जहां वह "बच्चा" आइटम होता है . आसान मामला केवल "बच्चे" को संदर्भित करना और एक बार परिवर्तन करना है।

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

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

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

1. ध्यान दें कि चूंकि यह मूल रूप से लिखा गया था, MongoDB ने $lookup . पेश किया ऑपरेटर जो वास्तव में सर्वर पर संग्रह के बीच "जॉइन" करता है। यहां सामान्य चर्चा के प्रयोजनों के लिए, अधिकांश परिस्थितियों में "बेहतर" सीटी बजाएं कि populate() द्वारा किए गए "एकाधिक क्वेरी" ओवरहेड और सामान्य रूप से "एकाधिक प्रश्न", अभी भी एक "महत्वपूर्ण ओवरहेड" . है किसी भी $lookup . के साथ किया गया ऑपरेशन।

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