MongoDB
 sql >> डेटाबेस >  >> NoSQL >> MongoDB

मोंगो में नेस्टेड श्रेणियों (या पदानुक्रमित डेटा) को स्टोर करने का सबसे प्रभावी तरीका?

सबसे पहले आप यह तय करना चाहते हैं कि आप किस प्रकार के पेड़ का उपयोग करेंगे।

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

तो आप एक ऐसा स्कीमा चाहते हैं जो आपको पथ के माध्यम से बच्चे पर जल्दी से पूछताछ करने की शक्ति देता है, यानी:खेल -> बास्केटबॉल -> पुरुष, खेल -> टेनिस -> महिला, और वास्तव में अपडेट के पैमाने की आवश्यकता नहीं है।

जैसा कि आपने ठीक ही बताया है कि MongoDB के पास इसके लिए एक अच्छा दस्तावेज़ीकरण पृष्ठ है:https://docs.mongodb.com/manual/applications/data-models-tree-structures/ जिससे 10gen वास्तव में पेड़ों के लिए विभिन्न मॉडलों और स्कीमा विधियों को बताता है और उनके मुख्य उतार-चढ़ाव का वर्णन करता है।

यदि आप आसानी से क्वेरी करना चाहते हैं, तो जिस पर ध्यान दिया जाना चाहिए, वह है भौतिक पथ:https://docs.mongodb.com/manual/tutorial/model-tree-structures-with-materialized-paths/

पेड़ों के निर्माण के लिए यह एक बहुत ही दिलचस्प तरीका है क्योंकि आपने "टेनिस" में "महिला" में दिए गए उदाहरण पर पूछताछ करने के लिए आप बस एक पूर्व-निर्धारित रेगेक्स कर सकते हैं (जो इंडेक्स का उपयोग कर सकते हैं:http://docs.mongodb.org/manual/reference/operator/regex/ ) ऐसा ही:

db.products.find({category: /^Sports,Tennis,Womens[,]/})

अपने पेड़ के एक निश्चित पथ के तहत सूचीबद्ध सभी उत्पादों को खोजने के लिए।

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

एक बेहतर तरीका यह होगा कि एक cat_id रखा जाए उत्पाद पर और फिर श्रेणियों को स्कीमा के साथ एक अलग संग्रह में अलग करें:

{
    _id: ObjectId(),
    name: 'Women\'s',
    path: 'Sports,Tennis,Womens',
    normed_name: 'all_special_chars_and_spaces_and_case_senstive_letters_taken_out_like_this'
}

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

तो "टेनिस" को "बैडमिन" में बदलने का एक उदाहरण:

db.categories.update({path:/^Sports,Tennis[,]/}).forEach(function(doc){
    doc.path = doc.path.replace(/,Tennis/, ",Badmin");
    db.categories.save(doc);
});

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

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

बेशक अतिरिक्त लाभ यह है कि यह स्कीमा नेस्टेड सेट मॉडल के साथ संगत है:http://en.wikipedia .org/wiki/Nested_set_model जो मैंने पाया है और समय फिर से ई-कॉमर्स साइटों के लिए बहुत बढ़िया हैं, उदाहरण के लिए, टेनिस "स्पोर्ट्स" और "लेज़र" दोनों के अंतर्गत हो सकता है और आप इस पर निर्भर करते हुए कई पथ चाहते हैं कि उपयोगकर्ता कहां से आया है।

भौतिक पथों के लिए स्कीमा केवल एक और path . जोड़कर आसानी से इसका समर्थन करता है , इतना आसान।

आशा है कि यह समझ में आता है, वहां काफी लंबा है।



  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. लूप में बुलाए गए डीबी प्रश्नों से पुनर्प्राप्त डेटा लौटाने में समस्या

  2. समय-आधारित सॉर्ट और लिमिट इश्यू को चेन करना

  3. MongoDB प्रमाणीकरण Linux सर्वर पर सक्षम नहीं है

  4. कैसे हर आधी रात को स्वचालित रूप से एक MongoDB संग्रह अद्यतन करने के लिए?

  5. अतिभारित संपत्ति का अप्रत्यक्ष संशोधन App\Dossier::$program का कोई प्रभाव नहीं है