महत्वपूर्ण शब्द सर्किट ब्रेकिंग अपवाद

Question

का कारण बनता है मुझे मध्य आकार का लोचदार खोज सूचकांक (1.46T या ~ 1e8 दस्तावेज़) मिला है। यह 4 सर्वरों पर चल रहा है जिनमें प्रत्येक के पास लोचदार और ओएस (कैशिंग के लिए) के बीच समान रूप से 64 जीबी राम विभाजित होता है।

मैं नए "महत्वपूर्ण शब्द" एकत्रीकरण तो मैं निम्न क्वेरी बंद निकाल बाहर की कोशिश करना चाहते ...

{ 
    "query": { 
    "ids": { 
     "type": "document", 
     "values": [ 
     "xCN4T1ABZRSj6lsB3p2IMTffv9-4ztzn1R11P_NwTTc" 
     ] 
    } 
    }, 
    "aggregations": { 
    "Keywords": { 
     "significant_terms": { 
     "field": "Body" 
     } 
    } 
    }, 
    "size": 0 
} 

कौन सा दस्तावेज़ सूचकांक के बाकी के साथ निर्दिष्ट के शरीर की तुलना और खोजना चाहिए दस्तावेज़ में महत्वपूर्ण शब्द जो सूचकांक में आम नहीं हैं।

दुर्भाग्य से, यह सदा ही में एक

ElasticsearchException परिणाम [org.elasticsearch.common.breaker.CircuitBreakingException: डेटा बहुत बड़ी है, डेटा की सीमा [+२५७४१९११६५४] बाइट से बड़ी होगी];

नेस्टेड: अनचेक एक्सेक्यूशन अपवाद [org.elasticsearch.common.breaker.CircuitBreakingException: डेटा बहुत बड़ा है, डेटा [25741911654] बाइट्स की सीमा से बड़ा होगा;

नेस्टेड: सर्किट ब्रेकिंग अपवाद [डेटा बहुत बड़ा, डेटा [25741911654] बाइट्स की सीमा से बड़ा होगा;

एक या दो मिनट के बाद और मुझे लगता है कि मुझे पर्याप्त स्मृति नहीं मिली है।

प्रश्न में लोचदार सर्वर वास्तव में वीएम हैं, इसलिए मैंने अन्य वीएम बंद कर दिए और प्रत्येक लोचदार उदाहरण 96 जीबी और प्रत्येक ओएस को 96 जीबी दिया।

वही समस्या आई (विभिन्न संख्याएं, अधिक समय ले लीं)। मुझे 1 9 2 जीबी से अधिक मेमोरी उपलब्ध कराने के लिए हार्डवेयर नहीं मिला है इसलिए उच्च नहीं जा सकता है।

क्या समेकन पूरी तरह से सूचकांक के खिलाफ उपयोग के लिए नहीं हैं? क्या मैं क्वेरी प्रारूप के संबंध में गलती कर रहा हूं?

Answer 1

बहुत बड़े सूचकांक [1] के लिए फ्री-टेक्स्ट फ़ील्ड पर रैम उपयोग के बारे में इस समेकन के लिए प्रलेखन पर एक चेतावनी है। बड़े सूचकांक पर यह एक छोटे शब्दावली (जैसे हैशटैग) लेकिन कई मुक्त-पाठ नियम और कई डॉक्स के संयोजन के साथ कम-गणनसंख्या क्षेत्रों के लिए ठीक काम करता है एक स्मृति-हॉग है। आप कम आवृत्ति पदों की लंबी पूंछ (जैसे दस्तावेज़ आवृत्ति < 2) जो राम ओवरहेड्स कम होगी ट्रिम करने के लिए शरीर के लिए क्षेत्र FieldData कैश [2] की लोडिंग पर एक फिल्टर निर्दिष्ट करने पर दिखाई दे सकता है।

मैंने इस एल्गोरिदम की एक भिन्नता का उपयोग किया है, जहां पहले शीर्ष मिलान वाले दस्तावेज़ों का केवल नमूना महत्वपूर्ण शब्दों के लिए विश्लेषण किया गया था और इस दृष्टिकोण को कम रैम की आवश्यकता होती है क्योंकि केवल शीर्ष एन दस्तावेज़ डिस्क और टोकनिज्ड से पढ़े जाते हैं (टर्म वेक्टर या एक विश्लेषक)। हालांकि, अब के लिए Elasticsearch में कार्यान्वयन फ़ील्डडाटा कैश पर निर्भर करता है और सभी मिलान करने वाले दस्तावेज़ों के लिए शर्तें देखता है।

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