MongoDB स्कीमा डिज़ाइन - कई छोटे दस्तावेज़ या कम बड़े दस्तावेज़?


88

पृष्ठभूमि
मैं अपने RDBMS डेटाबेस से MongoDB में रूपांतरण का प्रोटोटाइप बना रहा हूं। निरूपित करते समय, ऐसा लगता है जैसे मेरे पास दो विकल्प हैं, एक जो छोटे दस्तावेजों के कई (लाखों) की ओर जाता है या एक जो कम (सैकड़ों हजारों) बड़े दस्तावेजों की ओर जाता है।

अगर मैं इसे एक साधारण एनालॉग में डिस्टिल कर सकता हूं, तो यह इस तरह के (जावा में) कम ग्राहक दस्तावेजों के साथ एक संग्रह के बीच का अंतर होगा:

क्लास कस्टमर {
    निजी स्ट्रिंग नाम;
    निजी पते का पता;
    // प्रत्येक क्रेडिटकार्ड में सैकड़ों भुगतान उदाहरण हैं
    निजी सेट <CreditCard> creditCards;
}

या इस तरह के कई भुगतान दस्तावेजों के साथ एक संग्रह:

वर्ग भुगतान {
    निजी ग्राहक ग्राहक;
    निजी क्रेडिटकार्ड क्रेडिटकार्ड;
    निजी दिनांक का भुगतान;
    निजी फ्लोट payAmount;
}

प्रश्न
क्या MongoDB कई, कई छोटे दस्तावेजों या कम बड़े दस्तावेजों को पसंद करने के लिए डिज़ाइन किया गया है? क्या जवाब ज्यादातर इस बात पर निर्भर करता है कि मैं दौड़ने के लिए किन प्रश्नों की योजना बना रहा हूं? (अर्थात ग्राहक X के पास कितने क्रेडिट कार्ड हैं? बनाम पिछले महीने सभी ग्राहकों द्वारा भुगतान की गई औसत राशि क्या थी?)

मैंने बहुत कुछ देखा है, लेकिन मैं किसी भी MongoDB स्कीमा सर्वोत्तम प्रथाओं में ठोकर नहीं खाई है जो मुझे अपने प्रश्न का उत्तर देने में मदद करेंगे।

जवाबों:


82

आपको निश्चित रूप से आपके द्वारा किए जा रहे प्रश्नों के लिए अनुकूलन करने की आवश्यकता होगी।

यहाँ आपके विवरण के आधार पर मेरा सबसे अच्छा अनुमान है।

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

भुगतान ऑब्जेक्ट स्वचालित रूप से अपनी आईडी और इंडेक्स होगा। आप संभवतः ग्राहक संदर्भ पर एक इंडेक्स भी जोड़ना चाहेंगे।

यह आपको हर बार पूरे ग्राहक ऑब्जेक्ट को स्टोर किए बिना ग्राहक द्वारा भुगतान के लिए जल्दी से खोज करने की अनुमति देगा।

यदि आप "पिछले महीने भुगतान किए गए सभी ग्राहकों की औसत राशि क्या थी" जैसे सवालों का जवाब देना चाहते हैं, तो आप किसी भी बड़े डेटासेट के लिए एक नक्शा / कम करना चाहते हैं। आपको यह प्रतिक्रिया "वास्तविक समय" नहीं मिल रही है। आप पाएंगे कि ग्राहक को "संदर्भ" संग्रहीत करना संभवतः इन मानचित्र-कमों के लिए पर्याप्त है।

तो सीधे आपके सवाल का जवाब देने के लिए: क्या MongoDB कई, कई छोटे दस्तावेजों या कम बड़े दस्तावेजों को पसंद करने के लिए डिज़ाइन किया गया है?

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


30

MongoDB के अपने दस्तावेज़ के अनुसार, ऐसा लगता है कि यह कई छोटे दस्तावेज़ों के लिए डिज़ाइन किया गया है।

MongoDB के लिए प्रदर्शन सर्वोत्तम प्रथाओं से :

MongoDB में दस्तावेजों के लिए अधिकतम आकार 16 एमबी है। व्यवहार में अधिकांश दस्तावेज कुछ किलोबाइट या कम होते हैं। तालिका की तुलना में तालिका में पंक्तियों जैसे दस्तावेजों पर अधिक विचार करें। किसी एकल दस्तावेज़ में रिकॉर्ड की सूची बनाए रखने के बजाय, प्रत्येक रिकॉर्ड को एक दस्तावेज़ बनाएं।

से भाग 1: MongoDB स्कीमा डिजाइन के लिए अंगूठे के 6 नियम :

मॉडलिंग एक-से-कुछ

"एक-से-कुछ" का एक उदाहरण किसी व्यक्ति के लिए पते हो सकते हैं। यह एम्बेड करने के लिए एक अच्छा उपयोग मामला है - आप अपने व्यक्तिगत ऑब्जेक्ट के अंदर एक सरणी में पते डालेंगे।

अनेको के लिये एक

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

एक-से-Squillions

"वन-टू-स्क्विलेशन" का एक उदाहरण एक इवेंट लॉगिंग सिस्टम हो सकता है जो विभिन्न मशीनों के लिए लॉग संदेश एकत्र करता है। कोई भी होस्ट होस्ट 16 एमबी दस्तावेज़ आकार को ओवरफ्लो करने के लिए पर्याप्त संदेश उत्पन्न कर सकता है, भले ही आप सरणी में संग्रहीत सभी ऑब्जेक्ट ऑब्जेक्ट थे। यह "पैरेंट-रेफ़रिंग" के लिए क्लासिक उपयोग का मामला है - आपके पास होस्ट के लिए एक दस्तावेज़ होगा, और फिर लॉग संदेशों के लिए दस्तावेज़ में होस्ट के ऑब्जेक्ट को संग्रहीत करें।


11

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

सबसे पहले, दो संग्रह पर विचार करें: ग्राहक और भुगतान। इस प्रकार, अनाज काफी छोटा है: प्रति भुगतान एक दस्तावेज़।

आगे आपको यह तय करना होगा कि खाता जानकारी कैसे जमा करें, जैसे कि क्रेडिट कार्ड। आइए विचार करें कि क्या ग्राहक दस्तावेजों में खाते की जानकारी के सरणियाँ हैं या आपको नए खाता संग्रह की आवश्यकता है या नहीं।

यदि खाता दस्तावेज़ ग्राहक दस्तावेज़ों से अलग हैं, तो स्मृति में एक ग्राहक के लिए सभी खातों को लोड करने के लिए कई दस्तावेज़ लाने की आवश्यकता होती है। यह अतिरिक्त मेमोरी, I / O, बैंडविड्थ और CPU उपयोग में अनुवाद कर सकता है। क्या इसका मतलब यह है कि खाता संग्रह एक बुरा विचार है?

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

भुगतान दस्तावेज़ में वास्तव में निश्चित समयसीमा में किए गए सभी भुगतान शामिल हो सकते हैं (जैसे, दिन?)। ऐसी जटिलता उन सभी कोड को प्रभावित करेगी जो भुगतान दस्तावेज़ पढ़ते और लिखते हैं। समयपूर्व अनुकूलन परियोजनाओं के लिए घातक हो सकता है।

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

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

मुझे आपके निष्कर्षों के बारे में सुनना अच्छा लगेगा। सौभाग्य!

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.