როგორ გავზარდოთ წაკითხვის სიჩქარე HBase-დან 3-ჯერ და HDFS-დან 5-ჯერ

მაღალი შესრულება ერთ-ერთი მთავარი მოთხოვნაა დიდ მონაცემებთან მუშაობისას. Sberbank-ის მონაცემთა ჩატვირთვის განყოფილებაში, ჩვენ თითქმის ყველა ტრანზაქციას ვათავსებთ ჩვენს Hadoop-ზე დაფუძნებულ მონაცემთა ღრუბელში და, შესაბამისად, ვმუშაობთ ინფორმაციის მართლაც დიდ ნაკადებთან. ბუნებრივია, ჩვენ ყოველთვის ვეძებთ მუშაობის გაუმჯობესების გზებს და ახლა გვინდა გითხრათ, როგორ მოვახერხეთ RegionServer HBase და HDFS კლიენტის დაყენება, რის წყალობითაც ჩვენ შევძელით მნიშვნელოვნად გავზარდოთ წაკითხვის ოპერაციების სიჩქარე.


თუმცა, სანამ გაუმჯობესების არსზე გადავიდოდეთ, ღირს ვისაუბროთ შეზღუდვებზე, რომელთა გვერდის ავლა, პრინციპში, შეუძლებელია, თუ HDD-ზე დაჯდებით.

რატომ არის HDD და სწრაფი შემთხვევითი წვდომის კითხვა შეუთავსებელი
მოგეხსენებათ, HBase და მრავალი სხვა მონაცემთა ბაზა ინახავს მონაცემებს რამდენიმე ათეული კილობაიტის ზომის ბლოკებში. ნაგულისხმევად ეს არის დაახლოებით 64 KB. ახლა წარმოვიდგინოთ, რომ ჩვენ უნდა მივიღოთ მხოლოდ 100 ბაიტი და ვთხოვთ HBase-ს მოგვაწოდოს ეს მონაცემები გარკვეული გასაღების გამოყენებით. ვინაიდან HFiles-ში ბლოკის ზომა არის 64 KB, მოთხოვნა იქნება 640-ჯერ მეტი (მხოლოდ ერთი წუთი!) ვიდრე საჭიროა.

შემდეგი, რადგან მოთხოვნა გაივლის HDFS და მისი მეტამონაცემების ქეშირების მექანიზმს ShortCircuitCache (რომელიც ფაილებზე პირდაპირ წვდომის საშუალებას იძლევა), ეს იწვევს დისკიდან უკვე 1 MB წაკითხვას. თუმცა, ეს შეიძლება დარეგულირდეს პარამეტრით dfs.client.read.shortcircuit.buffer.size და ხშირ შემთხვევაში აზრი აქვს ამ მნიშვნელობის შემცირებას, მაგალითად 126 კბ-მდე.

ვთქვათ, ვაკეთებთ ამას, მაგრამ გარდა ამისა, როდესაც ვიწყებთ მონაცემების კითხვას java api-ით, როგორიცაა FileChannel.read ფუნქციები და ვთხოვთ ოპერაციულ სისტემას წაიკითხოს მითითებული რაოდენობის მონაცემები, ის კითხულობს „ყოველ შემთხვევაში“ 2-ჯერ მეტს. , ე.ი. 256 KB ჩვენს შემთხვევაში. ეს იმიტომ ხდება, რომ java-ს არ აქვს FADV_RANDOM დროშის დაყენების მარტივი გზა ამ ქცევის თავიდან ასაცილებლად.

შედეგად, ჩვენი 100 ბაიტის მისაღებად, ქუდის ქვეშ 2600-ჯერ მეტი იკითხება. როგორც ჩანს, გამოსავალი აშკარაა, მოდით შევამციროთ ბლოკის ზომა კილობაიტამდე, დავაყენოთ აღნიშნული დროშა და მივიღოთ დიდი განმანათლებლობის აჩქარება. მაგრამ უბედურება ის არის, რომ ბლოკის ზომის 2-ჯერ შემცირებით, ჩვენ ასევე ვამცირებთ დროის ერთეულზე წაკითხული ბაიტების რაოდენობას 2-ჯერ.

FADV_RANDOM დროშის დაყენებიდან გარკვეული სარგებლის მიღება შესაძლებელია, მაგრამ მხოლოდ მაღალი მრავალწახნაგობით და ბლოკის ზომით 128 KB, მაგრამ ეს არის მაქსიმუმ რამდენიმე ათეული პროცენტი:

