यह कहना मुश्किल है कि इष्टतम बल्क इंसर्ट क्या है - यह आंशिक रूप से आपके द्वारा सम्मिलित की जा रही वस्तुओं के आकार और अन्य अथाह कारकों पर निर्भर करता है। आप कुछ श्रेणियों की कोशिश कर सकते हैं और देख सकते हैं कि आपको सबसे अच्छा प्रदर्शन क्या देता है। एक विकल्प के रूप में, कुछ लोग mongoimport का उपयोग करना पसंद करते हैं, जो बहुत तेज़ है, लेकिन आपके आयात डेटा को json या csv होना चाहिए। यदि डेटा बीएसओएन प्रारूप में है, तो स्पष्ट रूप से मोंगोड्रेस्टोर है।
Mongo आसानी से अरबों दस्तावेज़ों को संभाल सकता है और एक संग्रह में अरबों दस्तावेज़ रख सकता है लेकिन याद रखें कि दस्तावेज़ का अधिकतम आकार 16mb है . MongoDB में अरबों दस्तावेज़ों वाले कई लोग हैं और MongoDB Google उपयोगकर्ता समूह . यह रहा एक दस्तावेज़ बड़ी संख्या में संग्रहों का उपयोग करने पर जिन्हें आप पढ़ना पसंद कर सकते हैं, यदि आप अपना विचार बदलते हैं और इसके बजाय एकाधिक संग्रह रखना चाहते हैं। आपके पास जितने अधिक संग्रह होंगे, आपके पास उतनी ही अधिक अनुक्रमणिकाएँ होंगी, जो शायद वह नहीं है जो आप चाहते हैं।
यह रही प्रस्तुति MongoDB में अरबों दस्तावेज़ डालने पर क्रेगलिस्ट से और लड़के के ब्लॉगपोस्ट ।
ऐसा लगता है कि शार्किंग आपके लिए एक अच्छा समाधान होगा, लेकिन आम तौर पर कई सर्वरों में स्केलिंग के लिए शार्डिंग का उपयोग किया जाता है और बहुत से लोग ऐसा करते हैं क्योंकि वे अपने लेखन को स्केल करना चाहते हैं या वे अपने कामकाजी सेट (डेटा और इंडेक्स) को रखने में असमर्थ हैं। रैम में। जैसे-जैसे आपका डेटा बढ़ता है या आपको अतिरिक्त अतिरेक और लचीलापन की आवश्यकता होती है, वैसे-वैसे एक सर्वर से शुरू करना और फिर एक शार्प या रेप्लिका-सेट पर जाना पूरी तरह से उचित है।
हालांकि, ऐसे अन्य उपयोगकर्ता हैं जो बहुत सारे लिखने के साथ एक ही मोंगोड की लॉकिंग सीमा प्राप्त करने के लिए एकाधिक मोंगोड का उपयोग करते हैं। यह स्पष्ट है लेकिन फिर भी कहने लायक है लेकिन एक सर्वर से प्रबंधित करने के लिए एक बहु-मोंगड सेटअप अधिक जटिल है। यदि आपका आईओ या सीपीयू यहां अधिकतम नहीं है, तो आपका कार्य सेट रैम से छोटा है और आपका डेटा संतुलित रखना आसान है (बहुत बेतरतीब ढंग से वितरित), आपको सुधार देखना चाहिए (एक सर्वर पर शार्डिंग के साथ)। FYI करें के रूप में, मेमोरी और IO विवाद की संभावना है। 2.2 में सुधार के साथ concurrency db के साथ लॉक करना , मुझे संदेह है कि इस तरह के परिनियोजन के लिए बहुत कम कारण होंगे।
आपको सही तरीके से शार्प करने के लिए अपने कदम की योजना बनाने की आवश्यकता है, अर्थात अपनी शार्प की को चुनने के बारे में सावधानी से सोचें। यदि आप इस तरह से जाते हैं तो पूर्व-विभाजन और बैलेंसर को बंद करना सबसे अच्छा है। चीजों को संतुलित रखने के लिए डेटा को इधर-उधर करना प्रति-उत्पादक होगा, जिसका अर्थ है कि आपको यह तय करना होगा कि इसे कैसे विभाजित किया जाए। इसके अतिरिक्त, कभी-कभी अपने दस्तावेज़ों को इस विचार के साथ डिज़ाइन करना महत्वपूर्ण होता है कि कुछ फ़ील्ड शार्डिंग के लिए या प्राथमिक कुंजी के रूप में उपयोगी होंगे।
यहां कुछ अच्छे लिंक दिए गए हैं -
- एक शार्ड कुंजी चुनना
- शार्द कुंजियों पर ब्लॉग पोस्ट
- शार्डिंग पर अवलोकन प्रस्तुति
- साझा करने की सर्वोत्तम प्रक्रियाओं पर प्रस्तुति
