कई टेराबाइट इंडेक्स वाले क्लस्टर का एक उदाहरण के साथ स्केलिंग एलिटिक्स खोज

धीमी खोज क्वेरी गति

सामाजिक जानकारी ( ark.com ) के लिए खोज इंजन पर काम करते हुए, हमने एलिस्टिक्स खोज का विकल्प चुना, क्योंकि समीक्षाओं के अनुसार इसे स्थापित करना और उपयोग करना बहुत आसान था, उत्कृष्ट खोज क्षमताएं थीं और सामान्य तौर पर, स्वर्ग से मन्ना की तरह दिखती थीं। इसलिए यह तब तक था जब तक हमारा सूचकांक ~ 1 बिलियन दस्तावेजों के अधिक या कम सभ्य आकार तक नहीं बढ़ गया था, आकार, खाते की प्रतिकृतियों को ध्यान में रखते हुए, पहले से ही 1.5 टीबी से अधिक हो गया था।

यहां तक ​​कि बैंल Term query दसियों सेकंड ले सकती थी। ईएस पर उतने अधिक दस्तावेज नहीं हैं जितना हम चाहेंगे, और इस मुद्दे की गुगली ने हमारे खोज इंजन के प्रासंगिक संस्करणों पर 2 साल पहले परिणाम दिया (हम 0.90.13 के साथ काम करते हैं - जो कि एक पुरानी पर्याप्त चीज नहीं है, लेकिन हम इसे बर्दाश्त नहीं कर सकते हैं पूरे क्लस्टर को कम करें, इसे अपडेट करें, और इसे वर्तमान क्षण में पुनरारंभ करें - केवल रोलिंग पुनरारंभ)।

धीमी सूचकांक गति

दूसरी समस्या यह है कि हम एलिस्टिक्स की तुलना में प्रति सेकंड (लगभग 100k) अधिक दस्तावेजों को अनुक्रमित कर सकते हैं। टाइमआउट, राइट आईओ पर एक बड़ा भार, 400 इकाइयों की प्रक्रिया कतार। जब आप मार्वल में देखते हैं तो सब कुछ वास्तव में डरावना लगता है।

इन समस्याओं को कैसे हल करें - कट के तहत

स्केल एलेस्टिक्स खोज क्लस्टर

प्रारंभिक स्थिति:

• 5 डेटा नोड्स, http सक्षम:
  
  • 100 जीबी रैम
  • 16 कोर
  • 4 टीबी एचडीडी (7200 आरपीएम, सीगेट)
  
  
• सूचकांक:
  
  • 500 से 1 बिलियन दस्तावेज़, केवल 5 टुकड़े
  • 50 से 400 तक प्राथमिक शर्ड की संख्या (यहां हमने अलग-अलग इंडेक्सिंग रणनीतियों का परीक्षण किया - यह सेटिंग बहुत महत्वपूर्ण है)
  • प्रतिकृतियां - 2 से 5 तक
  • सूचकांक का आकार 1.5 टेराबाइट तक है
  
  

इलास्टिक्स खोज में अनुक्रमण गति बढ़ाएँ

यह समस्या इतनी जटिल नहीं थी और इसके बारे में इंटरनेट पर थोड़ी और जानकारी है।

जाँच करने के लिए चेकलिस्ट:

• refresh_interval - कितनी बार खोज डेटा अपडेट किया जाता है, जितना अधिक बार, उतना ही अधिक IO आपकी आवश्यकता है
• index.translog.flush_threshold_ops - डिस्क पर डेटा डंप करने के लिए कितने ऑपरेशन के बाद
• index.translog.flush_threshold_size - डिस्क में फ्लश होने से पहले इंडेक्स में कितना डेटा जोड़ा जाना चाहिए

यहाँ विस्तृत दस्तावेज: www.elasticsearch.org/guide/en/elasticsearch/reference/current/indices-update-settings.html

सबसे पहले, हमने रिफ्रेश_एंटरवल को 30 सेकंड तक बढ़ा दिया, और वास्तव में थ्रूपुट को लगभग 5000 दस्तावेज़ प्रति सेकंड तक बढ़ा दिया। बाद में उन्होंने 5000 ऑपरेशनों में flush_threshold_ops सेट किए, और आकार 500 mb तक है। यदि आप चाहें, तो आप प्रतिकृतियों, शारदों, और इसी तरह की संख्या के साथ खेल सकते हैं, लेकिन इससे बहुत फर्क नहीं पड़ेगा। इसके अलावा, थ्रेडपूल पर ध्यान दें, यदि आपको डेटाबेस में समानांतर प्रश्नों की संख्या बढ़ाने की आवश्यकता है, हालांकि अक्सर यह आवश्यक नहीं है।

Elasticsearch में क्वेरी गति बढ़ाएँ

अब मुश्किल हिस्से पर आगे बढ़ें। हमारे सूचकांक के आकार और निरंतरता को जानने के लिए क्लस्टर (संस्करण अद्यतन, मशीन मिनेंटंस) को रिबूट करने की आवश्यकता है, और इस तरह से खाता पदों को भी ध्यान में रखना चाहिए: gibrown.wordpress.com/2014/02/06/scaling-elasticsearch-part-2.indexing, हमने निर्णय लिया कि हमारे सूचकांक में शार्क का आकार 1-2 जीबी से अधिक नहीं होगा। RF3 को ध्यान में रखते हुए, हमारे सूचकांक (हम 1.5 बिलियन दस्तावेजों पर भरोसा कर रहे हैं), यह देखते हुए कि हमारे दस्तावेजों के 0.5 बिलियन ने 300 जीबी को छोड़कर प्रतिकृतियों पर कब्जा कर लिया है, हमने इंडेक्स में 400 शार्क बनाई और गणना की कि सब कुछ ठीक होगा - रिबूट की गति पर्याप्त होगी उच्च: हमें 50-60 जीबी के डेटा ब्लॉक को पढ़ने की आवश्यकता नहीं है, और उन्हें दोहराने के लिए भी, इस प्रकार छोटे शार्क की वसूली को अवरुद्ध किया जाता है, और छोटे शार्क के लिए खोज की गति अधिक होती है।

