2012-12-10 18 views
22

मेरे पास एक सामान्य डेटाबेस संरचना प्रश्न है। मेरे परिदृश्य में मैं mongodb का उपयोग कर रहा हूँ।मोंगोडीबी संरचना: एकल संग्रह बनाम एकाधिक छोटे संग्रह

मैं एक ऐसा एप्लिकेशन बना रहा हूं जहां उपयोगकर्ता गानों (शीर्षक, कलाकार इत्यादि) की एक सूची अपलोड कर सके, लेकिन मुझे यकीन नहीं है कि मेरे पास एक गीत होना चाहिए या सभी उपयोगकर्ताओं के लिए लिस्ट संग्रह या अलग गीत List.user # संग्रह प्रत्येक व्यक्तिगत उपयोगकर्ता। उपयोगकर्ता केवल उनसे जुड़े गीतों को ही पूछ सकते हैं ताकि उपयोगकर्ता ए को उपयोगकर्ता बी के गीतों के बारे में कभी पता न हो।

कोड उदाहरण:

उपयोगकर्ता

db.songList.userA.find() 
{"title": "Some song of user A", "artist": "Some artist of user A"} 

db.songList.userB.find() 
{"title": "Some song of user B", "artist": "Some artist of user B"} 
  • पेशेवरों
    • छोटे संग्रह आकार प्रति एकाधिक संग्रह क्वेरी करने के लिए
  • विपक्ष
    • अनुरक्षणीयता
      • 1,000 उपयोगकर्ताओं 1,000 संग्रह

बनाम एक मालिक के साथ एक संग्रह 'उपयोगकर्ता' फ़ील्ड का मतलब

db.songList.find({"user":"A"}) 
{"title": "Some song of user A", "artist": "Some artist of user A", "user": "A"} 
  • पेशेवरों
    • लचीलापन उपयोगकर्ताओं भर में क्वेरी करने के लिए करता है, तो कभी जरूरत arised
  • विपक्ष
    • प्रदर्शन

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

अग्रिम धन्यवाद।

+3

इस तरह की चीजों के बारे में चिंता करने के बजाय, * कुछ * बनाएं। विवरणों के बारे में चिंता करने की बजाय, आपको शायद यह पता चल जाएगा कि इसे बनाने से सबसे अच्छा क्या होगा। – SomeKittens

+0

@ सोमकिट्टन के साथ सहमत हैं। उस ने कहा, मैं प्रति उपयोगकर्ता इसे करूँगा क्योंकि गलती करना आसान है और बी के लिए ए के गाने दिखाएं। वैसे भी, अगर मेरे पास पर्याप्त उपयोगकर्ता थे तो मैं अनुकूलन के बारे में चिंता करूंगा। –

+0

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

उत्तर

8

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

इसलिए एक छोटा संग्रह आकार वास्तव में एक समर्थक नहीं है और मुझे यकीन नहीं है कि यह सिद्धांत कहां आता है, यह एसक्यूएल में नहीं है और यह मोंगोडीबी में नहीं है। शेर्डिंग का प्रदर्शन, यदि अच्छी तरह से किया जाता है, तो डेटा के एक छोटे से संग्रह (छोटे ओवरहेड के साथ) पूछताछ के प्रदर्शन के सापेक्ष होना चाहिए। यदि ऐसा नहीं है तो आपने अपना शेर्डिंग गलत स्थापित कर लिया है।

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

इस प्रकार यदि प्रत्येक संग्रह में एक अनुक्रमणिका होती है, तो हम 12,000 संग्रह बना सकते हैं। --nssize पैरामीटर आपको इस सीमा को बढ़ाने की अनुमति देता है (नीचे देखें)।

+0