ტესტები ჩატარდა 100 ფაილზე, თითოეული 1 GB ზომის და განთავსებული იყო 10 HDD-ზე.

მოდით გამოვთვალოთ რისი იმედი შეგვიძლია, პრინციპში, ამ სიჩქარით:
ვთქვათ, ვკითხულობთ 10 დისკიდან 280 მბ/წმ სიჩქარით, ე.ი. 3 მილიონი ჯერ 100 ბაიტი. მაგრამ როგორც გვახსოვს, ჩვენთვის საჭირო მონაცემები 2600-ჯერ ნაკლებია ვიდრე წაკითხული. ამრიგად, 3 მილიონს ვყოფთ 2600-ზე და ვიღებთ 1100 ჩანაწერი წამში.

დეპრესიული, არა? ასეთია ბუნება Წვდომა წვდომა მონაცემებზე HDD-ზე - ბლოკის ზომის მიუხედავად. ეს არის შემთხვევითი წვდომის ფიზიკური ლიმიტი და არცერთ მონაცემთა ბაზას არ შეუძლია მეტის შეკუმშვა ასეთ პირობებში.

მაშინ როგორ აღწევს მონაცემთა ბაზები ბევრად უფრო მაღალ სიჩქარეს? ამ კითხვაზე პასუხის გასაცემად, მოდით შევხედოთ რა ხდება შემდეგ სურათზე:

აქ ჩვენ ვხედავთ, რომ პირველი რამდენიმე წუთის განმავლობაში სიჩქარე მართლაც დაახლოებით ათასი ჩანაწერია წამში. ამასთან, იმის გამო, რომ გაცილებით მეტი იკითხება, ვიდრე მოთხოვნილი იყო, მონაცემები მთავრდება ოპერაციული სისტემის (linux) ბუფ/ქეშში და სიჩქარე იზრდება უფრო ღირსეულ 60 ათას წამში.

ამრიგად, შემდგომში ჩვენ ვიმუშავებთ წვდომის დაჩქარებასთან მხოლოდ იმ მონაცემებზე, რომლებიც არის ოპერაციული სისტემის ქეში ან მდებარეობს SSD/NVMe შესანახი წვდომის სიჩქარის შესანახ მოწყობილობებში.

ჩვენს შემთხვევაში, ჩვენ ჩავატარებთ ტესტებს 4 სერვერისგან შემდგარ სკამზე, რომელთაგან თითოეული დარიცხულია შემდეგნაირად:

პროცესორი: Xeon E5-2680 v4 @ 2.40 GHz 64 ძაფები.
ოპერატიული მეხსიერება: 730 GB.
java ვერსია: 1.8.0_111

და აქ მთავარია ცხრილებში არსებული მონაცემების რაოდენობა, რომელიც უნდა წაიკითხოთ. ფაქტია, რომ თუ წაიკითხავთ მონაცემებს ცხრილიდან, რომელიც მთლიანად მოთავსებულია HBase ქეშში, მაშინ ის ვერც კი მოვა ოპერაციული სისტემის buff/cache-დან წაკითხვამდე. იმის გამო, რომ HBase ნაგულისხმევად გამოყოფს მეხსიერების 40% სტრუქტურას, რომელსაც ეწოდება BlockCache. არსებითად, ეს არის ConcurrentHashMap, სადაც გასაღები არის ფაილის სახელი + ბლოკის ოფსეტი, და მნიშვნელობა არის ფაქტობრივი მონაცემები ამ ოფსეტში.

ამრიგად, როდესაც ვკითხულობთ მხოლოდ ამ სტრუქტურიდან, ჩვენ ჩვენ ვხედავთ შესანიშნავ სიჩქარეს, როგორც მილიონი მოთხოვნა წამში. მაგრამ წარმოვიდგინოთ, რომ ჩვენ არ შეგვიძლია ასობით გიგაბაიტი მეხსიერების გამოყოფა მხოლოდ მონაცემთა ბაზის საჭიროებისთვის, რადგან ამ სერვერებზე ბევრი სხვა სასარგებლო რამ მუშაობს.

მაგალითად, ჩვენს შემთხვევაში, BlockCache-ის მოცულობა ერთ RS-ზე არის დაახლოებით 12 GB. ერთ კვანძზე ორი რს-ი ჩამოვყარეთ, ე.ი. 96 GB გამოყოფილია BlockCache-სთვის ყველა კვანძზე. და ბევრჯერ მეტი მონაცემია, მაგალითად, იყოს 4 ცხრილი, თითო 130 რეგიონი, რომლებშიც ფაილები არის 800 მბ ზომის, შეკუმშული FAST_DIFF-ით, ე.ი. სულ 410 GB (ეს არის სუფთა მონაცემები, ანუ რეპლიკაციის ფაქტორის გათვალისწინების გარეშე).

