MongoDB में जब आप एक शार्प सिस्टम में जाते हैं और आपको कोई संतुलन नहीं दिखता है तो यह कई चीजों में से एक हो सकता है।
-
संतुलन को ट्रिगर करने के लिए आपके पास पर्याप्त डेटा नहीं हो सकता है। यह निश्चित रूप से आपकी स्थिति नहीं थी, लेकिन कुछ लोगों को यह एहसास नहीं हो सकता है कि 64 एमबी के डिफॉल्ट चंक साइज के साथ डेटा डालने में कुछ समय लग सकता है, इससे पहले कि इसमें से कुछ को अन्य हिस्सों में विभाजित करने और संतुलित करने के लिए पर्याप्त हो।
-
हो सकता है कि बैलेंसर नहीं चल रहा हो - चूंकि आपके अन्य संग्रह संतुलित हो रहे थे जो आपके मामले में संभव नहीं था जब तक कि किसी कारण से बैलेंसर को रोक दिए जाने के बाद इस संग्रह को अंतिम रूप से शार्प नहीं किया गया था।
-
आपके संग्रह के हिस्सों को स्थानांतरित नहीं किया जा सकता है। यह तब हो सकता है जब शार्प की डेटा को छोटे-छोटे टुकड़ों में विभाजित करने के लिए पर्याप्त दानेदार न हो। जैसा कि यह पता चला है कि यह आपका मामला था क्योंकि आपकी शार्ड कुंजी इस बड़े संग्रह के लिए पर्याप्त दानेदार नहीं थी - आपके पास 105 भाग हैं (जो शायद अद्वितीय जॉब_आईडी मानों की संख्या से मेल खाते हैं) और 30 जीबी से अधिक डेटा। जब टुकड़े बहुत बड़े होते हैं और बैलेंसर उन्हें स्थानांतरित नहीं कर सकता है तो यह उन्हें "जंबो" के रूप में टैग करता है (इसलिए यह अपने पहियों को स्थानांतरित करने की कोशिश नहीं करेगा)।
शार्ड की के खराब विकल्प से कैसे उबरें? आम तौर पर शार्ड कुंजी को बदलना बहुत दर्दनाक होता है - चूंकि शार्ड कुंजी अपरिवर्तनीय है, इसलिए आपको इसे किसी अन्य शार्प कुंजी के साथ संग्रह में लाने के लिए पूर्ण डेटा माइग्रेशन के बराबर करना होगा। हालांकि, आपके मामले में संग्रह अभी भी एक शार्प पर है, इसलिए संग्रह को "अनशर्ड" करना अपेक्षाकृत आसान होना चाहिए और इसे एक नई शार्ड कुंजी के साथ पुनः साझा करना चाहिए। क्योंकि job_ids की संख्या अपेक्षाकृत कम है, मैं आपको job_id,customer_code पर शार्प करने के लिए एक नियमित इंडेक्स का उपयोग करने की सलाह दूंगा क्योंकि आप शायद उस पर क्वेरी करते हैं और मुझे लगता है कि यह हमेशा दस्तावेज़ निर्माण समय पर सेट होता है।
