🥇HBase वरून 3 पट आणि HDFS वरून 5 पट पर्यंत वाचन गती कशी वाढवायची

मोठ्या डेटासह कार्य करताना उच्च कार्यप्रदर्शन ही प्रमुख आवश्यकतांपैकी एक आहे. Sberbank मधील डेटा लोडिंग विभागात, आम्ही आमच्या Hadoop-आधारित डेटा क्लाउडमध्ये जवळजवळ सर्व व्यवहार पंप करतो आणि त्यामुळे माहितीच्या मोठ्या प्रवाहाला सामोरे जातो. साहजिकच, आम्ही नेहमी कार्यप्रदर्शन सुधारण्याचे मार्ग शोधत असतो आणि आता आम्ही तुम्हाला सांगू इच्छितो की आम्ही RegionServer HBase आणि HDFS क्लायंट कसे पॅच केले, ज्यामुळे आम्ही वाचन ऑपरेशन्सची गती लक्षणीयरीत्या वाढवू शकलो.

तथापि, सुधारणांच्या साराकडे जाण्यापूर्वी, आपण एचडीडीवर बसल्यास, तत्त्वतः, टाळता येणार नाही अशा निर्बंधांबद्दल बोलणे योग्य आहे.

HDD आणि जलद यादृच्छिक प्रवेश वाचन विसंगत का आहेत
तुम्हाला माहिती आहेच, HBase आणि इतर अनेक डेटाबेस, अनेक दहा किलोबाइट आकाराच्या ब्लॉक्समध्ये डेटा साठवतात. डीफॉल्टनुसार ते सुमारे 64 KB आहे. आता कल्पना करूया की आपल्याला फक्त 100 बाइट्स मिळणे आवश्यक आहे आणि आम्ही HBase ला विशिष्ट की वापरून हा डेटा देण्यास सांगू. HFiles मधील ब्लॉक आकार 64 KB असल्याने, विनंती आवश्यकतेपेक्षा 640 पट मोठी (फक्त एक मिनिट!) असेल.

पुढे, विनंती HDFS आणि त्याच्या मेटाडेटा कॅशिंग यंत्रणेद्वारे जाईल शॉर्ट सर्किट कॅशे (जे फायलींमध्ये थेट प्रवेश करण्यास अनुमती देते), यामुळे डिस्कवरून आधीच 1 MB वाचले जाते. तथापि, हे पॅरामीटरसह समायोजित केले जाऊ शकते dfs.client.read.shortcircuit.buffer.size आणि बर्याच बाबतीत हे मूल्य कमी करणे अर्थपूर्ण आहे, उदाहरणार्थ 126 KB.

समजा की आम्ही हे करतो, परंतु याशिवाय, जेव्हा आम्ही Java api द्वारे डेटा वाचण्यास सुरुवात करतो, जसे की FileChannel.read सारख्या फंक्शन्स आणि ऑपरेटिंग सिस्टमला निर्दिष्ट प्रमाणात डेटा वाचण्यास सांगते, तेव्हा ते "केवळ बाबतीत" 2 पट अधिक वाचते. , म्हणजे आमच्या बाबतीत 256 KB. कारण हे वर्तन रोखण्यासाठी जावाकडे FADV_RANDOM ध्वज सेट करण्याचा सोपा मार्ग नाही.

परिणामी, आमचे 100 बाइट्स मिळविण्यासाठी, हुड अंतर्गत 2600 पट अधिक वाचले जाते. असे दिसते की उपाय स्पष्ट आहे, चला ब्लॉकचा आकार किलोबाइटपर्यंत कमी करूया, उल्लेखित ध्वज सेट करूया आणि उत्कृष्ट प्रबोधन प्रवेग प्राप्त करूया. परंतु अडचण अशी आहे की ब्लॉकचा आकार 2 पट कमी करून, आम्ही वेळेच्या प्रति युनिट वाचलेल्या बाइट्सची संख्या 2 पट कमी करतो.

FADV_RANDOM ध्वज सेट करण्यापासून काही नफा मिळू शकतो, परंतु केवळ उच्च मल्टी-थ्रेडिंगसह आणि 128 KB ब्लॉक आकारासह, परंतु हे जास्तीत जास्त दहा टक्के आहे:

100 फायलींवर चाचण्या केल्या गेल्या, प्रत्येक 1 GB आकाराचा आणि 10 HDD वर स्थित आहे.

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

