🥇HBase से पढ़ने की गति को 3 गुना और HDFS से 5 गुना तक कैसे बढ़ाएं

बड़े डेटा के साथ काम करते समय उच्च प्रदर्शन प्रमुख आवश्यकताओं में से एक है। Sberbank के डेटा लोडिंग विभाग में, हम लगभग सभी लेनदेन को अपने Hadoop-आधारित डेटा क्लाउड में पंप करते हैं और इसलिए सूचना के वास्तव में बड़े प्रवाह से निपटते हैं। स्वाभाविक रूप से, हम हमेशा प्रदर्शन को बेहतर बनाने के तरीकों की तलाश में रहते हैं, और अब हम आपको बताना चाहते हैं कि हम रीजनसर्वर HBase और HDFS क्लाइंट को कैसे पैच करने में कामयाब रहे, जिसकी बदौलत हम रीड ऑपरेशंस की गति में उल्लेखनीय वृद्धि करने में सक्षम हुए।

हालाँकि, सुधारों के सार पर आगे बढ़ने से पहले, उन प्रतिबंधों के बारे में बात करना उचित है, जिन्हें सिद्धांत रूप में, यदि आप एचडीडी पर बैठते हैं, तो दरकिनार नहीं किया जा सकता है।

एचडीडी और तेज़ रैंडम एक्सेस रीड असंगत क्यों हैं?
जैसा कि आप जानते हैं, HBase और कई अन्य डेटाबेस, डेटा को कई दसियों किलोबाइट आकार के ब्लॉक में संग्रहीत करते हैं। डिफ़ॉल्ट रूप से यह लगभग 64 KB है. अब आइए कल्पना करें कि हमें केवल 100 बाइट्स प्राप्त करने की आवश्यकता है और हम HBase से एक निश्चित कुंजी का उपयोग करके हमें यह डेटा देने के लिए कहते हैं। चूँकि HFiles में ब्लॉक का आकार 64 KB है, अनुरोध आवश्यकता से 640 गुना बड़ा (सिर्फ एक मिनट!) होगा।

अगला, चूंकि अनुरोध एचडीएफएस और उसके मेटाडेटा कैशिंग तंत्र से होकर गुजरेगा शॉर्टसर्किट कैश (जो फ़ाइलों तक सीधी पहुंच की अनुमति देता है), इससे डिस्क से पहले ही 1 एमबी पढ़ना शुरू हो जाता है। हालाँकि, इसे पैरामीटर के साथ समायोजित किया जा सकता है dfs.client.read.shortcircuit.buffer.size और कई मामलों में इस मान को कम करना समझ में आता है, उदाहरण के लिए 126 केबी तक।

मान लीजिए कि हम ऐसा करते हैं, लेकिन इसके अलावा, जब हम जावा एपीआई के माध्यम से डेटा पढ़ना शुरू करते हैं, जैसे कि FileChannel.read जैसे फ़ंक्शन और ऑपरेटिंग सिस्टम को निर्दिष्ट मात्रा में डेटा पढ़ने के लिए कहते हैं, तो यह "बस के मामले में" 2 गुना अधिक पढ़ता है , अर्थात। हमारे मामले में 256 केबी। ऐसा इसलिए है क्योंकि जावा के पास इस व्यवहार को रोकने के लिए FADV_RANDOM ध्वज सेट करने का कोई आसान तरीका नहीं है।

परिणामस्वरूप, हमारी 100 बाइट्स प्राप्त करने के लिए, हुड के नीचे 2600 गुना अधिक पढ़ा जाता है। ऐसा प्रतीत होता है कि समाधान स्पष्ट है, आइए ब्लॉक आकार को एक किलोबाइट तक कम करें, उल्लिखित ध्वज सेट करें और महान ज्ञानोदय त्वरण प्राप्त करें। लेकिन परेशानी यह है कि ब्लॉक आकार को 2 गुना कम करके, हम समय की प्रति यूनिट पढ़ी जाने वाली बाइट्स की संख्या को भी 2 गुना कम कर देते हैं।

FADV_RANDOM ध्वज को सेट करने से कुछ लाभ प्राप्त किया जा सकता है, लेकिन केवल उच्च मल्टी-थ्रेडिंग और 128 केबी के ब्लॉक आकार के साथ, लेकिन यह अधिकतम कुछ दसियों प्रतिशत है:

परीक्षण 100 फ़ाइलों पर किए गए, प्रत्येक 1 जीबी आकार की और 10 एचडीडी पर स्थित थीं।

आइए गणना करें कि हम सैद्धांतिक रूप से इस गति पर क्या भरोसा कर सकते हैं:
मान लीजिए कि हम 10 डिस्क से 280 एमबी/सेकंड की गति से पढ़ते हैं, यानी। 3 मिलियन गुना 100 बाइट्स. लेकिन जैसा कि हमें याद है, हमें जो डेटा चाहिए वह पढ़े जाने वाले डेटा से 2600 गुना कम है। इस प्रकार, हम 3 मिलियन को 2600 से विभाजित करते हैं और प्राप्त करते हैं प्रति सेकंड 1100 रिकॉर्ड।

निराशाजनक, है ना? वह प्रकृति है रैंडम एक्सेस एचडीडी पर डेटा तक पहुंच - ब्लॉक आकार की परवाह किए बिना। यह रैंडम एक्सेस की भौतिक सीमा है और कोई भी डेटाबेस ऐसी परिस्थितियों में इससे अधिक नहीं निकाल सकता है।

फिर डेटाबेस बहुत अधिक गति कैसे प्राप्त करते हैं? इस प्रश्न का उत्तर देने के लिए, आइए देखें कि निम्नलिखित चित्र में क्या हो रहा है:

यहां हम देखते हैं कि पहले कुछ मिनटों के लिए गति वास्तव में प्रति सेकंड लगभग एक हजार रिकॉर्ड है। हालाँकि, इसके अलावा, इस तथ्य के कारण कि अनुरोध की तुलना में बहुत अधिक पढ़ा जाता है, डेटा ऑपरेटिंग सिस्टम (लिनक्स) के बफ़/कैश में समाप्त हो जाता है और गति बढ़कर 60 हजार प्रति सेकंड हो जाती है।

