របៀបបង្កើនល្បឿនអានពី HBase ដល់ទៅ 3 ដង និងពី HDFS ដល់ 5 ដង

ការអនុវត្តខ្ពស់គឺជាតម្រូវការសំខាន់មួយនៅពេលធ្វើការជាមួយទិន្នន័យធំ។ នៅក្នុងផ្នែកផ្ទុកទិន្នន័យនៅ Sberbank យើងបូមប្រតិបត្តិការស្ទើរតែទាំងអស់ចូលទៅក្នុង Data Cloud ដែលមានមូលដ្ឋានលើ Hadoop របស់យើង ហើយដូច្នេះដោះស្រាយជាមួយនឹងលំហូរព័ត៌មានដ៏ធំ។ ជាធម្មជាតិ យើងតែងតែស្វែងរកមធ្យោបាយដើម្បីកែលម្អការអនុវត្ត ហើយឥឡូវនេះយើងចង់ប្រាប់អ្នកពីរបៀបដែលយើងគ្រប់គ្រងដើម្បីជួសជុល RegionServer HBase និងម៉ាស៊ីនភ្ញៀវ HDFS អរគុណដែលយើងអាចបង្កើនល្បឿននៃការអានយ៉ាងសំខាន់។


ទោះយ៉ាងណាក៏ដោយ មុននឹងបន្តទៅចំណុចសំខាន់នៃការកែលម្អ វាមានតម្លៃនិយាយអំពីការរឹតបន្តឹង ដែលតាមគោលការណ៍មិនអាចជៀសបាន ប្រសិនបើអ្នកអង្គុយលើ HDD។

ហេតុអ្វីបានជា HDD និងការអាន Random Access លឿនមិនឆបគ្នា។
ដូចដែលអ្នកបានដឹងហើយថា HBase និងមូលដ្ឋានទិន្នន័យជាច្រើនទៀត រក្សាទុកទិន្នន័យនៅក្នុងប្លុកដែលមានទំហំរាប់សិបគីឡូបៃ។ តាមលំនាំដើមវាមានប្រហែល 64 KB ។ ឥឡូវនេះសូមស្រមៃថាយើងត្រូវទទួលបានត្រឹមតែ 100 បៃ ហើយយើងសុំឱ្យ HBase ផ្តល់ឱ្យយើងនូវទិន្នន័យនេះដោយប្រើសោជាក់លាក់។ ដោយសារទំហំប្លុកនៅក្នុង HFiles គឺ 64 KB សំណើនឹងមានទំហំធំជាង 640 ដង (ត្រឹមតែមួយនាទី!) ជាងការចាំបាច់។

បន្ទាប់ ចាប់តាំងពីសំណើនឹងឆ្លងកាត់ HDFS និងយន្តការផ្ទុកទិន្នន័យមេតារបស់វា។ ShortCircuitCache (ដែលអនុញ្ញាតឱ្យចូលប្រើឯកសារដោយផ្ទាល់) វានាំទៅដល់ការអាន 1 MB រួចហើយពីថាស។ ទោះជាយ៉ាងណាក៏ដោយនេះអាចត្រូវបានកែតម្រូវជាមួយនឹងប៉ារ៉ាម៉ែត្រ dfs.client.read.shortcircuit.buffer.size ហើយក្នុងករណីជាច្រើនវាសមហេតុផលក្នុងការកាត់បន្ថយតម្លៃនេះ ឧទាហរណ៍ទៅ 126 KB ។

ឧបមាថាយើងធ្វើបែបនេះ ប៉ុន្តែលើសពីនេះទៅទៀត នៅពេលដែលយើងចាប់ផ្តើមអានទិន្នន័យតាមរយៈ java api ដូចជាមុខងារដូចជា FileChannel.read ហើយសុំឱ្យប្រព័ន្ធប្រតិបត្តិការអានចំនួនទិន្នន័យដែលបានបញ្ជាក់ វាអាន "គ្រាន់តែក្នុងករណី" 2 ដងបន្ថែមទៀត។ , i.e. 256 KB ក្នុងករណីរបស់យើង។ នេះគឺដោយសារតែ java មិនមានវិធីងាយស្រួលក្នុងការកំណត់ទង់ FADV_RANDOM ដើម្បីការពារឥរិយាបថនេះ។

ជាលទ្ធផល ដើម្បីទទួលបាន 100 បៃរបស់យើង 2600 ដងទៀតត្រូវបានអាននៅក្រោមក្រណាត់។ វាហាក់ដូចជាថាដំណោះស្រាយគឺជាក់ស្តែង ចូរយើងកាត់បន្ថយទំហំប្លុកទៅជាគីឡូបៃ កំណត់ទង់ដែលបានរៀបរាប់ និងទទួលបានការពន្លឿនការត្រាស់ដឹងដ៏អស្ចារ្យ។ ប៉ុន្តែបញ្ហាគឺថាដោយកាត់បន្ថយទំហំប្លុក 2 ដងយើងក៏កាត់បន្ថយចំនួនបៃដែលអានក្នុងមួយឯកតានៃពេលវេលា 2 ដង។

ប្រាក់ចំណេញមួយចំនួនពីការកំណត់ទង់ FADV_RANDOM អាចទទួលបាន ប៉ុន្តែមានតែជាមួយខ្សែច្រើនខ្ពស់ និងទំហំប្លុក 128 KB ប៉ុន្តែនេះគឺជាអតិបរមាពីរបីដប់ភាគរយ៖