निराशाजनक, नाही का? तो निसर्ग आहे यादृच्छिक प्रवेश एचडीडीवरील डेटामध्ये प्रवेश - ब्लॉक आकाराकडे दुर्लक्ष करून. ही यादृच्छिक प्रवेशाची भौतिक मर्यादा आहे आणि अशा परिस्थितीत कोणताही डेटाबेस अधिक पिळून काढू शकत नाही.

मग डेटाबेस जास्त गती कशी मिळवतात? या प्रश्नाचे उत्तर देण्यासाठी, खालील चित्रात काय घडत आहे ते पाहूया:

येथे आपण पाहतो की पहिल्या काही मिनिटांसाठी वेग खरोखर प्रति सेकंद एक हजार रेकॉर्ड आहे. तथापि, पुढे, विनंती केल्यापेक्षा बरेच काही वाचले गेल्यामुळे, ऑपरेटिंग सिस्टम (लिनक्स) च्या बफ/कॅशेमध्ये डेटा संपतो आणि वेग अधिक सभ्य 60 हजार प्रति सेकंद इतका वाढतो.

अशाप्रकारे, पुढे आम्ही केवळ OS कॅशेमध्ये असलेल्या किंवा तुलनात्मक ऍक्सेस स्पीडच्या SSD/NVMe स्टोरेज डिव्हाइसेसमध्ये असलेल्या डेटावर ऍक्सेलरिंग ऍक्सेस हाताळू.

आमच्या बाबतीत, आम्ही 4 सर्व्हरच्या खंडपीठावर चाचण्या घेऊ, ज्यापैकी प्रत्येकासाठी खालीलप्रमाणे शुल्क आकारले जाते:

CPU: Xeon E5-2680 v4 @ 2.40GHz 64 थ्रेड्स.
मेमरी: 730 GB.
java आवृत्ती: 1.8.0_111

आणि येथे मुख्य मुद्दा म्हणजे टेबलमधील डेटाचे प्रमाण वाचणे आवश्यक आहे. वस्तुस्थिती अशी आहे की जर तुम्ही संपूर्णपणे HBase कॅशेमध्ये ठेवलेल्या टेबलमधील डेटा वाचला, तर तो ऑपरेटिंग सिस्टमच्या बफ/कॅशेमधून वाचायलाही येणार नाही. कारण HBase बाय डीफॉल्ट 40% मेमरी ब्लॉककॅच नावाच्या स्ट्रक्चरला वाटप करते. मूलत: हा ConcurrentHashMap आहे, जेथे की फाइल नाव + ब्लॉकचे ऑफसेट आहे आणि मूल्य या ऑफसेटमधील वास्तविक डेटा आहे.

अशा प्रकारे, केवळ या संरचनेतून वाचताना, आम्ही आम्ही उत्कृष्ट वेग पाहतो, प्रति सेकंद दशलक्ष विनंत्यांप्रमाणे. परंतु आपण कल्पना करूया की आपण शेकडो गीगाबाइट्स मेमरी फक्त डेटाबेसच्या गरजेसाठी देऊ शकत नाही, कारण या सर्व्हरवर इतर अनेक उपयुक्त गोष्टी चालू आहेत.

उदाहरणार्थ, आमच्या बाबतीत, एका आरएसवर ब्लॉककॅशची मात्रा सुमारे 12 जीबी आहे. आम्ही एका नोडवर दोन आरएस उतरवले, म्हणजे. सर्व नोड्सवर ब्लॉककॅशसाठी 96 GB वाटप केले आहे. आणि अनेक पट जास्त डेटा आहे, उदाहरणार्थ, ते 4 टेबल्स असू द्या, प्रत्येकी 130 प्रदेश, ज्यामध्ये फायली 800 MB आकाराच्या आहेत, FAST_DIFF द्वारे संकुचित केल्या आहेत, म्हणजे. एकूण 410 GB (हा शुद्ध डेटा आहे, म्हणजे प्रतिकृती घटक विचारात न घेता).

