मूल रूप से 27 नवंबर, 2020 को ObjectRocket.com/blog पर प्रकाशित।
Elasticsearch® डिफ़ॉल्ट सेटिंग्स के साथ आपके क्लस्टर में डेटा फैलाने में बहुत अच्छा है, लेकिन आपके क्लस्टर के बढ़ने शुरू होने के बाद, आपको प्रभावशीलता बढ़ाने के लिए अपनी डिफ़ॉल्ट सेटिंग्स को समायोजित करना चाहिए। आइए शार्डिंग की कुछ मूल बातों पर जाएं और कुछ इंडेक्सिंग और शार्ड सर्वोत्तम अभ्यास प्रदान करें।
Elasticsearch शार्डिंग का परिचय
Elasticsearch शार्ड कैसे काम करते हैं, इस बारे में कई दस्तावेज़ हैं, लेकिन शार्डिंग की मूल अवधारणा आपके डेटा को कई छोटे टुकड़ों में तोड़ना है ताकि खोज कई हिस्सों पर समानांतर में काम कर सके। इंडेक्स कार्यों के क्लस्टरिंग और समानांतरकरण को सुविधाजनक बनाने के लिए, अपने Elasticsearch इंस्टेंस में प्रत्येक इंडेक्स को संख्याबद्ध स्लाइस में काटें। इन स्लाइस को शार्ड कहा जाता है। आइए उनके कुछ प्रमुख व्यवहारों को देखें:
- प्रत्येक शार्ड इंडेक्स के लिए number of replicas सेटिंग के आधार पर रेप्लिकेट होता है। इसलिए, number of replicas सेटिंग एक के लिए, प्रत्येक शार्ड की दो प्रतियां होती हैं: एक प्राथमिक शार्ड और एक रेप्लिका शार्ड। प्राथमिक शार्ड मुख्य शार्ड है और
indexing/writeऔरsearch/readऑपरेशन के लिए उपयोग किया जाता है, जबकि रेप्लिका शार्ड केवलsearch/readऑपरेशन के लिए और प्राथमिक विफल होने पर रिकवरी के लिए उपयोग किए जाते हैं। - रेप्लिका शार्ड को अपने पैरेंट प्राथमिक शार्ड से अलग होस्ट पर रहना चाहिए।
- शार्ड डिफ़ॉल्ट रूप से क्लस्टर में होस्ट की संख्या में स्वचालित रूप से फैलते हैं, लेकिन वही भौतिक होस्ट कई प्राथमिक शार्ड रख सकता है। आप इस व्यवहार को संशोधित करने के लिए Elasticsearch सेटिंग्स का उपयोग कर सकते हैं (रीबैलेंसिंग, शार्ड आवंटन, आदि), लेकिन वह प्रक्रिया इस पोस्ट के दायरे से बाहर है।
- प्रत्येक शार्ड केवल एक होस्ट में रहना चाहिए क्योंकि शार्ड अविभाज्य हैं।
- आप इंडेक्स निर्माण के दौरान एक इंडेक्स द्वारा बनाए जाने वाले शार्ड की संख्या निर्धारित कर सकते हैं, या आप वैश्विक डिफ़ॉल्ट का उपयोग कर सकते हैं। इंडेक्स बनाने के बाद, आप रीइंडेक्सिंग के बिना शार्ड की संख्या नहीं बदल सकते।
- आप इंडेक्स निर्माण के दौरान एक इंडेक्स में रेप्लिका की संख्या निर्धारित कर सकते हैं, या आप वैश्विक डिफ़ॉल्ट का उपयोग कर सकते हैं। आप इंडेक्स बनाने के बाद इस संख्या को बदल सकते हैं।
आइए एक छोटा उदाहरण देखें। मैंने तीन के शार्ड काउंट और एक की रेप्लिका सेटिंग के साथ एक इंडेक्स बनाया। जैसा कि आप पूर्ववर्ती आरेख में देख सकते हैं, Elasticsearch आपके लिए छह शार्ड बनाता है: तीन प्राथमिक शार्ड (Ap, Bp, और Cp) और तीन रेप्लिका शार्ड (Ar, Br, और Cr)।
Elasticsearch सुनिश्चित करता है कि रेप्लिका और प्राथमिक अलग-अलग होस्ट पर हैं, लेकिन आप एक ही होस्ट पर कई प्राथमिक शार्ड आवंटित कर सकते हैं। होस्ट के विषय पर, आइए देखें कि आप अपने होस्ट को शार्ड कैसे आवंटित करते हैं।
शार्ड आवंटन और क्लस्टर्ड Elasticsearch
Elasticsearch डिफ़ॉल्ट रूप से सभी उपलब्ध होस्ट में शार्ड आवंटित करने का प्रयास करता है। Rackspace ObjectRocket पर, प्रत्येक क्लस्टर में मास्टर नोड्स, क्लाइंट नोड्स, और डेटा नोड्स होते हैं। हमारी आर्किटेक्चर में डेटा नोड्स उन बकेट का निर्माण करते हैं जिनको आप शार्ड असाइन कर सकते हैं।
पूर्ववर्ती उदाहरण का उपयोग करते हुए, आइए उन छह शार्ड को लेते हैं और उन्हें दो डेटा नोड्स (न्यूनतम) के साथ ObjectRocket for Elasticsearch क्लस्टर पर असाइन करते हैं। निम्न आरेख में, आप देख सकते हैं कि प्रत्येक शार्ड के लिए, प्राथमिक एक डेटा नोड पर आता है, जबकि रेप्लिका की गारंटी है कि वह दूसरे नोड पर हो। ध्यान रखें कि यहां दिए गए उदाहरण केवल एक संभावित आवंटन दिखाते हैं। आवंटन चाहे जो भी हो, एकमात्र निश्चित बात यह है कि एक रेप्लिका हमेशा अपने प्राथमिक से अलग डेटा नोड पर रखा जाता है।
अब, आइए इस उदाहरण को बढ़ाएं और एक तीसरा डेटा नोड जोड़ें। ध्यान दें कि दो शार्ड नए डेटा नोड पर चले जाते हैं, इसलिए प्रत्येक नोड पर दो शार्ड होते हैं।
अंत में, आइए इस क्लस्टर में दो के शार्ड काउंट और दो पर सेट रेप्लिका की संख्या के साथ एक नया इंडेक्स जोड़ें। यह आपको दो नए प्राथमिक (Xp और Yp) और चार रेप्लिका (Xr0, Xr1, Yr0, Yr1) देता है जिन्हें आप क्लस्टर में फैला सकते हैं जैसा कि निम्न छवि में देखा गया है।
नुकसान
Elasticsearch आपके लिए सारा कठिन काम करता है, लेकिन कुछ नुकसान हैं जिनसे बचना चाहिए।
नुकसान #1—बड़े इंडेक्स और बड़े शार्ड
बड़े शार्ड के साथ बड़े इंडेक्स का समस्या निवारण Elasticsearch में कम करने के लिए सबसे आसान मुद्दों में से एक है। एक उपयोगकर्ता बहुत प्रबंधनीय सिंगल इंडेक्स के साथ शुरू होता है। हालांकि, जैसे-जैसे उनका एप्लिकेशन बढ़ता है, वैसे-वैसे उनका इंडेक्स भी बढ़ता है। यह बड़े शार्ड की ओर ले जाता है क्योंकि शार्ड का आकार सीधे क्लस्टर डेटा की मात्रा से संबंधित होता है।
पहला मुद्दा जो यह कारण बनता है वह है क्लस्टर उपयोग में खराब दक्षता। जैसे-जैसे शार्ड बढ़ते हैं, उन्हें डेटा नोड पर रखना कठिन हो जाता है। एक शार्ड को वहां स्टोर करने के लिए डेटा नोड फ्री स्पेस का एक बड़ा ब्लॉक लगता है। यह स्थिति नोड्स को बहुत सारे अप्रयुक्त, बर्बाद स्पेस के साथ ले जाती है। उदाहरण के लिए, यदि मेरे पास 8 GB डेटा नोड्स हैं, लेकिन प्रत्येक शार्ड 6 GB है, तो मैं अपने प्रत्येक डेटा नोड पर 2 GB फंसा दूंगा। दूसरा मुद्दा हॉट स्पॉटिंग है। यदि आप अपने डेटा को कुछ शार्ड में समेकित करते हैं, तो जटिल क्वेरी को बड़ी संख्या में नोड्स पर विभाजित नहीं किया जा सकता और समानांतर में निष्पादित नहीं किया जा सकता।
इंडेक्स के साथ कंजूसी न करें
रुके हुए स्पेस मुद्दों को हल करने के लिए कई इंडेक्स का उपयोग करें। अपने डेटा को कई इंडेक्स में फैलाएं ताकि क्लस्टर में शार्ड की संख्या बढ़े और डेटा समान रूप से फैले। इसके अलावा, टेट्रिस खेल की तरह, जब Elasticsearch शार्ड रखता है, तो कई इंडेक्स क्यूरेट करना आसान होता है। Elasticsearch में उपनाम क्षमताएं अभी भी कई इंस्टेंस को आपके ऐप के लिए सिंगल इंडेक्स के रूप में प्रकट कर सकती हैं। अधिकांश Elastic Stack डिफ़ॉल्ट रूप से दैनिक इंडेक्स बनाता है, जो एक अच्छी प्रथा है। आप तब विशिष्ट तारीख सीमा तक खोजों के दायरे को सीमित करने के लिए उपनामों का उपयोग कर सकते हैं, पुराने इंडेक्स को हटाने के लिए क्यूरेटर का उपयोग कर सकते हैं जैसे-जैसे वे पुराने होते हैं, और पुराने डेटा को रीइंडेक्स किए बिना अपने डेटा के बढ़ने के साथ इंडेक्स सेटिंग्स को संशोधित कर सकते हैं।
जैसे-जैसे आपका इंडेक्स आकार बढ़ता है, शार्ड काउंट बढ़ाएं
अधिक बार इंडेक्स जोड़ें और जैसे-जैसे आपका इंडेक्स बढ़ता है शार्ड काउंट बढ़ाएं। आपके द्वारा शार्ड आकार को अपने वांछित स्थान से अधिक होते देखने के बाद, आप अपने इंडेक्स टेम्पलेट (या जो भी आप नए इंडेक्स बनाने के लिए उपयोग करते हैं) को प्रत्येक इंडेक्स के लिए अधिक शार्ड उपयोग करने के लिए अपडेट कर सकते हैं। हालांकि, यह केवल तभी मदद करता है जब आप अक्सर नए इंडेक्स बनाते हैं, इसलिए यह सिफारिश दूसरी सूचीबद्ध है। अन्यथा, आपको शार्ड काउंट को संशोधित करने के लिए रीइंडेक्स करना होगा, जो कई इंडेक्स प्रबंधित करने से अधिक काम का प्रतिनिधित्व करता है।
हमारा अनुभव नियम: यदि एक शार्ड डेटा नोड के आकार के 40% से बड़ा है, तो वह शार्ड शायद बहुत बड़ा है। इस मामले में, हम अधिक शार्ड वाले इंडेक्स में रीइंडेक्स करने या बड़े प्लान आकार (प्रति डेटा नोड अधिक क्षमता) पर जाने की सलाह देते हैं।
नुकसान #2—बहुत अधिक इंडेक्स या शार्ड
उलटा बहुत अधिक इंडेक्स या शार्ड है। पिछले खंड को पढ़ने के बाद, आप बस कह सकते हैं, "ठीक है। मैं हर डॉक को उसके इंडेक्स में रखूंगा और दस लाख शार्ड बनाऊंगा।" वहां समस्या यह है कि इंडेक्स और शार्ड का ओवरहेड होता है। वह ओवरहेड स्टोरेज, मेमोरी संसाधनों, और प्रोसेसिंग प्रदर्शन में खुद को प्रकट करता है।
क्योंकि क्लस्टर को सभी शार्ड की स्थिति और वे कहां स्थित हैं, बनाए रखना चाहिए, शार्ड की एक बड़ी संख्या एक बड़ी बुककीपिंग ऑपरेशन बन जाती है, जो मेमोरी उपयोग को प्रभावित करती है। इसके अलावा, क्योंकि आपको क्वेरी को अधिक तरीकों से विभाजित करने की आवश्यकता होती है, आप क्वेरी के लिए स्कैटर या गैदर में बहुत अधिक समय बिताते हैं। यह नुकसान क्लस्टर के आकार, उपयोग के मामले, और अन्य कारकों पर अत्यधिक निर्भर है, लेकिन सामान्य तौर पर, हम कुछ सिफारिशों के साथ इसे कम कर सकते हैं।
शार्ड 50 GB से बड़े नहीं होने चाहिए
सामान्य तौर पर, 25 GB बड़े शार्ड के लिए एक आदर्श आकार है, और 50 GB के लिए रीइंडेक्सिंग की आवश्यकता होती है। यह विचार शार्ड के प्रदर्शन और उस शार्ड को आवश्यकता पड़ने पर स्थानांतरित करने की प्रक्रिया से संबंधित है। रीबैलेंसिंग करते समय, शार्ड को क्लस्टर में एक अलग नोड पर ले जाएं। 50 GB डेटा ट्रांसफर में बहुत अधिक समय लग सकता है और पूरी प्रक्रिया के दौरान दो नोड्स को बांध सकता है।
शार्ड आकार को डेटा नोड आकार के 40% से कम रखें
जैसा कि पहले उल्लेख किया गया है, दूसरा शार्ड आकार मीट्रिक जो हमें रुचिकर लगता है वह है डेटा नोड क्षमता का प्रतिशत जो एक शार्ड लेता है। Rackspace ObjectRocket सर्विस पर, हम विभिन्न प्लान आकार प्रदान करते हैं जो डेटा नोड्स पर स्टोरेज की मात्रा से संबंधित हैं। हम क्लस्टर और शार्ड को आकार देने की कोशिश करते हैं ताकि यह सुनिश्चित हो सके कि सबसे बड़े शार्ड डेटा नोड की क्षमता का 40% से अधिक न लें। विभिन्न आकारों के कई इंडेक्स वाले क्लस्टर में, यह काफी प्रभावी है। हालांकि, बहुत कम बड़े इंडेक्स वाले क्लस्टर में, हम और भी अधिक आक्रामक होते हैं और डेटा नोड की क्षमता को 30% से नीचे रखने की कोशिश करते हैं।
आदर्श रूप से, सुनिश्चित करें कि आप डेटा नोड पर क्षमता नहीं फंसा रहे हैं। यदि आपके शार्ड डेटा नोड के आकार का लगभग 45% हैं, तो आपको उस शार्ड को रखने के लिए लगभग आधे उपयोग पर एक डेटा नोड की आवश्यकता होती है। यह बहुत सारी अप्रयुक्त अतिरिक्त क्षमता है!
निष्कर्ष
सही शार्ड और इंडेक्सिंग सेटिंग्स का चयन करना मुश्किल हो सकता है, लेकिन योजना बनाकर, कुछ अच्छे निर्णय पहले लेकर, और जैसे-जैसे आप आगे बढ़ते हैं ट्यूनिंग करके, आप अपने क्लस्टर को स्वस्थ और बेहतर तरीके से चलते रख सकते हैं। हम हर समय व्यवसायों को उनके Elasticsearch इंस्टेंस को परिष्कृत करने में मदद करते हैं।
Rackspace DBA Services के बारे में अधिक जानें।
कोई भी टिप्पणी करने या प्रश्न पूछने के लिए Feedback टैब का उपयोग करें। आप Sales Chat पर क्लिक करके अभी चैट कर सकते हैं और बातचीत शुरू कर सकते हैं।
