SOLR प्रदर्शन ट्यूनिंग

Question

मैं निम्नलिखित पढ़ा है:

1. अगर मैं का उपयोग करें:

   http://wiki.apache.org/solr/SolrPerformanceFactors

   http://wiki.apache.org/solr/SolrCaching

   http://www.lucidimagination.com/content/scaling-lucene-and-solr

   और मैं कुछ चीजों के बारे में प्रश्न पूछना चाहते हैं JVM विकल्प -XX:+UseCompressedStrings किस तरह का स्मृति बचत मैं प्राप्त कर सकता हूँ? एक साधारण उदाहरण रखने के लिए, यदि मेरे पास 1 अनुक्रमित फ़ील्ड (स्ट्रिंग) और 1 संग्रहीत फ़ील्ड (स्ट्रिंग) है omitNorms = true और omitTf = true के साथ, इंडेक्स और दस्तावेज़ कैश में किस प्रकार की बचत की उम्मीद है? मैं लगभग 50% अनुमान लगा रहा हूं, लेकिन शायद यह बहुत आशावादी है।

2. जब सोलर फ़िल्टर कैश वास्तव में होता है? अगर मैं सिर्फ एंड और कुछ ओआरएस के साथ एक सरल क्वेरी कर रहा हूं, और स्कोर द्वारा क्रमबद्ध कर रहा हूं, तो मुझे इसकी भी आवश्यकता है?
3. यदि मैं दस्तावेज़ कैश में सभी दस्तावेज़ों को कैश करना चाहता हूं, तो मैं आवश्यक स्थान की गणना कैसे करूं? ऊपर से उदाहरण का उपयोग करते हुए, यदि मेरे पास 20 एम दस्तावेज़ हैं, तो संपीड़ित तारों का उपयोग करें, और संग्रहीत फ़ील्ड की औसत लंबाई 25 वर्ण है, क्या मूल रूप से आवश्यक स्थान (25 बाइट्स + small_admin_overhead) * 20M है?
4. यदि सभी दस्तावेज़ दस्तावेज़ कैश में हैं, क्वेरी कैश कितना महत्वपूर्ण है?
5. यदि मैं दस्तावेज़ दस्तावेज़ में प्रत्येक दस्तावेज़ को स्वचालित करना चाहता हूं, तो *:* की क्वेरी को स्वतः चालू कर देगा?
6. स्केलिंग-लुसेन-एंड-सोलर आलेख कहता है कि FuzzyQuery धीमा है। अगर मैं solr की वर्तनी जांच सुविधा का उपयोग कर रहा हूं तो मैं मूल रूप से अस्पष्ट क्वेरी का उपयोग कर रहा हूं (क्योंकि वर्तनी जांच एक ही संपादन दूरी गणना करता है)? तो संभवतः वर्तनी जांच और अस्पष्ट क्वेरी दोनों समान रूप से "धीमी" हैं?
7. स्ट्रिंग के लिए ल्यूसीन फील्ड कैश का वर्णन करने वाला अनुभाग थोड़ा उलझन में है। क्या मैं इसे सही ढंग से पढ़ रहा हूं कि आवश्यक स्थान मूल रूप से अनुक्रमित स्ट्रिंग फ़ील्ड का आकार है + उस क्षेत्र में अद्वितीय शर्तों की संख्या के बराबर एक पूर्णांक arry?
8. अंत में, थ्रूपुट को अधिकतम करने के तहत, ओएस डिस्क कैश के लिए पर्याप्त जगह छोड़ने के बारे में एक बयान है। यह कहता है, "सब कुछ, बड़े पैमाने पर सूचकांक के लिए, यह सुनिश्चित करना सबसे अच्छा है कि आपके पास JVM को जो कुछ भी दे रहा है उससे कम से कम कुछ गीगाबाइट रैम हो।" तो अगर मेरे पास 12 जीबी मेमोरी मशीन है (उदाहरण के तौर पर), मुझे ओएस में कम से कम 2-3 जीबी देना चाहिए? क्या मैं डिस्क इंडेक्स आकार को देखकर ओएस द्वारा आवश्यक डिस्क कैश स्पेस का अनुमान लगा सकता हूं?

Answer 1

1. यह सुनिश्चित करने का एकमात्र तरीका यह है कि इसे आजमाएं। हालांकि, मुझे इंडेक्स में बहुत कम बचत की उम्मीद होगी, क्योंकि सूचकांक में प्रत्येक बार एक बार वास्तविक स्ट्रिंग होगी, शेष दस्तावेजों के भीतर उस स्ट्रिंग के स्थानों के लिए डेटा होगा। वे सूचकांक का एक बड़ा हिस्सा नहीं हैं।
2. फ़िल्टर कैश केवल फ़िल्टर क्वेरी कैश करता है। यह आपके सटीक उपयोग के मामले के लिए उपयोगी नहीं हो सकता है, लेकिन कई उन्हें उपयोगी पाते हैं। उदाहरण के लिए, देश, भाषा, उत्पाद प्रकार इत्यादि के परिणाम को संकुचित करना। यदि आप अक्सर उनका उपयोग करते हैं तो इस तरह की चीजों के लिए क्वेरी परिणाम पुन: गणना से बच सकते हैं।
3. वास्तव में, आपको बस इसे आजमाने और प्रोफाइलर के साथ मापना होगा। सटीक डेटा संरचना का गहराई से ज्ञान के बिना, कुछ भी शुद्ध SWAG है। आपकी गणना किसी और के प्रोफाइलिंग के बिना उतनी ही अच्छी है।
4. दस्तावेज़ कैश केवल गणना करने के बाद परिणामों को गठित करने में समय बचाता है क्वेरी की गणना के बाद। यदि आप अपना अधिकांश समय गणना करने वाले प्रश्नों का खर्च करते हैं, तो दस्तावेज़ कैश आपको थोड़ा अच्छा करेगा। क्वेरी कैश केवल पुनः उपयोग किए गए प्रश्नों के लिए उपयोगी है।यदि आपकी कोई भी प्रश्न दोहराई नहीं जाती है, तो क्वेरी कैश बेकार है
5. हां, मान लें कि आपका दस्तावेज़ कैश उन सभी को पकड़ने के लिए काफी बड़ा है।

