इस विषय पर बहुत सारे विचार। हालांकि मेरी प्रतिक्रिया किसी भी तरह से एह कैश का लाभ नहीं उठाती है।
सबसे पहले, मुझे विश्वास नहीं है कि दस्तावेजों को आपकी खोज अनुक्रमणिका में संग्रहीत किया जाना चाहिए। खोज सामग्री को पूरे दस्तावेज़ में नहीं रखा जाना चाहिए। इसका मतलब यह है कि, आपकी खोज क्वेरी से क्या लौटाया गया है दस्तावेज़ आईडी होना चाहिए। दस्तावेजों की सामग्री खुद नहीं है। दस्तावेज़ों को स्वयं को दूसरी प्रणाली से संग्रहीत और पुनर्प्राप्त किया जाना चाहिए, शायद मूल फ़ाइल स्टोर जिसे वे शुरू करने के लिए अनुक्रमित कर रहे हैं। इससे इंडेक्स आकार कम हो जाएगा, आपके दस्तावेज़ कैश आकार में कमी आएगी, मास्टर गुलाम प्रतिकृति समय कम हो जाएगा (यदि आप अक्सर अपडेट करते हैं तो यह एक बाधा बन सकता है), और खोज प्रतिक्रियाओं में ओवरहेड कम करें।
अगला, सौर के सामने एक रिवर्स HTTP प्रॉक्सी डालने पर विचार करें। हालांकि क्वेरी कैश सोलर को तुरंत प्रतिक्रिया देने की इजाजत देता है, लेकिन सौर के सामने बैठे वार्निश जैसे कैश भी तेज हैं। यह सोलर को अनलोड करता है, जिससे वह उन प्रश्नों का जवाब देने में समय बिताने की अनुमति देता है जो पहले नहीं देखे गए हैं। दूसरा प्रभाव यह है कि अब आप क्वेरी कैश के बजाय दस्तावेज़ कैश पर अपनी अधिकांश मेमोरी फेंक सकते हैं। यदि आपने मेरे पहले सुझाव का पालन किया है तो आपके दस्तावेज़ अविश्वसनीय रूप से छोटे होंगे, जिससे आप अधिकतर रखने की इजाजत दे सकते हैं, अगर उनमें से सभी स्मृति में नहीं हैं।
दस्तावेज़ आकारों के लिए लिफाफा गणना का एक त्वरित पीछे। मैं आसानी से 150 मिलियन दस्तावेजों के लिए एक आईडी के रूप में 32 बिट int प्रदान कर सकता हूं। दस्तावेज़ विकास के लिए मेरे पास अभी भी 10x हेडरूम है। 150 मिलियन आईडी 600 एमबी लेता है। सोलर रैपिंग दस्तावेज़ों के लिए एक झुकाव कारक में जोड़ें, और आप संभवतः 1-2 जीबी में अपने सभी सौर दस्तावेज़ों को कैश कर सकते हैं। 12 जीबी-24 जीबी या रैम प्राप्त करने पर विचार करना आजकल आसान है, और मैं कहूंगा कि आप इसे 1 बॉक्स पर कर सकते हैं और अविश्वसनीय प्रदर्शन प्राप्त कर सकते हैं। EhCache की तरह कुछ भी अपर्याप्त की आवश्यकता नहीं है। बस यह सुनिश्चित करना होगा कि आप अपनी खोज अनुक्रमणिका का यथासंभव कुशलतापूर्वक उपयोग करें।
जीसी के संबंध में: मुझे अपने सोलर सर्वर पर बहुत से जीसी समय व्यतीत नहीं हुए। जो कुछ भी एकत्रित करने की आवश्यकता है वह बहुत ही कम जीवित वस्तुएं थी जिसमें HTTP अनुरोध और प्रतिक्रिया चक्र शामिल था, जो कभी भी ईडन स्पेस से बाहर नहीं निकलता था। सही ढंग से ट्यून किए जाने पर कैशों का उच्च कारोबार नहीं हुआ था। एकमात्र बड़े बदलाव तब थे जब एक नई अनुक्रमणिका लोड की गई थी और कैश फ्लेश किए गए थे, लेकिन यह लगातार नहीं हो रहा था।
संपादित करें: पृष्ठभूमि के लिए, मैंने कंसोल बेचने वाली बड़ी कंपनी के लिए सोलर कैशिंग ट्यूनिंग करने में काफी समय बिताया और प्रति दिन लाखों खोजों को उनके सौर सर्वर से सेवा प्रदान करता है।
चूंकि हमने वास्तव में कुछ भी नहीं बनाया है, इसलिए हम निश्चित रूप से इस विकल्प पर विचार करेंगे।हालांकि, इसमें डेटाबेस इंस्टेंस खड़ा होना शामिल होगा। धन्यवाद। – nvalada
जो मैंने रेखांकित किया है, उसके लिए यह नहीं है। आप अपनी आईडी के रूप में एक यूआरएल या फ़ाइल पथ का उपयोग कर सकते हैं। यह और अधिक जगह लेता है, लेकिन अभी भी उचित हो सकता है। – rfeak
@rfeak: मेरी कंपनी में हम न केवल अपने खोज उद्देश्यों के लिए सोलर का उपयोग करते हैं, बल्कि इसके टेक्स्ट हाइलाइटिंग के लिए भी उपयोग करते हैं। मुझे लगता है कि सूचकांक से दस्तावेजों को अलग करने की विधि इस क्षमता को हटा देगी। यदि आपके पास समय है, तो क्या आप समझा सकते हैं कि आप बड़ी इंडेक्स समस्याओं को हल करने के बारे में कैसे जाएंगे, लेकिन किसी भी तरह से सोलर की टेस्ट हाइलाइटिंग क्षमताओं का लाभ उठा रहे हैं? – iralls