मैंने इसे पढ़ा था [http://stackoverflow.com/questions/11514781/mongodb-performance-issue-single-huge-collection-vs-multiple-small-collections) जिसने मुझे विश्वास दिलाया कि मुझे एक महत्वपूर्ण दिखाई देगा कई छोटे संग्रह के साथ प्रदर्शन लाभ। क्या आप कह रहे हैं कि क्या मुझे उपयोगकर्ता फ़ील्ड पर एक शार्ड कुंजी के साथ एक संग्रह होना था, मुझे एक समान प्रदर्शन लाभ देखना चाहिए? – Steven

+0

वहां बहुत सारे अज्ञात हैं कि यह कहने के लिए कि वह उन समय क्यों प्राप्त कर रहा था, क्वेरी समय हार्डवेयर, इंडेक्स, डेटा, सामान्यीकरण इत्यादि पर निर्भर हैं। हालांकि, उन्होंने ध्यान दिया कि क्वेरी बहुत तेज थी जब उनके पास बड़ी संख्या में रिकॉर्ड थे, समस्या तब थी जब वह अपनी अनुक्रमणिका के भीतर चुनिंदाता की एक छोटी संख्या का उपयोग कर रहा था (मूल्य> 100 के साथ कम संख्या के रिकॉर्ड) जो मुझे विश्वास दिलाता है कि उसकी अनुक्रमणिका उसकी क्वेरी के लिए अच्छा नहीं था। – Sammaye

+1

हां, user_id जैसे कुछ पर एक शार्ड कुंजी (यहां अनुमान लगाने का थोड़ा सा, आपको वास्तव में वास्तव में अपने डेटा के लिए इसे वास्तव में खोजना चाहिए) उपयोगकर्ता_आईडी युक्त प्रश्नों के लिए एक सभ्य वापसी का उत्पादन करेगा। हालांकि यह शेरिंग के साथ पूरी तस्वीर नहीं है और मैं दृढ़ता से अनुशंसा करता हूं कि आप यहां कुछ खोज करें और तुरंत सोचें कि उपयोगकर्ता_आईडी आपकी शेडिंग समस्याओं को हल करेगी। – Sammaye

11

मैं प्रति उपयोगकर्ता अलग संग्रह बनाने के लिए NOT की अनुशंसा करता हूं।

documentation

डिफ़ॉल्ट रूप से MongoDB डेटाबेस प्रति लगभग 24,000 नामस्थान की एक सीमा होती है पढ़ें। प्रत्येक नेमस्पेस 628 बाइट्स है, .ns फ़ाइल 16 एमबी डिफ़ॉल्ट है।

प्रत्येक संग्रह प्रत्येक इंडेक्स के रूप में नामस्थान के रूप में गिना जाता है।इस प्रकार यदि प्रत्येक संग्रह में एक अनुक्रमणिका थी, तो हम 12,000 संग्रह बना सकते हैं। --nssize पैरामीटर आपको इस सीमा को (नीचे देखें) को बढ़ाने की अनुमति देता है।

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

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

अद्यतन

@Henry लियू टिप्पणी में उल्लेख किया है। वायर्ड टाइगर स्टोरेज इंजन का उपयोग कर मोंगोड 3.0 या उससे ऊपर के लिए, यह अब सीमा नहीं होगी।

docs.mongodb.org/manual/reference/limits/#namespaces

+0

जानकारी के लिए धन्यवाद लेकिन अगले पैराग्राफ को पढ़ने से पता चलता है कि इस सीमा को अधिकतम करने के लिए कैसे उपयोग किया जा सकता है (अधिकतम .ns फ़ाइल आकार 2 जीबी है)। इसलिए यदि प्रत्येक गीत सूची संग्रह में केवल 1 इंडेक्स है तो मैं सैद्धांतिक रूप से 2 जीबी के आने से पहले 240,000+ संग्रह कर सकता हूं। (अगर इस संग्रह में 2 इंडेक्स होते हैं तो यह सीमा लगभग आधे में कट जाती है)। – Steven

+0

आप स्पष्ट रूप से किसी भी तरह से मॉडल कर सकते हैं। मैंने जो कुछ किया वह एक सुंदर दृष्टिकोण की सिफारिश की गई थी :) –

+0

धन्यवाद आपका इनपुट बहुत उपयोगी था, इस जानकारी को पढ़ने के बाद कई संग्रह जरूरी नहीं लगते हैं क्योंकि मैं नामस्थान सीमाओं से परहेज करते हुए एक संग्रह में जो कुछ भी कर सकता हूं वह कर सकता हूं। – Steven

संबंधित मुद्दे