ការធ្វើតេស្តត្រូវបានអនុវត្តលើឯកសារ 100 ដែលនីមួយៗមានទំហំ 1 GB និងមានទីតាំងនៅលើ HDD ចំនួន 10 ។

ចូរយើងគណនាអ្វីដែលយើងអាចធ្វើបាន ជាគោលការណ៍ ពឹងផ្អែកលើល្បឿននេះ៖
ឧបមាថាយើងអានពី 10 ថាសក្នុងល្បឿន 280 MB/sec, i.e. 3 លានដង 100 បៃ។ ប៉ុន្តែដូចដែលយើងចងចាំ ទិន្នន័យដែលយើងត្រូវការគឺ 2600 ដងតិចជាងអ្វីដែលបានអាន។ ដូច្នេះយើងបែងចែក 3 លានដោយ 2600 ហើយទទួលបាន 1100 កំណត់ត្រាក្នុងមួយវិនាទី។

បាក់ទឹកចិត្តមែនទេ? នោះជាធម្មជាតិ ការចូលប្រើដោយចៃដន្យ ការចូលប្រើទិន្នន័យនៅលើ HDD - ដោយមិនគិតពីទំហំប្លុក។ នេះគឺជាដែនកំណត់ជាក់ស្តែងនៃការចូលប្រើដោយចៃដន្យ ហើយគ្មានមូលដ្ឋានទិន្នន័យណាមួយអាចច្របាច់ចេញបន្ថែមទៀតនៅក្រោមលក្ខខណ្ឌបែបនេះទេ។

ដូច្នេះតើ Databases ទទួលបានល្បឿនខ្ពស់ជាងនេះដោយរបៀបណា? ដើម្បី​ឆ្លើយ​នឹង​សំណួរ​នេះ សូម​មើល​ថា​មាន​អ្វី​កើត​ឡើង​ក្នុង​រូបភាព​ខាង​ក្រោម៖

នៅទីនេះយើងឃើញថាសម្រាប់ប៉ុន្មាននាទីដំបូង ល្បឿនពិតជាប្រហែលមួយពាន់កំណត់ត្រាក្នុងមួយវិនាទី។ ទោះយ៉ាងណាក៏ដោយបន្ថែមទៀតដោយសារតែការពិតដែលថាត្រូវបានអានច្រើនជាងការស្នើសុំទិន្នន័យបញ្ចប់នៅក្នុង buff / cache នៃប្រព័ន្ធប្រតិបត្តិការ (linux) ហើយល្បឿនកើនឡើងដល់សមរម្យជាង 60 ពាន់ក្នុងមួយវិនាទី។

ដូច្នេះ យើងនឹងដោះស្រាយជាមួយការបង្កើនល្បឿនចូលប្រើតែទិន្នន័យដែលមាននៅក្នុងឃ្លាំងសម្ងាត់ OS ឬស្ថិតនៅក្នុងឧបករណ៍ផ្ទុក SSD/NVMe នៃល្បឿនចូលដំណើរការដែលអាចប្រៀបធៀបបាន។

ក្នុងករណីរបស់យើង យើងនឹងធ្វើការសាកល្បងលើម៉ាស៊ីនមេចំនួន 4 ដែលនីមួយៗត្រូវបានគិតប្រាក់ដូចខាងក្រោម៖

ស៊ីភីយូ៖ Xeon E5-2680 v4 @ 2.40GHz 64 ខ្សែ។
អង្គចងចាំ៖ ៧៣០ ជីកាបៃ។
កំណែ java៖ 1.8.0_111

ហើយនៅទីនេះចំណុចសំខាន់គឺចំនួនទិន្នន័យនៅក្នុងតារាងដែលត្រូវអាន។ ការពិតគឺថាប្រសិនបើអ្នកអានទិន្នន័យពីតារាងដែលត្រូវបានដាក់ទាំងស្រុងនៅក្នុងឃ្លាំងសម្ងាត់ HBase នោះវានឹងមិនមកអានពី buff/cache របស់ប្រព័ន្ធប្រតិបត្តិការនោះទេ។ ដោយសារតែ HBase តាមលំនាំដើមបែងចែក 40% នៃអង្គចងចាំទៅរចនាសម្ព័ន្ធហៅថា BlockCache ។ សំខាន់នេះគឺជា ConcurrentHashMap ដែលកូនសោគឺជាឈ្មោះឯកសារ + អុហ្វសិតនៃប្លុក ហើយតម្លៃគឺជាទិន្នន័យពិតប្រាកដនៅអុហ្វសិតនេះ។

ដូច្នេះនៅពេលអានតែពីរចនាសម្ព័ន្ធនេះយើង យើងឃើញល្បឿនដ៏អស្ចារ្យដូចជាសំណើមួយលានក្នុងមួយវិនាទី។ ប៉ុន្តែសូមស្រមៃថា យើងមិនអាចបែងចែកអង្គចងចាំរាប់រយជីហ្គាបៃសម្រាប់តែតម្រូវការមូលដ្ឋានទិន្នន័យបានទេ ពីព្រោះមានរបស់មានប្រយោជន៍ជាច្រើនទៀតដែលកំពុងដំណើរការលើម៉ាស៊ីនមេទាំងនេះ។

