विकल्प?

Question

मुझे विंडोज क्लस्टर्स में चलने वाले एप्लिकेशन के लिए Lucene.NET चलाने में रूचि है। खोज समस्या स्वयं ही काफी छोटी है, लेकिन स्टेटलेस/क्लस्टर समस्या को अभी भी संभालना है।

मैं समझता हूं कि एसओएलआर मेरे परिदृश्य (और अधिक) को संभालता है लेकिन एक सर्वलेट कंटेनर (और जावा) की आवश्यकता होती है जो मेरे लिए कुछ समस्याएं उत्पन्न करती है। Lucene.NET आधारित दृष्टिकोण की जटिलता के आधार पर यह अभी भी एक शीश विकल्प हो सकता है। सभी नोड्स के लिए

• एक साझा भंडारण पर जारी रहती है तो आम:

  मेरा प्रश्न अब क्या विकल्प एकाधिक मेजबान पर चल रहा है की समस्या से निपटने के लिए मेरे पास है? Lucene.NET संगतता पारदर्शी रूप से संभाल लेंगे? क्या सर्वर कैशिंग के लिए रैम का उपयोग करेंगे, और यदि ऐसा है तो Lucene.NET को अद्यतन फ़ाइलों पर आधारित पारदर्शी रूप से अमान्यता है?

• प्रतिकृति? प्रत्येक सर्वर की अपनी हर चीज की अपनी प्रतिलिपि होती है। किसी भी अद्यतन पर, सभी सर्वरों को एक नई प्रतिकृति मिलती है (या अगर यह उचित रूप से सरल है तो diff)। इसके लिए मौजूदा उपकरण, या मेरे लिए संभाल करने के लिए?

• वर्कलोड विभाजन/शेरिंग? प्रत्येक सर्वर केवल पढ़ने और अपडेट दोनों के लिए अपने डेटा को संभालता है। इसे संभालने के लिए उपकरण, आंशिक परिणाम आदि में शामिल हो?

• अन्य विकल्प मेरी प्रारंभिक जांच में मुझे याद आ सकता है?

स्थानीय संस्करण के साथ प्रयोग करते समय, मेरी ल्यूसीन निर्देशिका कुछ सौ मेग्स के क्रम में थी। लंबे समय तक मैं शायद 1-5 जीबी देख सकता हूं। यदि अपडेट की आवृत्ति एक कठिनाई है तो मैं इसे काफी लचीला रूप से नियंत्रित कर सकता हूं। समवर्ती पढ़ने/खोज भार बहुत ही मध्यम होने की उम्मीद है।

Answer 1

आप एकाधिक सर्वरों के साथ lucene.net का उपयोग कर सकते हैं लेकिन आपको एक अनुक्रमण सर्वर को लागू करना होगा।

आपके द्वारा किए गए सभी परिवर्तनों को कतारबद्ध किया जाना चाहिए और हर बार लंबित दस्तावेज़ों को अनुक्रमित करना चाहिए। यदि आपको कतार में एक्स आइटम हैं तो भी आपको तुरंत इंडेक्स करना चाहिए (एक्स आपके विलय दस्तावेज़ों पर निर्भर करता है जो यह मेरे लिए 25,000 था)।

उपर्युक्त के पीछे तर्क आपको इंडेक्स में छोटे बदलाव करने से बचने की आवश्यकता है क्योंकि यह कई छोटी फाइलों के कारण प्रदर्शन ओवरटाइम को कम कर देगा। यूओ 2 इंडेक्सिंग सर्वर चला सकता है लेकिन इंडेक्स पर लॉक करने के कारण केवल 1 ही इंडेक्स होगा, ऐसा करने का एकमात्र कारण यह है कि अगर पहले नीचे चला जाता है तो असफल होने के लिए, आपकी ज़रूरतों पर निर्भर करता है।

मैंने 30 मिलियन रिकॉर्ड के साथ 15 जीबी की अनुक्रमणिका का उपयोग किया है। इसके साथ मेरा परिदृश्य अजीब था। 20 वेब सामग्री प्रत्येक सूचकांक पकड़े की सेवा भूमिकाओं - सूचकांक को

• 1 कार्यकर्ता भूमिका

• 2 बदल जाता है।

प्रत्येक 15 मिनट में परिवर्तनों को धक्का दिया गया था और सूचकांक 25,000 परिवर्तनों और 250,000 दस्तावेजों वाले प्रत्येक संयुक्त सूचकांक में विलय कर दिया गया था। प्रत्येक वेब सर्वर ने प्रत्येक 15 मिनट में परिवर्तन के लिए ब्लॉब स्टोरेज की जांच की और इंडेक्स रीडर को लॉक कर दिया, जो परिवर्तनों को डाउनलोड किए जाने पर अमान्य कर दिया गया था। प्रति फ़ाइल आपके अधिकतम दस्तावेज़ मूल रूप से पिछले कई परिवर्तनों को डाउनलोड करने वाले वेब सर्वर को रोकने के लिए हैं।

मैंने ल्यूसीन.एज़ूर डायरेक्टरी का उपयोग शुरू करने के लिए किया था, लेकिन यह ब्लॉब स्टोरेज में बदले हुए ब्लब्स का पता लगाने पर भरोसेमंद नहीं था, इसलिए मैंने ब्लॉब्स को फिर से चालू कर दिया और स्थानीय रूप से तुलना की और आवश्यकतानुसार डाउनलोड किया।

अब मैं इस तरह कुछ फिर से लागू करूंगा? जवाब एक बड़ा नंबर है। जब आप पहिया को फिर से शुरू कर रहे हैं तो मैं लोचदार खोज या हलर का उपयोग करूंगा।