2013-06-04 9 views
23

हमारे आवेदन को एक डीबी में 5 संग्रह की आवश्यकता है। जब हम अपने आवेदन में ग्राहकों को जोड़ते हैं तो हम प्रत्येक ग्राहक के लिए अलग डीबी बनाए रखना चाहते हैं। उदाहरण के लिए, यदि हमारे पास 500 ग्राहक हैं, तो हमारे पास 500 डीबीएस और 2500 संग्रह होंगे (प्रत्येक डीबी में 5 संग्रह होंगे)। इस तरह हम प्रत्येक ग्राहक डेटा को अलग कर सकते हैं। मेरी चिंता है, क्या यह किसी भी प्रदर्शन की समस्या का कारण बन जाएगा?मोंगोडीबी प्रदर्शन - एकाधिक डेटाबेस

अद्यतन: इसके अलावा इस google-group discussion का पालन करें।

+0

ग्राहकों की एक बड़ी संख्या में आप इसके बजाय अलंकित उदाहरणों की तलाश करना बेहतर हो सकते हैं, लेकिन यह आपके द्वारा दिए गए – Sammaye

+2

से अधिक पर निर्भर करता है, जो कि shards के लिए हैं - वे प्रत्येक एक अलग mongod उदाहरण/प्रतिकृति सेट हैं। यह मोंगोडीबी के बहुत से उपयोगकर्ताओं के लिए बेहद आम कॉन्फ़िगरेशन है जो कई किरायेदारों और अलग-अलग डीबी होस्ट कर रहे हैं, यहां एक मानक उत्तर है। –

उत्तर

30

हमारे आवेदन को एक डीबी में 5 संग्रह की आवश्यकता है। जब हम ग्राहकों को पर हमारे एप्लिकेशन में जोड़ते हैं तो हम प्रत्येक ग्राहक के लिए अलग-अलग डीबी बनाए रखना चाहते हैं। उदाहरण के लिए, यदि हमारे पास 500 ग्राहक हैं, तो हमारे पास 500 डीबीएस और 2500 संग्रह होंगे (प्रत्येक डीबी में 5 संग्रह होंगे)। इस तरह हम प्रत्येक ग्राहक डेटा को अलग कर सकते हैं।

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

मेरी चिंता है, क्या यह किसी भी प्रदर्शन की समस्या का कारण बन जाएगा?

नहीं है, और वास्तव में यह एक ग्राहक के लिए डेटाबेस के स्तर का ताला अत्यंत भारी ताला विवाद के साथ के रूप में मदद मिलेगी (यदि है कि आपके परिदृश्य में संभव है) एक और ग्राहक के लिए प्रदर्शन को प्रभावित नहीं होगा (यह अभी भी हो सकता है अगर वे के लिए प्रतिस्पर्धा कर रहे हैं एक ही I/O बैंडविड्थ लेकिन यदि आप --directoryperdb विकल्प का उपयोग करते हैं तो आपके पास उन डीबी को अलग-अलग भौतिक उपकरणों पर रखने की क्षमता है।

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

दूसरे उत्तर में दावे के विपरीत, टीटीएल मॉनिटर थ्रेड दस्तावेजों को तब तक खींच नहीं लेता जब तक उन्हें हटाया नहीं जा रहा (और मुफ्त सूची में जोड़ा गया)। वे टीटीएल इंडेक्स दोनों से यह बताने के लिए काम करते हैं कि क्या दस्तावेजों की अवधि समाप्त होनी है और साथ ही दस्तावेज़ को सीधे ढूंढना है।

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

+0

+1 आपने शायद मुझसे अधिक अनुभव लोड किया है, हालांकि मुझे अभी भी लगता है कि उचित उत्तर स्थिति के बारे में अधिक जानकारी मांगता है। –

+0

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

+0

मुझे लगता है कि यह ओपी के परिदृश्य में समझ में आता है, जो मुझे लगता है कि कुछ उपयोगकर्ता हैं लेकिन प्रति उपयोगकर्ता अपेक्षाकृत उच्च दस्तावेज गिनती है, लेकिन अगर ओपी को कुछ हज़ार ग्राहकों के पीछे स्केल करना था (तो 1 मिलियन कहें) क्या यह अभी भी एक अच्छा दृष्टिकोण होगा? – nick

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