अशा प्रकारे, BlockCache एकूण डेटा व्हॉल्यूमच्या केवळ 23% आहे आणि हे बिगडेटा म्हटल्या जाणार्‍या वास्तविक परिस्थितीच्या अगदी जवळ आहे. आणि येथूनच मजा सुरू होते - कारण स्पष्टपणे, कमी कॅशे हिट, कामगिरी तितकी वाईट. शेवटी, जर तुम्ही चुकलो तर तुम्हाला खूप काम करावे लागेल - म्हणजे. कॉलिंग सिस्टम फंक्शन्स वर जा. तथापि, हे टाळले जाऊ शकत नाही, तर चला पूर्णपणे भिन्न पैलू पाहू - कॅशेमधील डेटाचे काय होते?

चला परिस्थिती सोपी करू आणि असे गृहीत धरू की आपल्याकडे एक कॅशे आहे जी फक्त 1 ऑब्जेक्टला बसते. जेव्हा आपण कॅशेपेक्षा 3 पट मोठ्या डेटा व्हॉल्यूमसह कार्य करण्याचा प्रयत्न करतो तेव्हा काय होईल याचे एक उदाहरण येथे आहे, आपल्याला हे करावे लागेल:

1. कॅशेमध्ये ब्लॉक 1 ठेवा
2. कॅशेमधून ब्लॉक 1 काढा
3. कॅशेमध्ये ब्लॉक 2 ठेवा
4. कॅशेमधून ब्लॉक 2 काढा
5. कॅशेमध्ये ब्लॉक 3 ठेवा

5 क्रिया पूर्ण झाल्या! तथापि, ही परिस्थिती सामान्य म्हणता येणार नाही; खरं तर, आम्ही HBase ला पूर्णपणे निरुपयोगी काम करण्यास भाग पाडत आहोत. ते सतत OS कॅशे मधील डेटा वाचते, तो BlockCache मध्ये ठेवते, फक्त तो जवळजवळ लगेच बाहेर टाकण्यासाठी कारण डेटाचा एक नवीन भाग आला आहे. पोस्टच्या सुरुवातीला अॅनिमेशन समस्येचे सार दर्शविते - कचरा कलेक्टर मोठ्या प्रमाणावर जात आहे, वातावरण तापत आहे, दूरच्या आणि गरम स्वीडनमधील छोटी ग्रेटा अस्वस्थ होत आहे. आणि आम्ही IT लोकांना जेव्हा मुले दुःखी असतात तेव्हा ते खरोखर आवडत नाही, म्हणून आम्ही त्याबद्दल काय करू शकतो याचा विचार करू लागतो.

जर तुम्ही सर्व ब्लॉक्स कॅशेमध्ये ठेवले नाहीत तर त्यातील काही टक्केच ठेवल्यास, जेणेकरून कॅशे ओव्हरफ्लो होणार नाही? 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 संसाधने वाचवतो फक्त तो ताबडतोब मंगळाच्या कुत्र्यांच्या नाल्यात टाकण्यासाठी:

त्याच वेळी, CPU वापर वाढतो, परंतु उत्पादकतेपेक्षा खूपच कमी आहे:

हे देखील लक्षात घेण्यासारखे आहे की 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 MB सेट करणे इष्टतम आहे. मध्यमवर्गीयांसाठी (~10 कोर) 200-300 MB. कमकुवत प्रणालींसाठी (2-5 कोर) 50-100 MB सामान्य असू शकतात (यावर चाचणी केली जात नाही).

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

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

जर खरेतर 2000 MB निष्कासित केले असेल, तर ओव्हरहेड बरोबर आहे:

2000 * 100 / 500 - 100 = 300%

अल्गोरिदम काही दहा टक्क्यांपेक्षा जास्त राखण्याचा प्रयत्न करतात, त्यामुळे वैशिष्ट्य कॅशे केलेल्या ब्लॉक्सची टक्केवारी कमी करेल, ज्यामुळे स्वयं-ट्यूनिंग यंत्रणा लागू होईल.

तथापि, लोड कमी झाल्यास, समजा फक्त 200 MB बाहेर काढले जातात आणि ओव्हरहेड नकारात्मक होते (तथाकथित ओव्हरशूटिंग):

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 पुन्हा अधिक ब्लॉक्स कॅशे करते.

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

पूर्ण कोड पुल विनंती मध्ये आढळू शकतो HBASE 23887 github वर.