ឧទាហរណ៍ក្នុងករណីរបស់យើងបរិមាណ BlockCache នៅលើ RS មួយគឺប្រហែល 12 GB ។ យើងបានចុះចត RS ពីរនៅលើថ្នាំងមួយ, i.e. 96 GB ត្រូវបានបម្រុងទុកសម្រាប់ BlockCache នៅលើថ្នាំងទាំងអស់។ ហើយ​មាន​ទិន្នន័យ​ច្រើន​ដង​ទៀត ឧទាហរណ៍ ទុក​វា​ជា 4 តារាង 130 តំបន់​នីមួយៗ ដែល​ឯកសារ​មាន​ទំហំ 800 MB បង្រួម​ដោយ FAST_DIFF i.e. សរុប 410 GB (នេះគឺជាទិន្នន័យសុទ្ធ ពោលគឺដោយមិនគិតពីកត្តាចម្លង)។

ដូច្នេះ BlockCache មានត្រឹមតែប្រហែល 23% នៃបរិមាណទិន្នន័យសរុប ហើយនេះគឺកាន់តែខិតទៅជិតលក្ខខណ្ឌពិតនៃអ្វីដែលហៅថា BigData ។ ហើយនេះគឺជាកន្លែងដែលភាពសប្បាយរីករាយចាប់ផ្តើម - ដោយសារតែជាក់ស្តែង ការចូលមើលឃ្លាំងសម្ងាត់តិចជាងមុន ការសម្តែងកាន់តែអាក្រក់។ យ៉ាងណាមិញប្រសិនបើអ្នកនឹកអ្នកនឹងត្រូវធ្វើការងារជាច្រើន - i.e. ចុះទៅមុខងារប្រព័ន្ធហៅទូរសព្ទ។ ទោះជាយ៉ាងណាក៏ដោយ នេះមិនអាចជៀសវាងបានទេ ដូច្នេះសូមក្រឡេកមើលទិដ្ឋភាពខុសគ្នាទាំងស្រុង - តើមានអ្វីកើតឡើងចំពោះទិន្នន័យនៅក្នុងឃ្លាំងសម្ងាត់?

ចូរធ្វើឱ្យស្ថានភាពងាយស្រួល ហើយសន្មតថាយើងមានឃ្លាំងសម្ងាត់ដែលសមនឹងវត្ថុ 1 ប៉ុណ្ណោះ។ នេះគឺជាឧទាហរណ៍នៃអ្វីដែលនឹងកើតឡើងនៅពេលដែលយើងព្យាយាមធ្វើការជាមួយទំហំទិន្នន័យធំជាងឃ្លាំងសម្ងាត់ 3 ដង យើងនឹងត្រូវ៖

1. ដាក់ប្លុក 1 ក្នុងឃ្លាំងសម្ងាត់
2. យកប្លុក 1 ចេញពីឃ្លាំងសម្ងាត់
3. ដាក់ប្លុក 2 ក្នុងឃ្លាំងសម្ងាត់
4. យកប្លុក 2 ចេញពីឃ្លាំងសម្ងាត់
5. ដាក់ប្លុក 3 ក្នុងឃ្លាំងសម្ងាត់

សកម្មភាព​ទាំង​៥​ត្រូវ​បាន​បញ្ចប់! ទោះជាយ៉ាងណាក៏ដោយ ស្ថានភាពនេះមិនអាចត្រូវបានគេហៅថាធម្មតាទេ តាមពិតយើងកំពុងបង្ខំឱ្យ 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 ជាច្រើនដោយមិនធ្វើការងាររបស់ Sisyphean ក្នុងការដាក់ទិន្នន័យក្នុងឃ្លាំងសម្ងាត់ដើម្បីបោះវាចោលភ្លាមៗទៅលើសត្វឆ្កែ Martian៖

ក្នុងពេលជាមួយគ្នានេះ ការប្រើប្រាស់ CPU កើនឡើង ប៉ុន្តែតិចជាងផលិតភាពច្រើន៖

វាក៏គួរអោយកត់សំគាល់ផងដែរថាប្លុកដែលផ្ទុកនៅក្នុង BlockCache គឺខុសគ្នា។ ភាគច្រើនប្រហែល 95% គឺជាទិន្នន័យខ្លួនឯង។ ហើយនៅសល់គឺជាទិន្នន័យមេតា ដូចជាតម្រង Bloom ឬ LEAF_INDEX និង ល។. ទិន្នន័យនេះមិនគ្រប់គ្រាន់ទេ ប៉ុន្តែវាមានប្រយោជន៍ខ្លាំងណាស់ ពីព្រោះមុនពេលចូលប្រើទិន្នន័យដោយផ្ទាល់ HBase ងាកទៅរកមេតាដើម្បីស្វែងយល់ថាតើចាំបាច់ត្រូវស្វែងរកនៅទីនេះបន្ថែមទៀត ហើយប្រសិនបើដូច្នេះ តើប្លុកចំណាប់អារម្មណ៍ស្ថិតនៅត្រង់ណា។

ដូច្នេះនៅក្នុងកូដយើងឃើញលក្ខខណ្ឌត្រួតពិនិត្យ buf.getBlockType().isData() ហើយអរគុណចំពោះមេតានេះ យើងនឹងទុកវានៅក្នុងឃ្លាំងសម្ងាត់ក្នុងករណីណាក៏ដោយ។

ឥឡូវនេះ ចូរបង្កើនការផ្ទុក និងរឹតបន្តឹងមុខងារនេះបន្តិចក្នុងមួយលើក។ នៅក្នុងការធ្វើតេស្តដំបូង យើងបានធ្វើឱ្យភាគរយនៃការកាត់ចេញ = 20 ហើយ BlockCache ត្រូវបានគេប្រើប្រាស់តិចតួច។ ឥឡូវ​យើង​កំណត់​វា​ទៅ 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 និងធ្វើឱ្យមុខងារនេះដំណើរការភ្លាមៗបន្ទាប់ពីការបើកដំណើរការ។