ამრიგად, BlockCache არის მონაცემთა მთლიანი მოცულობის მხოლოდ 23% და ეს ბევრად უფრო ახლოსაა რეალურ პირობებთან, რასაც BigData ჰქვია. და სწორედ აქ იწყება გართობა - რადგან ცხადია, რაც უფრო ნაკლები ქეში მოხვდება, მით უფრო უარესია შესრულება. ბოლოს და ბოლოს, თუ გაცდენთ, ბევრი სამუშაო მოგიწევთ - ე.ი. გადადით სისტემის ფუნქციების გამოძახებაზე. თუმცა, ამის თავიდან აცილება შეუძლებელია, ამიტომ მოდით შევხედოთ სრულიად განსხვავებულ ასპექტს - რა ემართება ქეშის შიგნით არსებულ მონაცემებს?

მოდით გავამარტივოთ სიტუაცია და დავუშვათ, რომ გვაქვს ქეში, რომელიც მხოლოდ 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 რესურსს ისე, რომ არ ვასრულებთ სიზიფური სამუშაოს ქეშში მონაცემების განთავსებას, მხოლოდ იმისთვის, რომ სასწრაფოდ გადავაგდოთ ისინი მარსის ძაღლების გადინებაში:

ამავდროულად, პროცესორის გამოყენება იზრდება, მაგრამ ბევრად ნაკლებია ვიდრე პროდუქტიულობა:

ასევე აღსანიშნავია, რომ 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-ზე და ფუნქცია გავააქტიუროთ გაშვებისთანავე.

თუმცა, ამ პარამეტრში ასევე არის დატვირთვა. თუ ჩვენი დატვირთვა ისეთია, რომ მოკლევადიანი კითხვა (ვთქვათ დღის განმავლობაში) და გრძელვადიანი კითხვა (ღამით) მუდმივად იკვეთება, მაშინ ჩვენ შეგვიძლია დავრწმუნდეთ, რომ ფუნქცია ჩართულია მხოლოდ მაშინ, როდესაც ხანგრძლივი წაკითხვის ოპერაციები მიმდინარეობს.

მაგალითად, ჩვენ ვიცით, რომ მოკლევადიანი კითხვა ჩვეულებრივ დაახლოებით 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 წამში ვიანგარიშებთ რამდენი ბაიტი იყო. გამოსახლება ფორმულის გამოყენებით:

ზედნადები = გათავისუფლებული ბაიტების ჯამი (MB) * 100 / ლიმიტი (MB) - 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. ეს ნიშნავს, რომ 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. დავიწყოთ სკანირების გაკეთება (25 ძაფი, პარტია = 100)
2. 5 წუთის შემდეგ დაამატეთ მრავალჯერადი (25 ძაფი, პარტია = 100)
3. 5 წუთის შემდეგ გამორთეთ multi-gets (რჩება მხოლოდ სკანირება ისევ)

ჩვენ ვაკეთებთ ორ გაშვებას, ჯერ hbase.lru.cache.heavy.eviction.count.limit = 10000 (რაც რეალურად გამორთავს ფუნქციას) და შემდეგ ვაყენებთ ლიმიტს = 0 (ჩართავს მას).

ქვემოთ მოყვანილ ჟურნალებში ვხედავთ, თუ როგორ არის ჩართული ფუნქცია და აღადგენს Overshooting 14-71%-მდე. დროდადრო დატვირთვა მცირდება, რაც ჩართავს Backpressure-ს და HBase ისევ ქეშირებს მეტ ბლოკს.

რეგიონის სერვერის შესვლა
გამოდევნილი (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) მექანიზმი, რომელიც საშუალებას გაძლევთ უშუალოდ შეხვიდეთ მონაცემებზე, თავიდან აიცილოთ ქსელური ურთიერთქმედება.

პროფილირებამ აჩვენა, რომ მიუხედავად იმისა, რომ ეს მექანიზმი იძლევა დიდ მოგებას, ის ასევე ხდება რაღაც მომენტში ბოსტნეულობა, რადგან თითქმის ყველა მძიმე ოპერაცია ხდება საკეტის შიგნით, რაც იწვევს უმეტეს დროს დაბლოკვას.