तथापि, या परिस्थितीत या हार्डवेअरवर 300 हजार वाचन प्रति सेकंद एवढेच साध्य करता येत नाही. वस्तुस्थिती अशी आहे की जेव्हा तुम्हाला HDFS द्वारे डेटा ऍक्सेस करण्याची आवश्यकता असते तेव्हा शॉर्ट सर्किट कॅश (यापुढे 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 पेक्षा जास्त थ्रेड रीड्स असतात तेव्हा तो लक्षणीय भूमिका बजावू लागतो. हे देखील लक्षात येते की एसएससीची संख्या 6 वरून वाढवणे आणि वरील एक लक्षणीय लहान कामगिरी वाढ देते.

टीप 1: चाचणी परिणाम खूपच अस्थिर असल्याने (खाली पहा), 3 धावा केल्या गेल्या आणि परिणामी मूल्यांची सरासरी काढली गेली.

टीप 2: यादृच्छिक प्रवेश कॉन्फिगर केल्याने होणारा कार्यप्रदर्शन लाभ समान आहे, जरी प्रवेश स्वतःच थोडा कमी आहे.

तथापि, हे स्पष्ट करणे आवश्यक आहे की, HBase च्या बाबतीत विपरीत, हे प्रवेग नेहमीच विनामूल्य नसते. येथे आम्ही CPU ची लॉक्सवर टांगण्याऐवजी अधिक कार्य करण्याची क्षमता "अनलॉक" करतो.

येथे तुम्ही हे पाहू शकता की, सर्वसाधारणपणे, कॅशेच्या संख्येत वाढ केल्याने CPU वापरामध्ये अंदाजे प्रमाणात वाढ होते. तथापि, थोडे अधिक विजयी जोड्या आहेत.

उदाहरणार्थ, SSC = 3 सेटिंग जवळून पाहू या. श्रेणीवरील कार्यक्षमतेत वाढ सुमारे 3.3 पट आहे. खाली सर्व तीन स्वतंत्र धावांचे परिणाम आहेत.

तर CPU वापर सुमारे 2.8 पटीने वाढतो. फरक फार मोठा नाही, परंतु लहान ग्रेटा आधीच आनंदी आहे आणि तिला शाळेत जाण्यासाठी आणि धडे घेण्यासाठी वेळ असू शकतो.

अशाप्रकारे, एचडीएफएस (उदाहरणार्थ स्पार्क इ.) मध्ये मोठ्या प्रमाणात प्रवेश वापरणाऱ्या कोणत्याही साधनासाठी याचा सकारात्मक परिणाम होईल, बशर्ते अॅप्लिकेशन कोड हलका असेल (म्हणजे प्लग एचडीएफएस क्लायंटच्या बाजूला असेल) आणि विनामूल्य CPU पॉवर असेल. . तपासण्यासाठी, HBase वरून वाचण्यासाठी BlockCache ऑप्टिमायझेशन आणि SSC ट्यूनिंगचा एकत्रित वापर काय परिणाम करेल हे तपासू.

हे पाहिले जाऊ शकते की अशा परिस्थितीत परिणाम परिष्कृत चाचण्यांइतका महान नाही (कोणत्याही प्रक्रियेशिवाय वाचन), परंतु येथे अतिरिक्त 80K पिळून काढणे शक्य आहे. एकत्रितपणे, दोन्ही ऑप्टिमायझेशन 4x स्पीडअप प्रदान करतात.

या ऑप्टिमायझेशनसाठी एक पीआर देखील बनविला गेला [HDFS-15202], जे विलीन केले गेले आहे आणि ही कार्यक्षमता भविष्यातील प्रकाशनांमध्ये उपलब्ध असेल.

आणि शेवटी, समान वाइड-कॉलम डेटाबेस, कॅसॅन्ड्रा आणि एचबेसच्या वाचन कामगिरीची तुलना करणे मनोरंजक होते.

हे करण्यासाठी, आम्ही दोन होस्ट (एकूण 800 थ्रेड) कडून मानक YCSB लोड चाचणी युटिलिटीची उदाहरणे लाँच केली. सर्व्हरच्या बाजूला - 4 होस्टवर RegionServer आणि Cassandra ची 4 उदाहरणे (जिथे क्लायंट चालू आहेत, त्यांचा प्रभाव टाळण्यासाठी नाही). आकाराच्या सारण्यांमधून वाचन आले:

HBase - HDFS वर 300 GB (100 GB शुद्ध डेटा)

Cassandra - 250 GB (प्रतिकृती घटक = 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

HBase वरून 3 पट आणि HDFS वरून 5 पट पर्यंत वाचन गती कशी वाढवायची

एक टिप्पणी जोडा Отменить ответ