ទោះយ៉ាងណាក៏ដោយក៏មាន payload នៅក្នុងប៉ារ៉ាម៉ែត្រនេះផងដែរ។ ប្រសិនបើបន្ទុករបស់យើងគឺដូចជាការអានរយៈពេលខ្លី (និយាយក្នុងអំឡុងពេលថ្ងៃ) និងការអានរយៈពេលវែង (នៅពេលយប់) ត្រូវបានលាយបញ្ចូលគ្នាឥតឈប់ឈរ នោះយើងអាចប្រាកដថាមុខងារនេះត្រូវបានបើកតែនៅពេលដែលប្រតិបត្តិការអានវែងកំពុងដំណើរការ។

ជាឧទាហរណ៍ យើងដឹងថាការអានរយៈពេលខ្លីជាធម្មតាមានរយៈពេលប្រហែល 1 នាទី។ មិនចាំបាច់ចាប់ផ្តើមបោះចោលប្លុកទេ ឃ្លាំងសម្ងាត់នឹងមិនមានពេលវេលាដើម្បីក្លាយជាហួសសម័យទេ ហើយបន្ទាប់មកយើងអាចកំណត់ប៉ារ៉ាម៉ែត្រនេះស្មើនឹងឧទាហរណ៍ 10. នេះនឹងនាំឱ្យការពិតដែលថាការបង្កើនប្រសិទ្ធភាពនឹងចាប់ផ្តើមដំណើរការតែនៅពេលដែលរយៈពេលយូរ - ការ​អាន​សកម្ម​ពាក្យ​បាន​ចាប់​ផ្តើ​ម, i.e. ក្នុង 100 វិនាទី។ ដូច្នេះប្រសិនបើយើងអានរយៈពេលខ្លី នោះប្លុកទាំងអស់នឹងចូលទៅក្នុងឃ្លាំងសម្ងាត់ ហើយនឹងមាន (លើកលែងតែអ្នកដែលនឹងត្រូវបានបណ្តេញចេញដោយក្បួនដោះស្រាយស្តង់ដារ)។ ហើយនៅពេលដែលយើងអានរយៈពេលវែង មុខងារនេះត្រូវបានបើក ហើយយើងនឹងមានដំណើរការខ្ពស់ជាងច្រើន។

hbase.lru.cache.heavy.eviction.mb.size.limit - កំណត់ចំនួនមេកាបៃដែលយើងចង់ដាក់ក្នុងឃ្លាំងសម្ងាត់ (ហើយជាការពិត បណ្តេញចេញ) ក្នុងរយៈពេល 10 វិនាទី។ មុខងារនេះនឹងព្យាយាមឈានដល់តម្លៃនេះហើយរក្សាវា។ ចំណុចគឺនេះ៖ ប្រសិនបើយើងរុញជីហ្គាបៃទៅក្នុងឃ្លាំងសម្ងាត់ នោះយើងនឹងត្រូវបណ្តេញចេញ ជីហ្គាបៃ ហើយនេះដូចដែលយើងបានឃើញខាងលើ គឺមានតម្លៃថ្លៃណាស់។ ទោះជាយ៉ាងណាក៏ដោយ អ្នកមិនគួរព្យាយាមកំណត់វាឱ្យតូចពេកទេ ព្រោះវានឹងធ្វើឱ្យរបៀបរំលងប្លុកចេញមុនអាយុ។ សម្រាប់ម៉ាស៊ីនមេដែលមានថាមពល (ប្រហែល 20-40 ស្នូលរាងកាយ) វាល្អបំផុតក្នុងការកំណត់ប្រហែល 300-400 មេកាបៃ។ សម្រាប់ថ្នាក់កណ្តាល (~10 cores) 200-300 MB ។ សម្រាប់ប្រព័ន្ធខ្សោយ (2-5 cores) 50-100 MB អាចជារឿងធម្មតា (មិនត្រូវបានសាកល្បងលើទាំងនេះទេ)។

សូមក្រឡេកមើលរបៀបដែលវាដំណើរការ៖ ឧបមាថាយើងកំណត់ hbase.lru.cache.heavy.eviction.mb.size.limit = 500 វាមានប្រភេទនៃការផ្ទុក (អាន) ហើយបន្ទាប់មករៀងរាល់ ~ 10 វិនាទីយើងគណនាចំនួនបៃ។ បណ្តេញចេញដោយប្រើរូបមន្ត៖

លើស = Freed Bytes Sum (MB) * 100 / Limit (MB) - 100;

ប្រសិនបើការពិត 2000 MB ត្រូវបានបណ្តេញចេញ នោះ Overhead គឺស្មើនឹង៖

2000 * 100 / 500 - 100 = 300%

ក្បួនដោះស្រាយព្យាយាមរក្សាមិនលើសពីពីរបីដប់ភាគរយ ដូច្នេះលក្ខណៈពិសេសនឹងកាត់បន្ថយភាគរយនៃប្លុកដែលបានរក្សាទុក ដោយហេតុនេះអនុវត្តយន្តការលៃតម្រូវដោយស្វ័យប្រវត្តិ។

ទោះយ៉ាងណាក៏ដោយ ប្រសិនបើការផ្ទុកធ្លាក់ចុះ ឧបមាថាមានតែ 200 MB ប៉ុណ្ណោះដែលត្រូវបានបណ្តេញចេញ ហើយ Overhead ក្លាយជាអវិជ្ជមាន (ហៅថាការលើសទម្ងន់):

