ल्यूसीन में वृद्धिशील सूचकांक के बाद एक सूचकांक अनुकूलित किया जाना चाहिए?

Question

हम अपने ल्यूसीन इंडेक्स और प्रत्येक 2 घंटे या उससे भी अधिक की वृद्धिशील इंडेक्स पर हर 7 दिनों (यानी स्क्रैच से इंडेक्स बनाना) पूर्ण पुन: इंडेक्स चलाते हैं। हमारे सूचकांक में लगभग 700,000 दस्तावेज हैं और एक पूर्ण अनुक्रमणिका लगभग 17 घंटे लगती है (जो कोई समस्या नहीं है)।

जब हम वृद्धिशील इंडेक्स करते हैं, तो हम केवल पिछले दो घंटों में परिवर्तित सामग्री की अनुक्रमणिका करते हैं, इसलिए इसमें बहुत कम समय लगता है - लगभग आधे घंटे। हालांकि, हमने देखा है कि इस समय बहुत सारे (शायद 10 मिनट) इंडेक्सवाइटर.ऑप्टिमाइज़() विधि को चलाने में व्यतीत किया जाता है।

LuceneFAQ कहा गया है कि:

IndexWriter वर्ग एक का अनुकूलन() विधि है कि सूचकांक डेटाबेस काम्पैक्ट और प्रश्नों को गति का समर्थन करता है। आप अपने दस्तावेज़ सेट की पूरी अनुक्रमणिका या इंडेक्स के बढ़ते अपडेट के बाद इस विधि का उपयोग करना चाह सकते हैं। यदि आपका वृद्धिशील अद्यतन दस्तावेज़ों को अक्सर जोड़ता है, तो आप ऑप्टिमाइज़ेशन के अतिरिक्त ओवरहेड से बचने के लिए केवल थोड़ी देर में ऑप्टिमाइज़ेशन करना चाहते हैं।

... लेकिन ऐसा लगता है कि "अक्सर" का अर्थ क्या है। अनुकूलन सीपीयू गहन और बहुत आईओ-गहन है, इसलिए अगर हम इससे दूर हो सकते हैं तो हम इसे नहीं कर पाएंगे। एक गैर-अनुकूलित इंडेक्स पर चल रहे प्रश्नों की हिट कितनी है (मैं विशेष रूप से 20 वृद्धिशील इंडेक्स के बाद पूर्ण पुन: इंडेक्स के बाद क्वेरी प्रदर्शन के संदर्भ में सोच रहा हूं, कहता है, 50,000 दस्तावेज़ बदल गए हैं)? क्या हमें हर वृद्धिशील इंडेक्स के बाद अनुकूलित करना चाहिए या प्रदर्शन हिट इसके लायक नहीं है?

Answer 1

चटाई, जब से तुम एक अच्छा विचार कब तक अपने वर्तमान प्रक्रिया लेता है लगता है, मेरा सुझाव है कि आप optimize() हटाने और प्रभाव को मापने।

क्या 2 घंटे विंडोज़ में कई दस्तावेज़ बदलते हैं? यदि केवल एक छोटा सा अंश (50,000/700,000 लगभग 7% है) क्रमशः पुन: अनुक्रमित होते हैं, तो मुझे नहीं लगता कि आपको optimize() से अधिक मूल्य मिल रहा है।

कुछ विचार:

• बिल्कुल एक वृद्धिशील optimize() मत करो। मेरा अनुभव कहता है कि आप किसी भी तरह से एक बड़ा प्रश्न सुधार नहीं देख रहे हैं।
• 2-घंटे के बजाय optimize() दैनिक करें।
• कम मात्रा वाले समय के दौरान optimize() करें (जो javadoc कहता है)।

और सुनिश्चित करें कि आप माप लें। इन प्रकार के परिवर्तन उनके बिना अंधेरे में एक शॉट हो सकते हैं।

Answer 2

एक optimize ऑपरेशन पूरे सूचकांक को पढ़ता है और लिखता है, यही कारण है कि यह आईओ गहन है!

ऑप्टिमाइज़ ऑपरेशंस के पीछे विचार ल्यूसीन इंडेक्स में सभी एकल सेगमेंट को एक एकल सेगमेंट में दोबारा जोड़ना है, जो क्वेरी समय को बहुत कम कर सकता है क्योंकि आपको प्रति क्वेरी कई फाइलें खोलने और खोजने की ज़रूरत नहीं है। यदि आप सामान्य ल्यूसीन इंडेक्स फ़ाइल संरचना (संयुक्त संरचना के बजाए) का उपयोग कर रहे हैं, तो आपको प्रति प्रतिबद्ध ऑपरेशन के लिए एक नया सेगमेंट मिलता है; मुझे लगता है कि आपके पुन: इंडेक्स के समान ही?

मुझे लगता है कि Matt की बहुत अच्छी सलाह है और मैं जो कुछ कहता हूं वह दूसरा होगा - आपके पास मौजूद डेटा से प्रेरित हो।जब आप कम क्वेरी वॉल्यूम रखते हैं तो मैं वास्तव में एक कदम आगे जाता हूं और केवल ऑप्टमाइज़ करता हूं) जब आपको आवश्यकता होती है।

चूंकि क्वेरी प्रदर्शन आपके सूचकांक में सेगमेंट की संख्या से गहराई से जुड़ा हुआ है, इसलिए एक सरल ls -1 index/segments_* | count अनुकूलन की आवश्यकता होने पर एक उपयोगी संकेतक हो सकता है।

वैकल्पिक रूप से, क्वेरी प्रदर्शन और वॉल्यूम को ट्रैक करना और स्वीकार्य रूप से कम मात्रा के साथ अस्वीकार्य कम प्रदर्शन तक पहुंचने पर ऑप्टिमाइज़ करना बंद करना एक अच्छा समाधान होगा।

Answer 3

this mail में, ओटिस Gospodnetic का अनुकूलन का उपयोग कर, यदि आपका सूचकांक लगातार अपडेट देख रही है के खिलाफ सलाह। यह 2007 से है, लेकिन optimize() पर कॉल करना आईओ-भारी ऑपरेशन में बहुत ही प्रकृति है। आप एक और कदमपूर्ण दृष्टिकोण का उपयोग करने पर विचार कर सकते हैं; MergeScheduler