ამის გაცნობიერების შემდეგ მივხვდით, რომ პრობლემის გვერდის ავლა შესაძლებელია დამოუკიდებელი 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 ათასი წაკითხვის შესრულების დრო 64 კბ ბლოკში ერთი ქეშით მოითხოვს 78 წამს. მაშინ როცა 5 ქეშით ამას 16 წამი სჭირდება. იმათ. არის 5-ჯერ აჩქარება. როგორც გრაფიკიდან ჩანს, ეფექტი არც თუ ისე შესამჩნევია მცირე რაოდენობის პარალელური წაკითხვისთვის, ის იწყებს შესამჩნევ როლს, როდესაც 50 ძაფზე მეტი წაკითხვაა. ასევე შესამჩნევია SSC-ების რაოდენობის გაზრდა 6-დან. და ზემოთ იძლევა მნიშვნელოვნად მცირე შესრულების ზრდას.

შენიშვნა 1: ვინაიდან ტესტის შედეგები საკმაოდ ცვალებადია (იხ. ქვემოთ), განხორციელდა 3 გაშვება და მიღებული მნიშვნელობები საშუალოდ შეფასდა.

შენიშვნა 2: შემთხვევითი წვდომის კონფიგურაციის შედეგად მიღებული ეფექტურობა იგივეა, თუმცა თავად წვდომა ოდნავ ნელია.

თუმცა, აუცილებელია განვმარტოთ, რომ HBase-ის შემთხვევისგან განსხვავებით, ეს აჩქარება ყოველთვის უფასო არ არის. აქ ჩვენ „ვიხსნით“ CPU-ს შესაძლებლობას, უფრო მეტი სამუშაო გააკეთოს, ნაცვლად საკეტებზე ჩამოკიდების.

აქ შეგიძლიათ დააკვირდეთ, რომ ზოგადად, ქეშების რაოდენობის ზრდა იძლევა CPU-ს გამოყენების დაახლოებით პროპორციულ ზრდას. თუმცა, არის ოდნავ მეტი მომგებიანი კომბინაციები.

მაგალითად, მოდით უფრო დეტალურად შევხედოთ პარამეტრს SSC = 3. ეფექტურობის ზრდა დიაპაზონში არის დაახლოებით 3.3-ჯერ. ქვემოთ მოცემულია სამივე ცალკეული გაშვების შედეგები.

მაშინ, როდესაც პროცესორის მოხმარება იზრდება დაახლოებით 2.8-ჯერ. განსხვავება არც თუ ისე დიდია, მაგრამ პატარა გრეტა უკვე ბედნიერია და შეიძლება სკოლაში დასწრება და გაკვეთილების გავლაც მოასწროს.

ამრიგად, ეს დადებითად იმოქმედებს ნებისმიერ ხელსაწყოზე, რომელიც იყენებს HDFS-ზე დიდი წვდომას (მაგალითად, Spark და ა.შ.), იმ პირობით, რომ აპლიკაციის კოდი მსუბუქი წონაა (ანუ შტეფსელი HDFS კლიენტის მხარესაა) და არის CPU-ის უფასო სიმძლავრე. . შესამოწმებლად, მოდით შევამოწმოთ რა ეფექტი ექნება BlockCache ოპტიმიზაციისა და SSC tuning-ის კომბინირებულ გამოყენებას HBase-დან წასაკითხად.

ჩანს, რომ ასეთ პირობებში ეფექტი არ არის ისეთი დიდი, როგორც დახვეწილ ტესტებში (კითხვა ყოველგვარი დამუშავების გარეშე), მაგრამ სავსებით შესაძლებელია აქ დამატებითი 80K გამოწურვა. ორივე ოპტიმიზაცია ერთად უზრუნველყოფს 4-ჯერ სიჩქარეს.

ამ ოპტიმიზაციისთვის პიარიც გაკეთდა [HDFS-15202], რომელიც გაერთიანდა და ეს ფუნქცია ხელმისაწვდომი იქნება მომავალ გამოშვებებში.

და ბოლოს, საინტერესო იყო მსგავსი ფართო სვეტის მონაცემთა ბაზის, Cassandra-სა და HBase-ის კითხვის შესრულების შედარება.

ამისათვის ჩვენ გავუშვით სტანდარტული YCSB დატვირთვის ტესტირების უტილიტა ორი ჰოსტიდან (სულ 800 თემა). სერვერის მხარეს - RegionServer-ისა და Cassandra-ს 4 შემთხვევა 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