200 * 100 / 500 - 100 = -60%

ផ្ទុយទៅវិញ មុខងារនេះនឹងបង្កើនភាគរយនៃប្លុកឃ្លាំងសម្ងាត់រហូតដល់ Overhead ក្លាយជាវិជ្ជមាន។

ខាងក្រោមនេះគឺជាឧទាហរណ៍នៃរបៀបដែលវាមើលទៅលើទិន្នន័យពិត។ មិនចាំបាច់ព្យាយាមឈានដល់ 0% វាមិនអាចទៅរួចទេ។ វាល្អណាស់នៅពេលដែលវាមានប្រហែល 30 - 100% វាជួយជៀសវាងការចាកចេញមុនអាយុពីរបៀបបង្កើនប្រសិទ្ធភាពអំឡុងពេលមានការកើនឡើងរយៈពេលខ្លី។

hbase.lru.cache.heavy.eviction.overhead.coefficient — កំណត់ថាតើយើងចង់ទទួលបានលទ្ធផលលឿនប៉ុណ្ណា។ ប្រសិនបើយើងដឹងច្បាស់ថាការអានរបស់យើងភាគច្រើនវែង ហើយមិនចង់រង់ចាំ យើងអាចបង្កើនសមាមាត្រនេះ និងទទួលបានប្រសិទ្ធភាពខ្ពស់លឿនជាងមុន។

ឧទាហរណ៍យើងកំណត់មេគុណនេះ = 0.01 ។ នេះមានន័យថា Overhead (សូមមើលខាងលើ) នឹងត្រូវបានគុណដោយលេខនេះដោយលទ្ធផលលទ្ធផល ហើយភាគរយនៃប្លុកដែលបានរក្សាទុកនឹងត្រូវបានកាត់បន្ថយ។ ចូរសន្មតថា Overhead = 300% និងមេគុណ = 0.01 បន្ទាប់មកភាគរយនៃប្លុកឃ្លាំងសម្ងាត់នឹងត្រូវបានកាត់បន្ថយ 3% ។

តក្កវិជ្ជា "Backpressure" ស្រដៀងគ្នានេះក៏ត្រូវបានអនុវត្តសម្រាប់តម្លៃអវិជ្ជមាន (ការលើសចំណុះ) ផងដែរ។ ដោយសារការប្រែប្រួលរយៈពេលខ្លីនៃបរិមាណអាន និងការបណ្តេញចេញគឺតែងតែអាចធ្វើទៅបាន យន្តការនេះអនុញ្ញាតឱ្យអ្នកជៀសវាងការចាកចេញមុនអាយុពីរបៀបបង្កើនប្រសិទ្ធភាព។ Backpressure មានតក្កវិជ្ជាបញ្ច្រាស៖ ការវាយលុកកាន់តែខ្លាំង ប្លុកកាន់តែច្រើនត្រូវបានទុកក្នុងឃ្លាំងសម្ងាត់។

លេខកូដអនុវត្ត

        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. តោះចាប់ផ្តើម Scan (25 threads, batch=100)
2. បន្ទាប់ពី 5 នាទីបន្ថែមការទទួលបានច្រើន (25 ខ្សែស្រឡាយ, បាច់ = 100)
3. បន្ទាប់ពី 5 នាទី សូមបិទការទទួលច្រើន (នៅសល់តែស្កេនម្តងទៀត)

យើងធ្វើការរត់ពីរ ទីមួយ hbase.lru.cache.heavy.eviction.count.limit = 10000 (ដែលពិតជាបិទមុខងារ) ហើយបន្ទាប់មកកំណត់ limit = 0 (បើកដំណើរការវា)។

នៅក្នុងកំណត់ហេតុខាងក្រោម យើងឃើញពីរបៀបដែលមុខងារត្រូវបានបើក ហើយកំណត់ការ Overshooting ឡើងវិញទៅ 14-71%។ យូរៗម្តង បន្ទុកថយចុះ ដែលបើក Backpressure ហើយ HBase ផ្ទុកប្លុកបន្ថែមទៀតម្តងទៀត។

