ऐसे कई कारक हैं जो निर्यात प्रदर्शन को सीमित कर रहे हैं।
- उपलब्ध मेमोरी की तुलना में डेटा का आकार अपेक्षाकृत बड़ा है:~2 टीबी बनाम ~ 5 जीबी वायर्डटाइगर कैश (यदि डिफ़ॉल्ट पर सेट है)। वह है:
- संपूर्ण WiredTiger कैश में केवल सर्वोत्तम हो सकता है संग्रह का ~0.22%, वास्तव में यह इससे बहुत कम होने की संभावना है क्योंकि कैश में अन्य संग्रह और अनुक्रमणिका से डेटा होगा।
- इसका मतलब है कि कैश की वर्तमान सामग्री को हटाते समय WiredTiger को डिस्क से बहुत बार लाने की आवश्यकता होती है। यदि प्रतिकृति सेट का सक्रिय रूप से उपयोग किया जा रहा है, तो इसका अर्थ होगा "गंदे" डेटा को कैश से निकालना और उन्हें डिस्क पर बनाए रखना, जिसमें समय लगेगा।
- ध्यान दें कि WiredTiger कैश के अंदर दस्तावेज़ संपीड़ित नहीं होते हैं।
- संग्रह में बड़े दस्तावेज़ हैं, जिनमें से आपको इसके केवल एक भाग की आवश्यकता है। इसका मतलब है कि दस्तावेजों को संसाधित करने के लिए अतिरिक्त समय की आवश्यकता है।
- संग्रह को zlib के साथ संकुचित किया गया है, जिसका अर्थ है कि अतिरिक्त समय का उपयोग दस्तावेज़ों को असम्पीडित करने के लिए किया जाना चाहिए।
- पठन वरीयता
secondaryPreferredहै , जिसका अर्थ है कि यह एक माध्यमिक से पढ़ने की कोशिश करेगा। यदि प्रतिकृति सेट को सक्रिय रूप से लिखा जा रहा है, तो द्वितीयक पर oplog लागू संचालन पाठकों को अवरुद्ध कर देगा। इससे और देरी होगी।
एक संभावित सुधार यह है कि यदि यह एक ऐसा ऑपरेशन है जो आप अक्सर करते हैं, तो संबंधित क्षेत्रों पर एक इंडेक्स बनाना और इसे कवर की गई क्वेरी प्रदर्शन में सुधार कर सकता है क्योंकि अनुक्रमणिका पूर्ण दस्तावेज़ों से छोटी होगी।
संपादित करें:mongoexport चल रहा है समानांतर में इस मामले में मददगार हो सकता है:
प्रदान की गई अतिरिक्त जानकारी के अलावा, मैंने एक परीक्षण चलाया जो इस समस्या को कुछ हद तक कम करता प्रतीत होता है।
ऐसा लगता है कि mongoexport चल रहा है समानांतर में, जहां प्रत्येक mongoexport संग्रह का एक सबसेट संभालना निर्यात को गति देने में सक्षम हो सकता है।
ऐसा करने के लिए, _id . को विभाजित करें mongoexport . की संख्या के अनुरूप नाम स्थान प्रक्रिया जिसे आप चलाने की योजना बना रहे हैं।
उदाहरण के लिए, अगर मेरे पास 200,000 दस्तावेज़ हैं, जो _id:0 . से शुरू होते हैं से _id:199,999 और 2 mongoexport . का उपयोग कर रहे हैं प्रक्रियाएं:
mongoexport -q '{"_id":{"$gte":0, "$lt":100000}}' -d test -c test > out1.json &
mongoexport -q '{"_id":{"$gte":100000, "$lt":200000}}' -d test -c test > out2.json &
जहां उपरोक्त उदाहरण में, दो mongoexport प्रत्येक प्रक्रिया संग्रह के आधे हिस्से को संभालती है।
1 प्रक्रिया, 2 प्रक्रियाओं, 4 प्रक्रियाओं और 8 प्रक्रियाओं के साथ इस वर्कफ़्लो का परीक्षण मैं निम्नलिखित समय पर पहुँचता हूँ:
1 प्रक्रिया का उपयोग करना:
real 0m32.720s
user 0m33.900s
sys 0m0.540s
2 प्रक्रियाएं:
real 0m16.528s
user 0m17.068s
sys 0m0.300s
4 प्रक्रियाएं:
real 0m8.441s
user 0m8.644s
sys 0m0.140s
8 प्रक्रियाएं:
real 0m5.069s
user 0m4.520s
sys 0m0.364s
उपलब्ध संसाधनों के आधार पर, 8 mongoexport चल रहा है समानांतर में प्रक्रियाएं ~ 6 के कारक द्वारा प्रक्रिया को तेज करने लगती हैं। इसका परीक्षण 8 कोर वाली मशीन में किया गया था।
नोट :हाफर का उत्तर विचार में समान है, हालांकि यह उत्तर मूल रूप से यह देखने की कोशिश करता है कि mongoexport को कॉल करने में कोई लाभ है या नहीं समानांतर में।