इस प्रकार, आगे हम केवल उस डेटा तक पहुंच को तेज करने से निपटेंगे जो ओएस कैश में है या तुलनीय एक्सेस गति के एसएसडी/एनवीएमई स्टोरेज डिवाइस में स्थित है।

हमारे मामले में, हम 4 सर्वरों की एक बेंच पर परीक्षण करेंगे, जिनमें से प्रत्येक का शुल्क निम्नानुसार है:

सीपीयू: Xeon E5-2680 v4 @ 2.40GHz 64 थ्रेड।
मेमोरी: 730 जीबी.
जावा संस्करण: 1.8.0_111

और यहां मुख्य बिंदु तालिकाओं में डेटा की मात्रा है जिसे पढ़ने की आवश्यकता है। तथ्य यह है कि यदि आप किसी तालिका से डेटा पढ़ते हैं जो पूरी तरह से HBase कैश में रखा गया है, तो यह ऑपरेटिंग सिस्टम के बफ़/कैश से भी पढ़ने में नहीं आएगा। क्योंकि HBase डिफ़ॉल्ट रूप से 40% मेमोरी को ब्लॉक कैश नामक संरचना में आवंटित करता है। अनिवार्य रूप से यह एक ConcurrentHashMap है, जहां कुंजी फ़ाइल नाम + ब्लॉक का ऑफसेट है, और मान इस ऑफसेट पर वास्तविक डेटा है।

इस प्रकार, जब हम केवल इस संरचना से पढ़ते हैं हम उत्कृष्ट गति देखते हैं, प्रति सेकंड दस लाख अनुरोधों की तरह। लेकिन आइए कल्पना करें कि हम केवल डेटाबेस आवश्यकताओं के लिए सैकड़ों गीगाबाइट मेमोरी आवंटित नहीं कर सकते, क्योंकि इन सर्वरों पर कई अन्य उपयोगी चीजें चल रही हैं।

उदाहरण के लिए, हमारे मामले में, एक आरएस पर ब्लॉक कैश की मात्रा लगभग 12 जीबी है। हमने एक नोड पर दो आरएस उतारे, यानी। सभी नोड्स पर ब्लॉक कैश के लिए 96 जीबी आवंटित किए गए हैं। और कई गुना अधिक डेटा है, उदाहरण के लिए, इसे 4 टेबल, प्रत्येक 130 क्षेत्र होने दें, जिसमें फ़ाइलें 800 एमबी आकार की हैं, FAST_DIFF द्वारा संपीड़ित हैं, यानी। कुल 410 जीबी (यह शुद्ध डेटा है, यानी प्रतिकृति कारक को ध्यान में रखे बिना)।

इस प्रकार, ब्लॉककैश कुल डेटा वॉल्यूम का केवल 23% है और यह बिगडेटा कहलाने वाली वास्तविक स्थितियों के बहुत करीब है। और यहीं से मजा शुरू होता है - क्योंकि जाहिर है, जितना कम कैश हिट होगा, प्रदर्शन उतना ही खराब होगा। आख़िरकार, यदि आप चूक गए, तो आपको बहुत काम करना होगा - अर्थात। सिस्टम फ़ंक्शंस को कॉल करने के लिए नीचे जाएं। हालाँकि, इसे टाला नहीं जा सकता है, तो आइए एक बिल्कुल अलग पहलू पर नजर डालें - कैश के अंदर डेटा का क्या होता है?

आइए स्थिति को सरल बनाएं और मान लें कि हमारे पास एक कैश है जो केवल 1 ऑब्जेक्ट में फिट बैठता है। यहां एक उदाहरण दिया गया है कि क्या होगा जब हम कैश से 3 गुना बड़े डेटा वॉल्यूम के साथ काम करने का प्रयास करेंगे, हमें यह करना होगा:

1. ब्लॉक 1 को कैश में रखें
2. कैश से ब्लॉक 1 हटाएं
3. ब्लॉक 2 को कैश में रखें
4. कैश से ब्लॉक 2 हटाएं
5. ब्लॉक 3 को कैश में रखें

5 कार्य पूर्ण! हालाँकि, इस स्थिति को सामान्य नहीं कहा जा सकता है; वास्तव में, हम HBase को पूरी तरह से बेकार काम करने के लिए मजबूर कर रहे हैं। यह लगातार ओएस कैश से डेटा पढ़ता है, इसे ब्लॉक कैश में रखता है, केवल इसे लगभग तुरंत बाहर फेंकने के लिए क्योंकि डेटा का एक नया हिस्सा आ गया है। पोस्ट की शुरुआत में एनीमेशन समस्या का सार दिखाता है - कचरा संग्रहकर्ता का काम बंद हो रहा है, माहौल गर्म हो रहा है, दूर और गर्म स्वीडन में छोटी ग्रेटा परेशान हो रही है। और हम आईटी लोगों को वास्तव में यह पसंद नहीं है जब बच्चे दुखी होते हैं, इसलिए हम सोचना शुरू कर देते हैं कि हम इसके बारे में क्या कर सकते हैं।