Log RegionServer
បណ្តេញចេញ (MB): 0, សមាមាត្រ 0.0, លើស (%): -100, បញ្ជរការបណ្តេញចេញធ្ងន់: 0, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 100
បណ្តេញចេញ (MB): 0, សមាមាត្រ 0.0, លើស (%): -100, បញ្ជរការបណ្តេញចេញធ្ងន់: 0, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 100
បណ្តេញចេញ (MB): 2170, សមាមាត្រ 1.09, លើស (%): 985, បញ្ជរការបណ្តេញចេញធ្ងន់: 1, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 91 < ចាប់ផ្តើម
បណ្តេញចេញ (MB): 3763, សមាមាត្រ 1.08, លើស (%): 1781, បញ្ជរការបណ្តេញចេញធ្ងន់: 2, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 76
បណ្តេញចេញ (MB): 3306, សមាមាត្រ 1.07, លើស (%): 1553, បញ្ជរការបណ្តេញចេញធ្ងន់: 3, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 61
បណ្តេញចេញ (MB): 2508, សមាមាត្រ 1.06, លើស (%): 1154, បញ្ជរការបណ្តេញចេញធ្ងន់: 4, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 50
បណ្តេញចេញ (MB): 1824, សមាមាត្រ 1.04, លើស (%): 812, បញ្ជរការបណ្តេញចេញធ្ងន់: 5, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 42
បណ្តេញចេញ (MB): 1482, សមាមាត្រ 1.03, លើស (%): 641, បញ្ជរការបណ្តេញចេញធ្ងន់: 6, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 36
បណ្តេញចេញ (MB): 1140, សមាមាត្រ 1.01, លើស (%): 470, បញ្ជរការបណ្តេញចេញធ្ងន់: 7, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 32
បណ្តេញចេញ (MB): 913, សមាមាត្រ 1.0, លើស (%): 356, បញ្ជរការបណ្តេញចេញធ្ងន់: 8, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 29
បណ្តេញចេញ (MB): 912, សមាមាត្រ 0.89, លើស (%): 356, បញ្ជរការបណ្តេញចេញធ្ងន់: 9, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 26
បណ្តេញចេញ (MB): 684, សមាមាត្រ 0.76, លើស (%): 242, បញ្ជរការបណ្តេញចេញធ្ងន់: 10, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 24
បណ្តេញចេញ (MB): 684, សមាមាត្រ 0.61, លើស (%): 242, បញ្ជរការបណ្តេញចេញធ្ងន់: 11, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 456, សមាមាត្រ 0.51, លើស (%): 128, បញ្ជរការបណ្តេញចេញធ្ងន់: 12, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 21
បណ្តេញចេញ (MB): 456, សមាមាត្រ 0.42, លើស (%): 128, បញ្ជរការបណ្តេញចេញធ្ងន់: 13, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 20
បណ្តេញចេញ (MB): 456, សមាមាត្រ 0.33, លើស (%): 128, បញ្ជរការបណ្តេញចេញធ្ងន់: 14, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 19
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.33, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 15, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 19
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.32, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 16, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 19
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.31, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 17, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 19
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.3, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 18, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 19
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.29, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 19, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 19
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.27, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 20, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 19
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.25, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 21, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 19
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.24, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 22, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 19
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.22, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 23, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 19
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.21, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 24, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 19
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.2, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 25, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 19
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.17, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 26, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 19
បណ្តេញចេញ (MB): 456, សមាមាត្រ 0.17, លើស (%): 128, បញ្ជរការបណ្តេញចេញធ្ងន់: 27, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 18 < បានបន្ថែមទទួលបាន (ប៉ុន្តែតារាងដូចគ្នា)
បណ្តេញចេញ (MB): 456, សមាមាត្រ 0.15, លើស (%): 128, បញ្ជរការបណ្តេញចេញធ្ងន់: 28, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 17
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.13, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 29, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 17
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.11, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 30, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 17
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.09, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 31, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 17
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.08, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 32, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 17
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.07, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 33, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 17
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.06, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 34, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 17
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.05, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 35, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 17
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.05, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 36, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 17
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.04, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 37, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 17
បណ្តេញចេញ (MB): 109, សមាមាត្រ 0.04, លើស (%): -46, បញ្ជរការបណ្តេញចេញធ្ងន់: 37, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22 < សម្ពាធខាងក្រោយ
បណ្តេញចេញ (MB): 798, សមាមាត្រ 0.24, លើស (%): 299, បញ្ជរការបណ្តេញចេញធ្ងន់: 38, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 20
បណ្តេញចេញ (MB): 798, សមាមាត្រ 0.29, លើស (%): 299, បញ្ជរការបណ្តេញចេញធ្ងន់: 39, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 18
បណ្តេញចេញ (MB): 570, សមាមាត្រ 0.27, លើស (%): 185, បញ្ជរការបណ្តេញចេញធ្ងន់: 40, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 17
បណ្តេញចេញ (MB): 456, សមាមាត្រ 0.22, លើស (%): 128, បញ្ជរការបណ្តេញចេញធ្ងន់: 41, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 16
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.16, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 42, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 16
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.11, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 43, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 16
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.09, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 44, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 16
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.07, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 45, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 16
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.05, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 46, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 16
បណ្តេញចេញ (MB): 222, សមាមាត្រ 0.04, លើស (%): 11, បញ្ជរការបណ្តេញចេញធ្ងន់: 47, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 16
បណ្តេញចេញ (MB): 104, សមាមាត្រ 0.03, លើស (%): -48, បញ្ជរការបណ្តេញចេញធ្ងន់: 47, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 21 < ការរំខានទទួលបាន
បណ្តេញចេញ (MB): 684, សមាមាត្រ 0.2, លើស (%): 242, បញ្ជរការបណ្តេញចេញធ្ងន់: 48, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 19
បណ្តេញចេញ (MB): 570, សមាមាត្រ 0.23, លើស (%): 185, បញ្ជរការបណ្តេញចេញធ្ងន់: 49, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 18
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.22, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 50, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 18
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.21, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 51, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 18
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.2, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 52, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 18
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.18, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 53, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 18
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.16, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 54, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 18
បណ្តេញចេញ (MB): 228, សមាមាត្រ 0.14, លើស (%): 14, បញ្ជរការបណ្តេញចេញធ្ងន់: 55, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 18
បណ្តេញចេញ (MB): 112, សមាមាត្រ 0.14, លើស (%): -44, បញ្ជរការបណ្តេញចេញធ្ងន់: 55, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 23 < សម្ពាធខាងក្រោយ
បណ្តេញចេញ (MB): 456, សមាមាត្រ 0.26, លើស (%): 128, បញ្ជរការបណ្តេញចេញធ្ងន់: 56, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.31, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 57, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.33, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 58, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.33, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 59, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.33, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 60, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.33, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 61, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.33, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 62, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.33, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 63, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.32, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 64, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.33, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 65, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.33, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 66, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.32, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 67, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.33, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 68, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.32, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 69, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.32, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 70, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.33, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 71, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.33, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 72, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.33, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 73, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.33, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 74, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.33, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 75, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 342, សមាមាត្រ 0.33, លើស (%): 71, បញ្ជរការបណ្តេញចេញធ្ងន់: 76, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 22
បណ្តេញចេញ (MB): 21, សមាមាត្រ 0.33, លើស (%): -90, បញ្ជរការបណ្តេញចេញធ្ងន់: 76, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 32
បណ្តេញចេញ (MB): 0, សមាមាត្រ 0.0, លើស (%): -100, បញ្ជរការបណ្តេញចេញធ្ងន់: 0, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 100
បណ្តេញចេញ (MB): 0, សមាមាត្រ 0.0, លើស (%): -100, បញ្ជរការបណ្តេញចេញធ្ងន់: 0, ឃ្លាំងសម្ងាត់បច្ចុប្បន្ន DataBlock (%): 100