सबसे पहले, सूचकांक में दस्तावेजों की संख्या छोटी (100-200 मिलियन) थी और क्वेरी की गति केवल 100-200 एमएस थी। लेकिन जैसे ही लगभग सभी शार्क कम से कम दस्तावेजों से भर गए, हमने क्वेरी प्रदर्शन को महत्वपूर्ण रूप से कम करना शुरू कर दिया। निरंतर इंडेक्सिंग के कारण IO पर एक उच्च भार के साथ यह सब मिलाकर, हम इसे पूरा नहीं कर सके।

इस मामले में, हमने 2 त्रुटियां कीं:

1. बहुत सारे शार्क बनाए गए (आदर्श स्थिति 1 कोर - 1 शार्क)
2. हमारे डेट नोड्स भी थे बैलेंसर नोड्स विथ http चालू - सीरियलाइजेशन एंड डिस्क्रिब्लाइजेशन ऑफ़ द डाटा ऑफ़ द टाइम

इसलिए, हमने प्रयोग करना शुरू किया।

Elaticsearch में संतुलन नोड्स जोड़ें

हमारे लिए पहला और स्पष्ट कदम एलिस्टिक्स खोज में तथाकथित balancer nodes का जोड़ था। वे अन्य परिणामों द्वारा क्वेरी परिणामों को एकत्र कर सकते हैं, वे IO के साथ कभी भी अतिभारित नहीं होंगे, क्योंकि वे डिस्क पर नहीं पढ़ते और लिखते हैं, और हम अपने डेटा नोड को ऑफलोड करेंगे।

परिनियोजन के लिए, हम शेफ और संबंधित इलास्टिक्स खोज कुकबुक का उपयोग करते हैं, इसलिए, निम्नलिखित सेटिंग्स के साथ, केवल कुछ अतिरिक्त भूमिकाएँ बनाते हैं:

 name "elasticsearch-balancer" description "Installs and launches elasticsearch" default_attributes( "elasticsearch" => { "node" => { "master" => false, "data" => false } } ) run_list("services::elasticsearch") 

हमने 4 बैलेंसर सफलतापूर्वक लॉन्च किए हैं। चित्र में थोड़ा सुधार हुआ - हमने अब हार्ड डिस्क के साथ ओवरलोड नोड्स नहीं देखे, लेकिन क्वेरी की गति अभी भी कम थी।

इलास्टिक्स खोज में डेटा नोड्स की संख्या बढ़ाएं

अब हमें याद आया कि हमारे पास (400) जितने भी शार्प थे, वे उत्पादकता में सुधार को प्रभावित करते हैं, लेकिन केवल इसे बढ़ाता है, क्योंकि एक मशीन पर बहुत अधिक शार्प हैं। सरल गणना के बाद, हमें पता चलता है कि 5 मशीनें पर्याप्त रूप से केवल 80 शार्क का समर्थन करेंगी। प्रतिकृतियों की संख्या को देखते हुए, हमारे पास उनमें से 1200 हैं।

चूंकि मशीनों का हमारा सामान्य बेड़ा (80 नोड्स) पर्याप्त संख्या में नोड्स को जोड़ने की अनुमति देता है और उनमें मुख्य समस्या एचडीडी (केवल 128 जीबी) का आकार है, हमने एक बार में लगभग 15 मशीनों को जोड़ने का फैसला किया। यह एक और 240 शार्क के साथ अधिक कुशलता से काम करने की अनुमति देगा।

इसके अलावा, हम कई दिलचस्प सेटिंग्स में आए:

* index.store.type - डिफ़ॉल्ट रूप से इसे niofs पर सेट किया जाता है, और मानदंड द्वारा प्रदर्शन mmapfs की तुलना में कम है - हमने इसे mmapfs में बदल दिया (डिफ़ॉल्ट मान 1.x है)
* indices.memory.index_buffer_size - 30% तक बढ़ गया, और इसके विपरीत, जावा हीप के तहत रैम की मात्रा 30 जीबी तक घट गई (यह 50% थी), चूंकि एमएमएफ़एफ़ के साथ हमें ऑपरेटिंग सिस्टम कैश के लिए बहुत अधिक रैम की आवश्यकता होती है

और निश्चित रूप से, हमारे मामले में, मुक्त स्थान के आधार पर शार्क के स्थान के नियंत्रण को सक्षम करना अनिवार्य था:

 curl -XPUT localhost:9200/_cluster/settings -d '{ "transient" : { "cluster.routing.allocation.disk.threshold_enabled" : true } }' 

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

क्लस्टर को स्केल करते समय और क्या विचार करें

क्लस्टर पुनरारंभ करते समय, शर्ड्स को स्थानांतरित करने की क्षमता को बंद करना सुनिश्चित करें: पुराने संस्करणों में क्लस्टर cluster.routing.allocation.enable = none , थोड़ा अलग सेटिंग।

यदि आपको इसे पढ़ते समय कोई प्रश्न है, तो मुझे इस पर चर्चा करने में खुशी होगी।