क्या होगा यदि आप कैश में सभी ब्लॉक नहीं, बल्कि उनमें से केवल एक निश्चित प्रतिशत डालते हैं, ताकि कैश ओवरफ़्लो न हो? आइए ब्लॉक कैश में डेटा डालने के लिए फ़ंक्शन की शुरुआत में कोड की केवल कुछ पंक्तियाँ जोड़कर शुरुआत करें:

  public void cacheBlock(BlockCacheKey cacheKey, Cacheable buf, boolean inMemory) {
    if (cacheDataBlockPercent != 100 && buf.getBlockType().isData()) {
      if (cacheKey.getOffset() % 100 >= cacheDataBlockPercent) {
        return;
      }
    }
...

यहां मुद्दा निम्नलिखित है: ऑफसेट फ़ाइल में ब्लॉक की स्थिति है और इसके अंतिम अंक यादृच्छिक रूप से और समान रूप से 00 से 99 तक वितरित किए जाते हैं। इसलिए, हम केवल उन लोगों को छोड़ देंगे जो हमें आवश्यक सीमा में आते हैं।

उदाहरण के लिए, कैशडेटाब्लॉकपेसेंट = 20 सेट करें और देखें कि क्या होता है:

परिणाम स्पष्ट है. नीचे दिए गए ग्राफ़ में, यह स्पष्ट हो जाता है कि इतनी तेजी क्यों आई - हम कैश में डेटा रखने के सिसिफ़ियन कार्य किए बिना बहुत सारे जीसी संसाधनों को बचाते हैं, केवल इसे तुरंत मार्टियन कुत्तों की नाली में फेंकने के लिए:

साथ ही, सीपीयू उपयोग बढ़ता है, लेकिन उत्पादकता से बहुत कम है:

यह भी ध्यान देने योग्य है कि ब्लॉक कैश में संग्रहीत ब्लॉक अलग-अलग हैं। अधिकांश, लगभग 95%, डेटा ही है। और बाकी मेटाडेटा है, जैसे ब्लूम फ़िल्टर या LEAF_INDEX और आदि. यह डेटा पर्याप्त नहीं है, लेकिन यह बहुत उपयोगी है, क्योंकि सीधे डेटा तक पहुंचने से पहले, HBase यह समझने के लिए मेटा की ओर मुड़ता है कि क्या यहां आगे खोजना आवश्यक है और यदि हां, तो वास्तव में रुचि का ब्लॉक कहां स्थित है।

इसलिए, कोड में हम एक चेक स्थिति देखते हैं buf.getBlockType().isData() और इस मेटा के लिए धन्यवाद, हम इसे किसी भी स्थिति में कैश में छोड़ देंगे।

अब आइए लोड बढ़ाएं और एक बार में फीचर को थोड़ा कस लें। पहले परीक्षण में हमने कटऑफ प्रतिशत = 20 बनाया और ब्लॉक कैश का थोड़ा कम उपयोग किया गया। अब इसे 23% पर सेट करें और हर 100 मिनट में 5 थ्रेड जोड़कर देखें कि संतृप्ति किस बिंदु पर होती है:

यहां हम देखते हैं कि मूल संस्करण लगभग तुरंत ही प्रति सेकंड लगभग 100 हजार अनुरोधों की सीमा तक पहुंच जाता है। जबकि पैच 300 हजार तक का एक्सेलरेशन देता है। साथ ही, यह स्पष्ट है कि आगे त्वरण अब इतना "मुक्त" नहीं है; सीपीयू उपयोग भी बढ़ रहा है।

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

इसे नियंत्रित करने के लिए तीन विकल्प जोड़े गए हैं:

hbase.lru.cache.heavy.eviction.count.limit - सेट करता है कि ऑप्टिमाइज़ेशन (यानी ब्लॉक छोड़ना) का उपयोग शुरू करने से पहले कैश से डेटा निकालने की प्रक्रिया कितनी बार चलनी चाहिए। डिफ़ॉल्ट रूप से यह MAX_INT = 2147483647 के बराबर है और वास्तव में इसका मतलब है कि सुविधा इस मान के साथ कभी भी काम करना शुरू नहीं करेगी। क्योंकि निष्कासन प्रक्रिया हर 5 - 10 सेकंड में शुरू होती है (यह भार पर निर्भर करता है) और 2147483647 * 10 / 60 / 60 / 24 / 365 = 680 वर्ष। हालाँकि, हम इस पैरामीटर को 0 पर सेट कर सकते हैं और लॉन्च के तुरंत बाद फीचर को काम कर सकते हैं।

हालाँकि, इस पैरामीटर में एक पेलोड भी है। यदि हमारा लोड ऐसा है कि अल्पकालिक रीड (मान लीजिए दिन के दौरान) और दीर्घकालिक रीड (रात में) लगातार आपस में जुड़े हुए हैं, तो हम यह सुनिश्चित कर सकते हैं कि सुविधा केवल तभी चालू हो जब लंबे समय तक रीड ऑपरेशन जारी हो।

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

hbase.lru.cache.heavy.eviction.mb.size.limit - सेट करता है कि हम 10 सेकंड में कितने मेगाबाइट कैश में रखना चाहते हैं (और, निश्चित रूप से, बाहर निकालना)। फीचर इस मान तक पहुंचने और इसे बनाए रखने का प्रयास करेगा। मुद्दा यह है: यदि हम गीगाबाइट को कैश में डालते हैं, तो हमें गीगाबाइट को बाहर निकालना होगा, और जैसा कि हमने ऊपर देखा, यह बहुत महंगा है। हालाँकि, आपको इसे बहुत छोटा सेट करने का प्रयास नहीं करना चाहिए, क्योंकि इससे ब्लॉक स्किप मोड समय से पहले बाहर निकल जाएगा। शक्तिशाली सर्वर (लगभग 20-40 भौतिक कोर) के लिए, लगभग 300-400 एमबी सेट करना इष्टतम है। मध्यम वर्ग के लिए (~10 कोर) 200-300 एमबी। कमजोर सिस्टम (2-5 कोर) के लिए 50-100 एमबी सामान्य हो सकता है (इन पर परीक्षण नहीं किया गया है)।

आइए देखें कि यह कैसे काम करता है: मान लें कि हमने hbase.lru.cache.heavy.eviction.mb.size.limit = 500 सेट किया है, किसी प्रकार का लोड (रीडिंग) है और फिर हर ~ 10 सेकंड में हम गणना करते हैं कि कितने बाइट्स थे सूत्र का उपयोग करके बेदखल किया गया:

ओवरहेड = मुक्त बाइट्स योग (एमबी) * 100 / सीमा (एमबी) - 100;

यदि वास्तव में 2000 एमबी हटा दिया गया, तो ओवरहेड इसके बराबर है:

2000 * 100 / 500 - 100 = 300%

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

हालाँकि, यदि लोड गिरता है, तो मान लें कि केवल 200 एमबी हटा दिया जाता है और ओवरहेड नकारात्मक हो जाता है (तथाकथित ओवरशूटिंग):

200 * 100 / 500 - 100 = -60%

इसके विपरीत, जब तक ओवरहेड सकारात्मक नहीं हो जाता, तब तक यह सुविधा कैश्ड ब्लॉक के प्रतिशत को बढ़ाएगी।

वास्तविक डेटा पर यह कैसा दिखता है इसका एक उदाहरण नीचे दिया गया है। 0% तक पहुँचने के लिए प्रयास करने की कोई आवश्यकता नहीं है, यह असंभव है। यह बहुत अच्छा है जब यह लगभग 30 - 100% होता है, इससे अल्पकालिक उछाल के दौरान अनुकूलन मोड से समय से पहले बाहर निकलने से बचने में मदद मिलती है।

hbase.lru.cache.heavy.eviction.overhead.coefficient — यह निर्धारित करता है कि हम कितनी जल्दी परिणाम प्राप्त करना चाहेंगे। यदि हम निश्चित रूप से जानते हैं कि हमारी रीडिंग अधिकतर लंबी है और हम इंतजार नहीं करना चाहते हैं, तो हम इस अनुपात को बढ़ा सकते हैं और तेजी से उच्च प्रदर्शन प्राप्त कर सकते हैं।

उदाहरण के लिए, हमने यह गुणांक = 0.01 निर्धारित किया है। इसका मतलब यह है कि परिणामी परिणाम से ओवरहेड (ऊपर देखें) को इस संख्या से गुणा किया जाएगा और कैश्ड ब्लॉक का प्रतिशत कम हो जाएगा। आइए मान लें कि ओवरहेड = 300% और गुणांक = 0.01, तो कैश्ड ब्लॉक का प्रतिशत 3% कम हो जाएगा।

एक समान "बैकप्रेशर" तर्क नकारात्मक ओवरहेड (ओवरशूटिंग) मानों के लिए भी लागू किया जाता है। चूँकि रीड और निष्कासन की मात्रा में अल्पकालिक उतार-चढ़ाव हमेशा संभव होता है, यह तंत्र आपको अनुकूलन मोड से समय से पहले बाहर निकलने से बचने की अनुमति देता है। बैकप्रेशर का एक उलटा तर्क है: ओवरशूटिंग जितना मजबूत होगा, उतने ही अधिक ब्लॉक कैश होंगे।

कार्यान्वयन कोड

        LruBlockCache cache = this.cache.get();
        if (cache == null) {
          break;
        }
        freedSumMb += cache.evict()/1024/1024;
        /*
        * Sometimes we are reading more data than can fit into BlockCache
        * and it is the cause a high rate of evictions.
        * This in turn leads to heavy Garbage Collector works.
        * So a lot of blocks put into BlockCache but never read,
        * but spending a lot of CPU resources.
        * Here we will analyze how many bytes were freed and decide
        * decide whether the time has come to reduce amount of caching blocks.
        * It help avoid put too many blocks into BlockCache
        * when evict() works very active and save CPU for other jobs.
        * More delails: https://issues.apache.org/jira/browse/HBASE-23887
        */

        // First of all we have to control how much time
        // has passed since previuos evict() was launched
        // This is should be almost the same time (+/- 10s)
        // because we get comparable volumes of freed bytes each time.
        // 10s because this is default period to run evict() (see above this.wait)
        long stopTime = System.currentTimeMillis();
        if ((stopTime - startTime) > 1000 * 10 - 1) {
          // Here we have to calc what situation we have got.
          // We have the limit "hbase.lru.cache.heavy.eviction.bytes.size.limit"
          // and can calculte overhead on it.
          // We will use this information to decide,
          // how to change percent of caching blocks.
          freedDataOverheadPercent =
            (int) (freedSumMb * 100 / cache.heavyEvictionMbSizeLimit) - 100;
          if (freedSumMb > cache.heavyEvictionMbSizeLimit) {
            // Now we are in the situation when we are above the limit
            // But maybe we are going to ignore it because it will end quite soon
            heavyEvictionCount++;
            if (heavyEvictionCount > cache.heavyEvictionCountLimit) {
              // It is going for a long time and we have to reduce of caching
              // blocks now. So we calculate here how many blocks we want to skip.
              // It depends on:
             // 1. Overhead - if overhead is big we could more aggressive
              // reducing amount of caching blocks.
              // 2. How fast we want to get the result. If we know that our
              // heavy reading for a long time, we don't want to wait and can
              // increase the coefficient and get good performance quite soon.
              // But if we don't sure we can do it slowly and it could prevent
              // premature exit from this mode. So, when the coefficient is
              // higher we can get better performance when heavy reading is stable.
              // But when reading is changing we can adjust to it and set
              // the coefficient to lower value.
              int change =
                (int) (freedDataOverheadPercent * cache.heavyEvictionOverheadCoefficient);
              // But practice shows that 15% of reducing is quite enough.
              // We are not greedy (it could lead to premature exit).
              change = Math.min(15, change);
              change = Math.max(0, change); // I think it will never happen but check for sure
              // So this is the key point, here we are reducing % of caching blocks
              cache.cacheDataBlockPercent -= change;
              // If we go down too deep we have to stop here, 1% any way should be.
              cache.cacheDataBlockPercent = Math.max(1, cache.cacheDataBlockPercent);
            }
          } else {
            // Well, we have got overshooting.
            // Mayby it is just short-term fluctuation and we can stay in this mode.
            // It help avoid permature exit during short-term fluctuation.
            // If overshooting less than 90%, we will try to increase the percent of
            // caching blocks and hope it is enough.
            if (freedSumMb >= cache.heavyEvictionMbSizeLimit * 0.1) {
              // Simple logic: more overshooting - more caching blocks (backpressure)
              int change = (int) (-freedDataOverheadPercent * 0.1 + 1);
              cache.cacheDataBlockPercent += change;
              // But it can't be more then 100%, so check it.
              cache.cacheDataBlockPercent = Math.min(100, cache.cacheDataBlockPercent);
            } else {
              // Looks like heavy reading is over.
              // Just exit form this mode.
              heavyEvictionCount = 0;
              cache.cacheDataBlockPercent = 100;
            }
          }
          LOG.info("BlockCache evicted (MB): {}, overhead (%): {}, " +
            "heavy eviction counter: {}, " +
            "current caching DataBlock (%): {}",
            freedSumMb, freedDataOverheadPercent,
            heavyEvictionCount, cache.cacheDataBlockPercent);

          freedSumMb = 0;
          startTime = stopTime;
       }

आइए अब एक वास्तविक उदाहरण का उपयोग करके इस सब को देखें। हमारे पास निम्नलिखित परीक्षण स्क्रिप्ट है:

आइए स्कैन करना शुरू करें (25 धागे, बैच = 100)
5 मिनट के बाद, मल्टी-गेट्स जोड़ें (25 धागे, बैच = 100)
5 मिनट के बाद, मल्टी-गेट्स को बंद कर दें (केवल फिर से स्कैन करना बाकी है)

हम दो रन करते हैं, पहले hbase.lru.cache.heavy.eviction.count.limit = 10000 (जो वास्तव में सुविधा को अक्षम करता है), और फिर सीमा = 0 सेट करते हैं (इसे सक्षम करता है)।

नीचे दिए गए लॉग में हम देखते हैं कि सुविधा कैसे चालू होती है और ओवरशूटिंग को 14-71% पर रीसेट करती है। समय-समय पर लोड कम हो जाता है, जिससे बैकप्रेशर और HBase कैश फिर से अधिक ब्लॉक चालू हो जाते हैं।

रीजनसर्वर लॉग करें
बेदखल (एमबी): 0, अनुपात 0.0, ओवरहेड (%): -100, भारी निष्कासन काउंटर: 0, वर्तमान कैशिंग डेटाब्लॉक (%): 100
बेदखल (एमबी): 0, अनुपात 0.0, ओवरहेड (%): -100, भारी निष्कासन काउंटर: 0, वर्तमान कैशिंग डेटाब्लॉक (%): 100
बेदखल (एमबी): 2170, अनुपात 1.09, ओवरहेड (%): 985, भारी निष्कासन काउंटर: 1, वर्तमान कैशिंग डेटाब्लॉक (%): 91 < प्रारंभ
बेदखल (एमबी): 3763, अनुपात 1.08, ओवरहेड (%): 1781, भारी निष्कासन काउंटर: 2, वर्तमान कैशिंग डेटाब्लॉक (%): 76
बेदखल (एमबी): 3306, अनुपात 1.07, ओवरहेड (%): 1553, भारी निष्कासन काउंटर: 3, वर्तमान कैशिंग डेटाब्लॉक (%): 61
बेदखल (एमबी): 2508, अनुपात 1.06, ओवरहेड (%): 1154, भारी निष्कासन काउंटर: 4, वर्तमान कैशिंग डेटाब्लॉक (%): 50
बेदखल (एमबी): 1824, अनुपात 1.04, ओवरहेड (%): 812, भारी निष्कासन काउंटर: 5, वर्तमान कैशिंग डेटाब्लॉक (%): 42
बेदखल (एमबी): 1482, अनुपात 1.03, ओवरहेड (%): 641, भारी निष्कासन काउंटर: 6, वर्तमान कैशिंग डेटाब्लॉक (%): 36
बेदखल (एमबी): 1140, अनुपात 1.01, ओवरहेड (%): 470, भारी निष्कासन काउंटर: 7, वर्तमान कैशिंग डेटाब्लॉक (%): 32
बेदखल (एमबी): 913, अनुपात 1.0, ओवरहेड (%): 356, भारी निष्कासन काउंटर: 8, वर्तमान कैशिंग डेटाब्लॉक (%): 29
बेदखल (एमबी): 912, अनुपात 0.89, ओवरहेड (%): 356, भारी निष्कासन काउंटर: 9, वर्तमान कैशिंग डेटाब्लॉक (%): 26
बेदखल (एमबी): 684, अनुपात 0.76, ओवरहेड (%): 242, भारी निष्कासन काउंटर: 10, वर्तमान कैशिंग डेटाब्लॉक (%): 24
बेदखल (एमबी): 684, अनुपात 0.61, ओवरहेड (%): 242, भारी निष्कासन काउंटर: 11, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 456, अनुपात 0.51, ओवरहेड (%): 128, भारी निष्कासन काउंटर: 12, वर्तमान कैशिंग डेटाब्लॉक (%): 21
बेदखल (एमबी): 456, अनुपात 0.42, ओवरहेड (%): 128, भारी निष्कासन काउंटर: 13, वर्तमान कैशिंग डेटाब्लॉक (%): 20
बेदखल (एमबी): 456, अनुपात 0.33, ओवरहेड (%): 128, भारी निष्कासन काउंटर: 14, वर्तमान कैशिंग डेटाब्लॉक (%): 19
बेदखल (एमबी): 342, अनुपात 0.33, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 15, वर्तमान कैशिंग डेटाब्लॉक (%): 19
बेदखल (एमबी): 342, अनुपात 0.32, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 16, वर्तमान कैशिंग डेटाब्लॉक (%): 19
बेदखल (एमबी): 342, अनुपात 0.31, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 17, वर्तमान कैशिंग डेटाब्लॉक (%): 19
बेदखल (एमबी): 228, अनुपात 0.3, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 18, वर्तमान कैशिंग डेटाब्लॉक (%): 19
बेदखल (एमबी): 228, अनुपात 0.29, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 19, वर्तमान कैशिंग डेटाब्लॉक (%): 19
बेदखल (एमबी): 228, अनुपात 0.27, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 20, वर्तमान कैशिंग डेटाब्लॉक (%): 19
बेदखल (एमबी): 228, अनुपात 0.25, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 21, वर्तमान कैशिंग डेटाब्लॉक (%): 19
बेदखल (एमबी): 228, अनुपात 0.24, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 22, वर्तमान कैशिंग डेटाब्लॉक (%): 19
बेदखल (एमबी): 228, अनुपात 0.22, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 23, वर्तमान कैशिंग डेटाब्लॉक (%): 19
बेदखल (एमबी): 228, अनुपात 0.21, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 24, वर्तमान कैशिंग डेटाब्लॉक (%): 19
बेदखल (एमबी): 228, अनुपात 0.2, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 25, वर्तमान कैशिंग डेटाब्लॉक (%): 19
बेदखल (एमबी): 228, अनुपात 0.17, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 26, वर्तमान कैशिंग डेटाब्लॉक (%): 19
बेदखल (एमबी): 456, अनुपात 0.17, ओवरहेड (%): 128, भारी निष्कासन काउंटर: 27, वर्तमान कैशिंग डेटाब्लॉक (%): 18 <जोड़ा गया (लेकिन तालिका वही है)
बेदखल (एमबी): 456, अनुपात 0.15, ओवरहेड (%): 128, भारी निष्कासन काउंटर: 28, वर्तमान कैशिंग डेटाब्लॉक (%): 17
बेदखल (एमबी): 342, अनुपात 0.13, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 29, वर्तमान कैशिंग डेटाब्लॉक (%): 17
बेदखल (एमबी): 342, अनुपात 0.11, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 30, वर्तमान कैशिंग डेटाब्लॉक (%): 17
बेदखल (एमबी): 342, अनुपात 0.09, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 31, वर्तमान कैशिंग डेटाब्लॉक (%): 17
बेदखल (एमबी): 228, अनुपात 0.08, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 32, वर्तमान कैशिंग डेटाब्लॉक (%): 17
बेदखल (एमबी): 228, अनुपात 0.07, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 33, वर्तमान कैशिंग डेटाब्लॉक (%): 17
बेदखल (एमबी): 228, अनुपात 0.06, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 34, वर्तमान कैशिंग डेटाब्लॉक (%): 17
बेदखल (एमबी): 228, अनुपात 0.05, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 35, वर्तमान कैशिंग डेटाब्लॉक (%): 17
बेदखल (एमबी): 228, अनुपात 0.05, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 36, वर्तमान कैशिंग डेटाब्लॉक (%): 17
बेदखल (एमबी): 228, अनुपात 0.04, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 37, वर्तमान कैशिंग डेटाब्लॉक (%): 17
बेदखल (एमबी): 109, अनुपात 0.04, ओवरहेड (%): -46, भारी निष्कासन काउंटर: 37, वर्तमान कैशिंग डेटाब्लॉक (%): 22 <बैक प्रेशर
बेदखल (एमबी): 798, अनुपात 0.24, ओवरहेड (%): 299, भारी निष्कासन काउंटर: 38, वर्तमान कैशिंग डेटाब्लॉक (%): 20
बेदखल (एमबी): 798, अनुपात 0.29, ओवरहेड (%): 299, भारी निष्कासन काउंटर: 39, वर्तमान कैशिंग डेटाब्लॉक (%): 18
बेदखल (एमबी): 570, अनुपात 0.27, ओवरहेड (%): 185, भारी निष्कासन काउंटर: 40, वर्तमान कैशिंग डेटाब्लॉक (%): 17
बेदखल (एमबी): 456, अनुपात 0.22, ओवरहेड (%): 128, भारी निष्कासन काउंटर: 41, वर्तमान कैशिंग डेटाब्लॉक (%): 16
बेदखल (एमबी): 342, अनुपात 0.16, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 42, वर्तमान कैशिंग डेटाब्लॉक (%): 16
बेदखल (एमबी): 342, अनुपात 0.11, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 43, वर्तमान कैशिंग डेटाब्लॉक (%): 16
बेदखल (एमबी): 228, अनुपात 0.09, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 44, वर्तमान कैशिंग डेटाब्लॉक (%): 16
बेदखल (एमबी): 228, अनुपात 0.07, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 45, वर्तमान कैशिंग डेटाब्लॉक (%): 16
बेदखल (एमबी): 228, अनुपात 0.05, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 46, वर्तमान कैशिंग डेटाब्लॉक (%): 16
बेदखल (एमबी): 222, अनुपात 0.04, ओवरहेड (%): 11, भारी निष्कासन काउंटर: 47, वर्तमान कैशिंग डेटाब्लॉक (%): 16
बेदखल (एमबी): 104, अनुपात 0.03, ओवरहेड (%): -48, भारी निष्कासन काउंटर: 47, वर्तमान कैशिंग डेटाब्लॉक (%): 21 < व्यवधान मिलता है
बेदखल (एमबी): 684, अनुपात 0.2, ओवरहेड (%): 242, भारी निष्कासन काउंटर: 48, वर्तमान कैशिंग डेटाब्लॉक (%): 19
बेदखल (एमबी): 570, अनुपात 0.23, ओवरहेड (%): 185, भारी निष्कासन काउंटर: 49, वर्तमान कैशिंग डेटाब्लॉक (%): 18
बेदखल (एमबी): 342, अनुपात 0.22, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 50, वर्तमान कैशिंग डेटाब्लॉक (%): 18
बेदखल (एमबी): 228, अनुपात 0.21, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 51, वर्तमान कैशिंग डेटाब्लॉक (%): 18
बेदखल (एमबी): 228, अनुपात 0.2, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 52, वर्तमान कैशिंग डेटाब्लॉक (%): 18
बेदखल (एमबी): 228, अनुपात 0.18, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 53, वर्तमान कैशिंग डेटाब्लॉक (%): 18
बेदखल (एमबी): 228, अनुपात 0.16, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 54, वर्तमान कैशिंग डेटाब्लॉक (%): 18
बेदखल (एमबी): 228, अनुपात 0.14, ओवरहेड (%): 14, भारी निष्कासन काउंटर: 55, वर्तमान कैशिंग डेटाब्लॉक (%): 18
बेदखल (एमबी): 112, अनुपात 0.14, ओवरहेड (%): -44, भारी निष्कासन काउंटर: 55, वर्तमान कैशिंग डेटाब्लॉक (%): 23 <बैक प्रेशर
बेदखल (एमबी): 456, अनुपात 0.26, ओवरहेड (%): 128, भारी निष्कासन काउंटर: 56, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 342, अनुपात 0.31, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 57, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 342, अनुपात 0.33, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 58, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 342, अनुपात 0.33, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 59, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 342, अनुपात 0.33, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 60, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 342, अनुपात 0.33, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 61, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 342, अनुपात 0.33, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 62, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 342, अनुपात 0.33, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 63, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 342, अनुपात 0.32, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 64, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 342, अनुपात 0.33, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 65, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 342, अनुपात 0.33, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 66, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 342, अनुपात 0.32, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 67, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 342, अनुपात 0.33, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 68, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 342, अनुपात 0.32, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 69, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 342, अनुपात 0.32, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 70, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 342, अनुपात 0.33, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 71, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 342, अनुपात 0.33, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 72, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 342, अनुपात 0.33, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 73, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 342, अनुपात 0.33, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 74, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 342, अनुपात 0.33, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 75, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 342, अनुपात 0.33, ओवरहेड (%): 71, भारी निष्कासन काउंटर: 76, वर्तमान कैशिंग डेटाब्लॉक (%): 22
बेदखल (एमबी): 21, अनुपात 0.33, ओवरहेड (%): -90, भारी निष्कासन काउंटर: 76, वर्तमान कैशिंग डेटाब्लॉक (%): 32
बेदखल (एमबी): 0, अनुपात 0.0, ओवरहेड (%): -100, भारी निष्कासन काउंटर: 0, वर्तमान कैशिंग डेटाब्लॉक (%): 100
बेदखल (एमबी): 0, अनुपात 0.0, ओवरहेड (%): -100, भारी निष्कासन काउंटर: 0, वर्तमान कैशिंग डेटाब्लॉक (%): 100

स्कैन को दो कैश अनुभागों के बीच संबंध के ग्राफ के रूप में एक ही प्रक्रिया को दिखाने की आवश्यकता थी - एकल (जहां ब्लॉक जिनके लिए पहले कभी अनुरोध नहीं किया गया है) और मल्टी (डेटा "अनुरोधित" कम से कम एक बार यहां संग्रहीत किया गया है):

और अंत में, ग्राफ़ के रूप में पैरामीटर्स का संचालन कैसा दिखता है। तुलना के लिए, कैश को शुरुआत में पूरी तरह से बंद कर दिया गया था, फिर HBase को कैशिंग के साथ लॉन्च किया गया था और अनुकूलन कार्य की शुरुआत में 5 मिनट (30 निष्कासन चक्र) की देरी हुई थी।

पूरा कोड पुल अनुरोध में पाया जा सकता है एचबीएएसई 23887 जीथब पर.

हालाँकि, इन शर्तों के तहत इस हार्डवेयर पर प्रति सेकंड 300 हजार रीड्स ही हासिल नहीं किया जा सकता है। तथ्य यह है कि जब आपको एचडीएफएस के माध्यम से डेटा तक पहुंचने की आवश्यकता होती है, तो शॉर्टसर्किट कैश (इसके बाद एसएससी के रूप में संदर्भित) तंत्र का उपयोग किया जाता है, जो आपको नेटवर्क इंटरैक्शन से बचते हुए सीधे डेटा तक पहुंचने की अनुमति देता है।

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

इसे समझने के बाद, हमने महसूस किया कि स्वतंत्र एसएससी की एक श्रृंखला बनाकर समस्या से बचा जा सकता है:

private final ShortCircuitCache[] shortCircuitCache;
...
shortCircuitCache = new ShortCircuitCache[this.clientShortCircuitNum];
for (int i = 0; i < this.clientShortCircuitNum; i++)
  this.shortCircuitCache[i] = new ShortCircuitCache(…);

और फिर अंतिम ऑफसेट अंक पर भी चौराहों को छोड़कर, उनके साथ काम करें:

public ShortCircuitCache getShortCircuitCache(long idx) {
    return shortCircuitCache[(int) (idx % clientShortCircuitNum)];
}

अब आप परीक्षण शुरू कर सकते हैं. ऐसा करने के लिए, हम एक साधारण मल्टी-थ्रेडेड एप्लिकेशन के साथ एचडीएफएस से फाइलें पढ़ेंगे। पैरामीटर सेट करें:

conf.set("dfs.client.read.shortcircuit", "true");
conf.set("dfs.client.read.shortcircuit.buffer.size", "65536"); // по дефолту = 1 МБ и это сильно замедляет чтение, поэтому лучше привести в соответствие к реальным нуждам
conf.set("dfs.client.short.circuit.num", num); // от 1 до 10

और बस फ़ाइलें पढ़ें:

FSDataInputStream in = fileSystem.open(path);
for (int i = 0; i < count; i++) {
    position += 65536;
    if (position > 900000000)
        position = 0L;
    int res = in.read(position, byteBuffer, 0, 65536);
}

इस कोड को अलग-अलग थ्रेड में निष्पादित किया जाता है और हम एक साथ पढ़ी जाने वाली फ़ाइलों की संख्या (10 से 200 - क्षैतिज अक्ष) और कैश की संख्या (1 से 10 - ग्राफ़िक्स) बढ़ा देंगे। ऊर्ध्वाधर अक्ष उस त्वरण को दर्शाता है जो केवल एक कैश होने पर मामले के सापेक्ष एसएससी में वृद्धि के परिणामस्वरूप होता है।

ग्राफ़ कैसे पढ़ें: एक कैश के साथ 100 केबी ब्लॉक में 64 हजार रीड्स के निष्पादन समय के लिए 78 सेकंड की आवश्यकता होती है। जबकि 5 कैश के साथ इसमें 16 सेकंड का समय लगता है। वे। ~5 गुना त्वरण है। जैसा कि ग्राफ से देखा जा सकता है, समानांतर रीड्स की एक छोटी संख्या के लिए प्रभाव बहुत ध्यान देने योग्य नहीं है; यह 50 से अधिक थ्रेड रीड्स होने पर ध्यान देने योग्य भूमिका निभाना शुरू कर देता है। यह भी ध्यान देने योग्य है कि एसएससी की संख्या 6 से बढ़ रही है और इससे ऊपर काफी कम प्रदर्शन वृद्धि मिलती है।

नोट 1: चूंकि परीक्षण के परिणाम काफी अस्थिर हैं (नीचे देखें), 3 रन किए गए और परिणामी मान औसत किए गए।

नोट 2: रैंडम एक्सेस को कॉन्फ़िगर करने से प्रदर्शन लाभ समान है, हालांकि एक्सेस स्वयं थोड़ा धीमा है।

हालाँकि, यह स्पष्ट करना आवश्यक है कि, HBase के मामले के विपरीत, यह त्वरण हमेशा मुफ़्त नहीं होता है। यहां हम ताले पर लटकने के बजाय सीपीयू की अधिक काम करने की क्षमता को "अनलॉक" करते हैं।

यहां आप देख सकते हैं कि, सामान्य तौर पर, कैश की संख्या में वृद्धि सीपीयू उपयोग में लगभग आनुपातिक वृद्धि देती है। हालाँकि, जीतने वाले संयोजन थोड़े अधिक हैं।

उदाहरण के लिए, आइए सेटिंग एसएससी = 3 पर करीब से नज़र डालें। रेंज पर प्रदर्शन में वृद्धि लगभग 3.3 गुना है। तीनों अलग-अलग रन के परिणाम नीचे दिए गए हैं।

जबकि सीपीयू की खपत लगभग 2.8 गुना बढ़ जाती है। अंतर बहुत बड़ा नहीं है, लेकिन छोटी ग्रेटा पहले से ही खुश है और उसके पास स्कूल जाने और सबक लेने का समय हो सकता है।

इस प्रकार, इसका किसी भी उपकरण के लिए सकारात्मक प्रभाव पड़ेगा जो एचडीएफएस (उदाहरण के लिए स्पार्क इत्यादि) तक थोक पहुंच का उपयोग करता है, बशर्ते कि एप्लिकेशन कोड हल्का हो (यानी प्लग एचडीएफएस क्लाइंट साइड पर हो) और मुफ्त सीपीयू पावर हो . जाँचने के लिए, आइए परीक्षण करें कि HBase से पढ़ने के लिए ब्लॉक कैश ऑप्टिमाइज़ेशन और SSC ट्यूनिंग के संयुक्त उपयोग का क्या प्रभाव पड़ेगा।

यह देखा जा सकता है कि ऐसी परिस्थितियों में प्रभाव परिष्कृत परीक्षणों (बिना किसी प्रसंस्करण के पढ़ना) जितना महान नहीं है, लेकिन यहां अतिरिक्त 80K निचोड़ना काफी संभव है। एक साथ, दोनों अनुकूलन 4x तक स्पीडअप प्रदान करते हैं।

इस अनुकूलन के लिए एक पीआर भी बनाया गया था [एचडीएफएस-15202], जिसे विलय कर दिया गया है और यह कार्यक्षमता भविष्य के रिलीज़ में उपलब्ध होगी।

और अंत में, समान वाइड-कॉलम डेटाबेस, कैसेंड्रा और HBase के पढ़ने के प्रदर्शन की तुलना करना दिलचस्प था।

ऐसा करने के लिए, हमने दो होस्ट (कुल 800 थ्रेड) से मानक YCSB लोड परीक्षण उपयोगिता के उदाहरण लॉन्च किए। सर्वर साइड पर - 4 होस्ट पर रीजनसर्वर और कैसेंड्रा के 4 इंस्टेंस (वे नहीं जहां क्लाइंट चल रहे हैं, उनके प्रभाव से बचने के लिए)। आकार की तालिकाओं से रीडिंग आई:

HBase - एचडीएफएस पर 300 जीबी (100 जीबी शुद्ध डेटा)

कैसेंड्रा - 250 जीबी (प्रतिकृति कारक = 3)

वे। वॉल्यूम लगभग समान था (HBase में थोड़ा अधिक)।

एचबेस पैरामीटर:

dfs.client.short.circuit.num = 5 (एचडीएफएस क्लाइंट अनुकूलन)

hbase.lru.cache.heavy.eviction.count.limit = 30 - इसका मतलब है कि पैच 30 निष्कासन (~5 मिनट) के बाद काम करना शुरू कर देगा

hbase.lru.cache.heavy.eviction.mb.size.limit = 300 - कैशिंग और निष्कासन की लक्ष्य मात्रा

YCSB लॉग को पार्स किया गया और एक्सेल ग्राफ़ में संकलित किया गया:

जैसा कि आप देख सकते हैं, ये अनुकूलन इन परिस्थितियों में इन डेटाबेस के प्रदर्शन की तुलना करना और प्रति सेकंड 450 हजार रीड्स हासिल करना संभव बनाते हैं।

हमें उम्मीद है कि उत्पादकता के रोमांचक संघर्ष के दौरान यह जानकारी किसी के लिए उपयोगी हो सकती है।

स्रोत: www.habr.com

HBase से 3 गुना और HDFS से 5 गुना तक पढ़ने की गति कैसे बढ़ाएं

एक टिप्पणी जोड़ें उत्तर रद्द