ការស្កេនគឺចាំបាច់ដើម្បីបង្ហាញដំណើរការដូចគ្នាក្នុងទម្រង់ជាក្រាហ្វនៃទំនាក់ទំនងរវាងផ្នែកឃ្លាំងសម្ងាត់ពីរ - តែមួយ (ដែលប្លុកដែលមិនធ្លាប់ត្រូវបានស្នើសុំពីមុន) និងច្រើន (ទិន្នន័យ "បានស្នើសុំ" យ៉ាងហោចណាស់ម្តងត្រូវបានរក្សាទុកនៅទីនេះ)៖

ហើយចុងក្រោយ តើប្រតិបត្តិការនៃប៉ារ៉ាម៉ែត្រមើលទៅដូចអ្វីក្នុងទម្រង់ក្រាហ្វ។ សម្រាប់ការប្រៀបធៀប ឃ្លាំងសម្ងាត់ត្រូវបានបិទទាំងស្រុងនៅដើមដំបូង បន្ទាប់មក HBase ត្រូវបានបើកដំណើរការជាមួយឃ្លាំងសម្ងាត់ និងពន្យាពេលការចាប់ផ្តើមការងារបង្កើនប្រសិទ្ធភាពត្រឹម 5 នាទី (30 វដ្តនៃការបណ្តេញចេញ) ។

កូដពេញលេញអាចរកបាននៅក្នុង Pull Request HBASE 23887 នៅលើ github ។

ទោះជាយ៉ាងណាក៏ដោយ 300 អានក្នុងមួយវិនាទី មិនមែនសុទ្ធតែអាចសម្រេចបាននៅលើផ្នែករឹងនេះក្រោមលក្ខខណ្ឌទាំងនេះនោះទេ។ ការពិតគឺថានៅពេលដែលអ្នកត្រូវការចូលប្រើទិន្នន័យតាមរយៈ HDFS យន្តការ ShortCircuitCache (តទៅនេះហៅថា SSC) ត្រូវបានប្រើ ដែលអនុញ្ញាតឱ្យអ្នកចូលប្រើទិន្នន័យដោយផ្ទាល់ ជៀសវាងអន្តរកម្មបណ្តាញ។

Profiling បានបង្ហាញថា ទោះបីជាយន្តការនេះផ្តល់ផលចំណេញច្រើនក៏ដោយ វាក៏នៅចំណុចខ្លះក្លាយជាឧបសគ្គផងដែរ ពីព្រោះប្រតិបត្តិការធ្ងន់ៗស្ទើរតែទាំងអស់កើតឡើងនៅក្នុងសោរដែលនាំទៅដល់ការរារាំងភាគច្រើននៃពេលវេលា។

ដោយបានដឹងពីបញ្ហានេះ យើងបានដឹងថាបញ្ហាអាចត្រូវបានជៀសវាងដោយការបង្កើតអារេនៃ SSCs ឯករាជ្យមួយ៖

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 ពាន់អានក្នុងប្លុក 64 KB ជាមួយនឹងឃ្លាំងសម្ងាត់មួយត្រូវការ 78 វិនាទី។ ចំណែក​ឯ​ឃ្លាំង​សម្ងាត់ 5 វា​ត្រូវ​ចំណាយ​ពេល 16 វិនាទី។ ទាំងនោះ។ មានការបង្កើនល្បឿន ~ 5 ដង។ ដូចដែលអាចមើលឃើញពីក្រាហ្វ ឥទ្ធិពលគឺមិនគួរឱ្យកត់សម្គាល់សម្រាប់ការអានប៉ារ៉ាឡែលមួយចំនួនតូចទេ វាចាប់ផ្តើមដើរតួនាទីគួរឱ្យកត់សម្គាល់នៅពេលមានការអានច្រើនជាង 50 ខ្សែស្រឡាយ។ វាក៏គួរឱ្យកត់សម្គាល់ផងដែរថាការបង្កើនចំនួន SSCs ពី 6 និងខាងលើផ្តល់នូវការកើនឡើងនៃការអនុវត្តតិចតួច។

ចំណាំ 1: ដោយសារលទ្ធផលតេស្តមានភាពប្រែប្រួលខ្លាំង (សូមមើលខាងក្រោម) ការរត់ចំនួន 3 ត្រូវបានអនុវត្ត ហើយតម្លៃលទ្ធផលគឺជាមធ្យម។

ចំណាំទី 2៖ ដំណើរការទទួលបានពីការកំណត់រចនាសម្ព័ន្ធការចូលប្រើដោយចៃដន្យគឺដូចគ្នា ទោះបីជាការចូលប្រើខ្លួនវាយឺតជាងបន្តិចក៏ដោយ។

