कुछ रणनीतियाँ दिमाग में आती हैं:
1) 'हॉट' दस्तावेज़ों के लिए एक अलग संग्रह/डेटाबेस का उपयोग करें।
यदि आप जानते हैं कि हॉट सेट में कौन से दस्तावेज़ हैं, तो हाँ, उन्हें एक अलग संग्रह में ले जाने से मदद मिलेगी। यह सुनिश्चित करेगा कि हॉट दस्तावेज़ एक ही विस्तार/पृष्ठों पर सह-निवासी हैं। यह उन दस्तावेज़ों के लिए अनुक्रमणिका को पूरी तरह से स्मृति में होने की अधिक संभावना बना देगा। यह इसके छोटे होने और (पूरी तरह से?) अधिक बार उपयोग किए जाने के कारण है।
यदि हॉट दस्तावेज़ों को अन्य दस्तावेज़ों के साथ बेतरतीब ढंग से मिलाया जाता है, तो दस्तावेज़ लोड करते समय आपको बी-ट्री इंडेक्स के अधिक लीफ तत्वों में गलती करने की संभावना होगी क्योंकि हाल ही में लोड किए गए या इंडेक्स ब्लॉक तक पहुंचने वाले किसी अन्य दस्तावेज़ की संभावना कम है।
2) अनुक्रमित मानों . को छोटा करें .
सूचकांक जितना छोटा होगा, एक बी-ट्री ब्लॉक में फिट होने वाले उतने ही अधिक मूल्य होंगे। (नोट:कुंजियाँ अनुक्रमणिका में शामिल नहीं हैं।) एक बकेट में अधिक प्रविष्टियाँ का अर्थ है कम बकेट और अनुक्रमणिका के लिए आवश्यक कम कुल मेमोरी। यह उच्च संभावना/लंबे जीवनकाल में अनुवाद करता है कि ब्लॉक स्मृति में रहेगा। आपके उदाहरण में 20->8 कैरेक्टर की कमी 50% बचत से बेहतर है। यदि आप उन 8 बाइट्स को लंबे समय में परिवर्तित कर सकते हैं तो थोड़ी अधिक बचत होती है क्योंकि लंबे समय तक लंबाई उपसर्ग (4 बाइट्स) और पिछली नल (कुल 5 बाइट्स) नहीं होती है।
3) प्रमुख नामों को छोटा करें।
फ़ील्ड नाम जितना छोटा होगा, प्रत्येक दस्तावेज़ में उतनी ही कम जगह होगी। यह घटती पठनीयता का दुर्भाग्यपूर्ण दुष्प्रभाव है।
4) शार्प
मेमोरी और अंतिम डिस्क बैंडविड्थ को समाप्त करने वाले पूरे कॉर्पस में पढ़ने के सामने प्रदर्शन को बनाए रखने का यह वास्तव में एकमात्र तरीका है। अगर आप शार्प करते हैं तो भी आप 'हॉट' कलेक्शन को शार्प करना चाहेंगे।
5) डिस्क पर रीड-अहेड को एक छोटे से मान पर एडजस्ट करें।
चूंकि 'नॉन-हॉट' रीड डिस्क से एक यादृच्छिक दस्तावेज़ लोड कर रहे हैं, हम वास्तव में केवल उस दस्तावेज़ और उसके आस-पास के कुछ दस्तावेज़ों को स्मृति में पढ़ना/गलती करना चाहते हैं। एक बार जब कोई उपयोगकर्ता किसी फ़ाइल के एक हिस्से से पढ़ता है, तो अधिकांश सिस्टम डेटा के एक बड़े ब्लॉक को पढ़ने और पढ़ने की कोशिश करेंगे। यह हम जो चाहते हैं उसके ठीक विपरीत है।
यदि आप देखते हैं कि आपका सिस्टम बहुत अधिक दोषपूर्ण है, लेकिन मोंगोड प्रक्रिया के लिए निवासी मेमोरी सिस्टम उपलब्ध मेमोरी तक नहीं पहुंचती है, तो आप ओएस के बेकार डेटा को पढ़ने के प्रभाव को देख सकते हैं।
6) चाबियों के लिए नीरस रूप से बढ़ते मूल्यों का उपयोग करने का प्रयास करें।
यह एक अनुकूलन को ट्रिगर करेगा (ऑब्जेक्ट आईडी आधारित इंडेक्स के लिए) कि जब इंडेक्स ब्लॉक विभाजित होता है तो यह 50/50 के बजाय 90/10 पर ऐसा करेगा। परिणाम यह है कि आपके सूचकांक में अधिकांश ब्लॉक क्षमता के करीब होंगे और आपको उनमें से कम की आवश्यकता होगी।
यदि आप इस तथ्य के बाद केवल 'हॉट' 50,000 दस्तावेज़ों को जानते हैं तो उन्हें अनुक्रमणिका क्रम में अलग संग्रह में जोड़ने से यह अनुकूलन भी शुरू हो जाएगा।
रोब।