6-8 सकारात्मक नहीं।

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

Answer 2

कैश

सामान्य तौर पर, कैशिंग प्रदर्शन में सुधार करने में एक अच्छा विचार की तरह लग रहा है, लेकिन यह भी मुद्दों का एक बहुत कुछ है:

• कैश की गई वस्तुओं की पुरानी पीढ़ी में जाने की संभावना है कचरा कलेक्टर, जो एकत्र करने के लिए अधिक महंगा है,
• सम्मिलन और निष्कासन प्रबंधन कुछ ओवरहेड जोड़ता है।

इसके अलावा, कैशिंग आपके खोज विलंबता को बेहतर बनाने की संभावना नहीं है जब तक कि आपके प्रश्नों में पैटर्न न हों। इसके विपरीत, यदि आपके ट्रैफ़िक का 20% कुछ प्रश्नों के कारण है, तो क्वेरी परिणाम कैश दिलचस्प हो सकता है। कैश को कॉन्फ़िगर करने के लिए आपको अपने प्रश्नों और दस्तावेज़ों को बहुत अच्छी तरह से जानना आवश्यक है। यदि आप नहीं करते हैं, तो आपको शायद कैशिंग अक्षम करना चाहिए।

यदि आप सभी कैश अक्षम करते हैं, तो भी प्रदर्शन ओएस I/O कैश के लिए बहुत अच्छा धन्यवाद हो सकता है। व्यावहारिक रूप से, इसका मतलब यह है कि यदि आप बार-बार फ़ाइल के एक ही हिस्से को पढ़ते हैं, तो संभवतः यह डिस्क से केवल पहली बार पढ़ा जाएगा, और फिर I/O कैश से। और सभी कैश को अक्षम करने से आप JVM को कम स्मृति दे सकते हैं, ताकि I/O कैश के लिए और अधिक स्मृति हो। अगर आपके सिस्टम में 12 जीबी मेमोरी है और यदि आप जेवीएम को 2 जीबी देते हैं, तो इसका मतलब है कि I/O कैश आपके इंडेक्स के 10 जी तक कैश करने में सक्षम हो सकता है (अन्य अनुप्रयोगों के आधार पर जो स्मृति की आवश्यकता होती है)।

मैं recommand आप यह पढ़ बनाम आई/ओ कैश अनुप्रयोग स्तर कैश के बारे में अधिक जानकारी पाने के लिए:

https://www.varnish-cache.org/trac/wiki/ArchitectNotes

http://antirez.com/post/what-is-wrong-with-2006-programming.html

फील्ड कैश

का आकार एक स्ट्रिंग के लिए फ़ील्ड कैश (लंबाई maxDoc के पूर्णांक की एक सरणी) + (सभी अद्वितीय स्ट्रिंग उदाहरणों के लिए एक सरणी) है। तो यदि आपके पास एक स्ट्रिंग फ़ील्ड वाला इंडेक्स है जिसमें औसतन आकार एस के एन उदाहरण हैं, और यदि आपके इंडेक्स में एम दस्तावेज़ हैं, तो इस फ़ील्ड के लिए फ़ील्ड कैश का आकार लगभग M * 4 + N * S होगा।

फील्ड कैश मुख्य रूप से पहलुओं और सॉर्टिंग के लिए उपयोग किया जाता है। यहां तक ​​कि बहुत कम स्ट्रिंग्स (10 से कम वर्ण) are more than 40 bytes, इसका मतलब है कि आपको सोलर को बहुत मेमोरी की आवश्यकता होने की उम्मीद करनी चाहिए यदि आप स्ट्रिंग फ़ील्ड को सॉर्ट या फ़ेसेट करते हैं जिसमें अद्वितीय संख्याएं हैं।

फजी क्वेरी

FuzzyQuery is slow in Lucene 3.x, but much faster in Lucene 4.x.

यह वर्तनी-जांचकर्ता कार्यान्वयन पर निर्भर करती है, लेकिन मुझे लगता है कि Solr 3.x वर्तनी परीक्षक उम्मीदवारों को खोजने के लिए (यही कारण है कि यह एक जरूरत है एन-ग्राम का उपयोग करता है लगता है समर्पित सूचकांक) और फिर केवल उम्मीदवारों पर इस सेट पर दूरी की गणना करता है, इसलिए प्रदर्शन अभी भी काफी अच्छा है।