ទោះយ៉ាងណាក៏ដោយ ចាំបាច់ត្រូវបញ្ជាក់ឱ្យច្បាស់ថា មិនដូចករណីជាមួយ HBase ការបង្កើនល្បឿននេះមិនតែងតែឥតគិតថ្លៃនោះទេ។ នៅទីនេះយើង "ដោះសោ" សមត្ថភាពរបស់ CPU ក្នុងការធ្វើការងារកាន់តែច្រើន ជំនួសឱ្យការព្យួរនៅលើសោ។

នៅទីនេះអ្នកអាចសង្កេតឃើញថា ជាទូទៅការកើនឡើងនៃចំនួនឃ្លាំងសម្ងាត់ផ្តល់នូវការកើនឡើងសមាមាត្រប្រហាក់ប្រហែលនៃការប្រើប្រាស់ស៊ីភីយូ។ ទោះយ៉ាងណាក៏ដោយមានបន្សំដែលឈ្នះច្រើនជាងបន្តិច។

ជាឧទាហរណ៍ សូមក្រឡេកមើលការកំណត់ SSC = 3 ឲ្យកាន់តែដិតដល់។ ការកើនឡើងនៃការអនុវត្តលើជួរគឺប្រហែល 3.3 ដង។ ខាង​ក្រោម​នេះ​ជា​លទ្ធផល​ពី​ការ​រត់​ទាំង​បី​ដាច់​ដោយ​ឡែក​ពី​គ្នា។

ខណៈពេលដែលការប្រើប្រាស់ស៊ីភីយូកើនឡើងប្រហែល 2.8 ដង។ ភាពខុសប្លែកគ្នានេះមិនធំទេ ប៉ុន្តែ Greta តូចសប្បាយចិត្តរួចទៅហើយ ហើយប្រហែលជាមានពេលទៅសាលា និងរៀន។

ដូច្នេះ វានឹងមានឥទ្ធិពលវិជ្ជមានសម្រាប់ឧបករណ៍ណាមួយដែលប្រើការចូលដំណើរការភាគច្រើនទៅកាន់ HDFS (ឧទាហរណ៍ Spark ។ . ដើម្បីពិនិត្យមើល សូមសាកល្បងថាតើការប្រើប្រាស់រួមគ្នានៃការបង្កើនប្រសិទ្ធភាព BlockCache និងការលៃតម្រូវ SSC សម្រាប់ការអានពី HBase នឹងមានអ្វីខ្លះ។

វាអាចត្រូវបានគេមើលឃើញថានៅក្រោមលក្ខខណ្ឌបែបនេះឥទ្ធិពលគឺមិនអស្ចារ្យដូចនៅក្នុងការធ្វើតេស្តចម្រាញ់ (អានដោយគ្មានដំណើរការណាមួយ) ប៉ុន្តែវាពិតជាអាចធ្វើទៅបានដើម្បីច្របាច់ចេញ 80K បន្ថែមនៅទីនេះ។ រួមគ្នា ការបង្កើនប្រសិទ្ធភាពទាំងពីរផ្តល់នូវការបង្កើនល្បឿនដល់ទៅ 4 ដង។

PR ក៏ត្រូវបានបង្កើតឡើងសម្រាប់ការបង្កើនប្រសិទ្ធភាពនេះផងដែរ។ [HDFS-15202]ដែលត្រូវបានបញ្ចូលគ្នា ហើយមុខងារនេះនឹងមាននៅក្នុងការចេញផ្សាយនាពេលខាងមុខ។

ហើយចុងក្រោយ វាជាការគួរឱ្យចាប់អារម្មណ៍ក្នុងការប្រៀបធៀបការអាននៃមូលដ្ឋានទិន្នន័យដែលមានជួរឈរធំទូលាយស្រដៀងគ្នា Cassandra និង HBase ។

ដើម្បីធ្វើដូច្នេះ យើងបានបើកដំណើរការឧបករណ៍ប្រើប្រាស់សាកល្បងការផ្ទុក YCSB ស្តង់ដារពីម៉ាស៊ីនពីរ (សរុបចំនួន 800 ខ្សែ)។ នៅផ្នែកខាងម៉ាស៊ីនមេ - 4 ករណីនៃ RegionServer និង Cassandra នៅលើ 4 ម៉ាស៊ីន (មិនមែនជាកន្លែងដែលអតិថិជនកំពុងដំណើរការដើម្បីជៀសវាងឥទ្ធិពលរបស់ពួកគេ) ។ ការអានបានមកពីតារាងទំហំ៖

HBase - 300 GB នៅលើ HDFS (ទិន្នន័យសុទ្ធ 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 ត្រូវបានញែក និងចងក្រងជាក្រាហ្វ Excel៖

ដូចដែលអ្នកអាចឃើញការបង្កើនប្រសិទ្ធភាពទាំងនេះធ្វើឱ្យវាអាចប្រៀបធៀបដំណើរការនៃមូលដ្ឋានទិន្នន័យទាំងនេះនៅក្រោមលក្ខខណ្ឌទាំងនេះនិងសម្រេចបាន 450 ពាន់អានក្នុងមួយវិនាទី។

យើងសង្ឃឹមថាព័ត៌មាននេះអាចមានប្រយោជន៍សម្រាប់នរណាម្នាក់ក្នុងអំឡុងពេលតស៊ូដ៏រំភើបសម្រាប់ផលិតភាព។

ប្រភព: www.habr.com