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

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


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

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

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

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

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

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

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

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

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

तो फिर ये बेस इतनी ज़्यादा गति कैसे प्राप्त कर लेते हैं? इस प्रश्न का उत्तर जानने के लिए, आइए नीचे दी गई तस्वीर में देखें कि क्या हो रहा है:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

उदाहरण के लिए, आइए cacheDataBlockPercent = 20 सेट करें और देखें कि क्या होता है:

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

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

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

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

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

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

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

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

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;
       }

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

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

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

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

क्षेत्र सर्वर लॉग
बेदखल (MB): 0, अनुपात 0.0, ओवरहेड (%): -100, भारी बेदखली काउंटर: 0, वर्तमान कैशिंग डेटाब्लॉक (%): 100
बेदखल (MB): 0, अनुपात 0.0, ओवरहेड (%): -100, भारी बेदखली काउंटर: 0, वर्तमान कैशिंग डेटाब्लॉक (%): 100
बेदखल (MB): 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
बेदखल (MB): 21, अनुपात 0.33, ओवरहेड (%): -90, भारी बेदखली काउंटर: 76, वर्तमान कैशिंग डेटाब्लॉक (%): 32
बेदखल (MB): 0, अनुपात 0.0, ओवरहेड (%): -100, भारी बेदखली काउंटर: 0, वर्तमान कैशिंग डेटाब्लॉक (%): 100
बेदखल (MB): 0, अनुपात 0.0, ओवरहेड (%): -100, भारी बेदखली काउंटर: 0, वर्तमान कैशिंग डेटाब्लॉक (%): 100

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

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

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

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

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

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

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)];
}

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

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 तक) बढ़ाएँगे। ऊर्ध्वाधर अक्ष उस गति में वृद्धि दर्शाता है जो SSC में वृद्धि से उस स्थिति की तुलना में प्राप्त होती है जब केवल एक कैश होता है।

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

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

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

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

यहाँ हम देख सकते हैं कि सामान्य तौर पर, कैश की संख्या बढ़ाने से CPU उपयोग में लगभग समानुपातिक वृद्धि होती है। हालाँकि, कुछ और भी लाभप्रद संयोजन हैं।

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

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

इस प्रकार, HDFS तक मास एक्सेस का उपयोग करने वाले किसी भी टूल (उदाहरण के लिए, स्पार्क, आदि) पर इसका सकारात्मक प्रभाव पड़ेगा, बशर्ते कि एप्लिकेशन कोड हल्का हो (अर्थात बाधा HDFS क्लाइंट साइड पर हो) और CPU पावर उपलब्ध हो। जाँच करने के लिए, आइए देखें कि HBase से रीडिंग के लिए BlockCache ऑप्टिमाइज़ेशन और SSC ट्यूनिंग के संयुक्त उपयोग से क्या प्रभाव पड़ेगा।

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

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

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

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

HBase - HDFS पर 300 GB (100 GB स्वच्छ डेटा)

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

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

HBase पैरामीटर:

dfs.client.short.circuit.num = 5 (HDFS क्लाइंट अनुकूलन)

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

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

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

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

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

स्रोत: www.habr.com