हमारे आवेदन को एक डीबी में 5 संग्रह की जरूरत है। जब हम क्लाइंट टूर एप्लिकेशन जोड़ते हैं तो हम प्रत्येक ग्राहक के लिए अलग डीबी बनाए रखना चाहते हैं। उदाहरण के लिए, यदि हमारे पास 500 ग्राहक हैं, तो हमारे पास 500 डीबीएस और 2500 संग्रह होंगे (प्रत्येक डीबी में 5 संग्रह हैं)। इस तरह हम प्रत्येक ग्राहक डेटा को अलग कर सकते हैं।
बढ़िया विचार है। तार्किक पृथक्करण के शीर्ष पर यह आपके लिए प्रदान करेगा, आप अन्य ग्राहकों के डेटा तक अनजाने में पहुंच को रोकने में मदद करने के लिए MongoDB में डेटाबेस स्तर की सुरक्षा का उपयोग करने में भी सक्षम होंगे।
<ब्लॉककोट>मेरी चिंता यह है कि क्या इससे प्रदर्शन संबंधी कोई समस्या होगी?
नहीं, और वास्तव में यह डेटाबेस स्तर लॉक के साथ एक ग्राहक के लिए अत्यधिक भारी लॉक विवाद (यदि यह आपके परिदृश्य में संभव है) के साथ मदद करेगा किसी अन्य ग्राहक के प्रदर्शन को प्रभावित नहीं करेगा (यह तब भी हो सकता है जब वे समान I/O बैंडविड्थ के लिए प्रतिस्पर्धा कर रहे हों लेकिन अगर आप --directoryperdb विकल्प का उपयोग करते हैं तो आपके पास उन डीबी को अलग-अलग भौतिक उपकरणों पर रखने की क्षमता है।
साझाकरण भी आसान स्केलिंग की अनुमति देगा क्योंकि आपको किसी भी संग्रह को विभाजित करने की भी आवश्यकता नहीं होगी - आप लोड को अलग-अलग समूहों में वितरित करने की अनुमति देने के लिए कई शार्क में डेटाबेस को राउंड-रॉबिन कर सकते हैं (यदि आप उस स्तर तक पहुंचते हैं तो)।
दूसरे उत्तर में दावे के विपरीत, TTLMonitor थ्रेड तब तक दस्तावेज़ों को RAM में नहीं खींचता जब तक कि उन्हें हटाया नहीं जाता (और मुफ़्त सूची में जोड़ा जाता है)। वे यह बताने के लिए कि क्या किसी दस्तावेज़ की समय सीमा समाप्त होनी है और साथ ही दस्तावेज़ का सीधे पता लगाने के लिए TTL अनुक्रमणिका से अलग काम करते हैं।
मैं एक डेटाबेस के खिलाफ कई संग्रह समाधान की दृढ़ता से अनुशंसा करता हूं क्योंकि यह आपको लोड को विभाजित करने की अनुमति नहीं देता है, न ही सुरक्षा प्रदान करता है, न ही आवेदन पक्ष पर इसे संभालना आसान है।
