HBase-ის გამოყენების თეორია და პრაქტიკა

Საღამო მშვიდობისა მე მქვია დანილ ლიპოვოი, ჩვენმა გუნდმა Sbertech-ში დაიწყო HBase-ის გამოყენება ოპერატიული მონაცემების შესანახად. მისი შესწავლის პროცესში დაგროვდა გამოცდილება, რომლის სისტემატიზაცია და აღწერა მინდოდა (ვიმედოვნებთ, რომ ბევრს გამოადგება). ქვემოთ მოყვანილი ყველა ექსპერიმენტი ჩატარდა HBase ვერსიებით 1.2.0-cdh5.14.2 და 2.0.0-cdh6.0.0-beta1.

1. ზოგადი არქიტექტურა
2. მონაცემების ჩაწერა HBASE-ში
3. მონაცემების კითხვა HBASE-დან
4. მონაცემთა ქეშირება
5. მონაცემთა ჯგუფური დამუშავება MultiGet/MultiPut
6. ცხრილების რეგიონებად დაყოფის სტრატეგია (გაყოფა)
7. შეცდომის ტოლერანტობა, კომპაქტურობა და მონაცემთა ლოკალიზაცია
8. პარამეტრები და შესრულება
9. სტრესის ტესტირება
10. დასკვნები

1. ზოგადი არქიტექტურა

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

2. ჩაწერეთ მონაცემები HBASE-ში

პირველ რიგში, მოდით შევხედოთ უმარტივეს შემთხვევას - ჩაწერეთ საკვანძო მნიშვნელობის ობიექტი მაგიდაზე put(rowkey) გამოყენებით. კლიენტმა ჯერ უნდა გაარკვიოს, სად მდებარეობს Root Region Server (RRS), რომელიც ინახავს hbase:meta ცხრილს. ამ ინფორმაციას ის ZooKeeper-ისგან იღებს. რის შემდეგაც ის წვდება RRS-ს და კითხულობს hbase:meta ცხრილს, საიდანაც ამოიღებს ინფორმაციას იმის შესახებ, თუ რომელი RegionServer (RS) არის პასუხისმგებელი მოცემული რიგის კლავიშის მონაცემების შესანახად ინტერესის ცხრილში. სამომავლო გამოყენებისთვის მეტა ცხრილი ინახება კლიენტის მიერ და, შესაბამისად, შემდგომი ზარები უფრო სწრაფად მიდის პირდაპირ RS-ში.

შემდეგი, RS, მოთხოვნის მიღების შემდეგ, პირველ რიგში წერს მას WriteAheadLog-ში (WAL), რომელიც აუცილებელია ავარიის შემთხვევაში აღდგენისთვის. შემდეგ ინახავს მონაცემებს Memstore– ში. ეს არის მეხსიერების ბუფერი, რომელიც შეიცავს მოცემული რეგიონის გასაღებების დახარისხებულ კომპლექტს. ცხრილი შეიძლება დაიყოს რეგიონებად (ტიხრები), რომელთაგან თითოეული შეიცავს გასაღებების ცალკეულ კომპლექტს. ეს საშუალებას გაძლევთ განათავსოთ რეგიონები სხვადასხვა სერვერებზე, რათა მიაღწიოთ უფრო მაღალ შესრულებას. თუმცა, მიუხედავად ამ განცხადების აშკარად, ჩვენ მოგვიანებით ვნახავთ, რომ ეს ყველა შემთხვევაში არ მუშაობს.

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

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

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

გარდა ზემოთ აღწერილი ჩატვირთვის პროცესისა, არსებობს ბევრად უფრო ეფექტური პროცედურა, რომელიც ალბათ ამ მონაცემთა ბაზის უძლიერესი მხარეა – BulkLoad. ეს მდგომარეობს იმაში, რომ ჩვენ დამოუკიდებლად ვაყალიბებთ HFiles-ს და ვდებთ მათ დისკზე, რაც საშუალებას გვაძლევს სრულყოფილად გავზარდოთ და მივაღწიოთ ძალიან ღირსეულ სიჩქარეებს. სინამდვილეში, აქ შეზღუდვა არ არის HBase, არამედ აპარატურის შესაძლებლობები. ქვემოთ მოცემულია ჩატვირთვის შედეგები კლასტერზე, რომელიც შედგება 16 RegionServers და 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads), HBase ვერსია 1.2.0-cdh5.14.2.

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

თქვენ ასევე შეგიძლიათ დაიწყოთ ჩატვირთვა ორ მაგიდაზე ერთდროულად და მიიღოთ ორმაგი სიჩქარე. ქვემოთ ხედავთ, რომ 10 KB ბლოკის ერთდროულად ჩაწერა ორ მაგიდაზე ხდება დაახლოებით 600 მბ/წმ სიჩქარით თითოეულში (სულ 1275 მბ/წმ), რაც ემთხვევა ერთ ცხრილზე ჩაწერის სიჩქარეს 623 მბ/წმ (იხ. 11 ზემოთ)

მაგრამ მეორე გაშვება ჩანაწერებით 50 KB აჩვენებს, რომ ჩამოტვირთვის სიჩქარე ოდნავ იზრდება, რაც მიუთითებს იმაზე, რომ ის უახლოვდება ლიმიტურ მნიშვნელობებს. ამავდროულად, უნდა გაითვალისწინოთ, რომ თავად HBASE-ზე პრაქტიკულად არანაირი დატვირთვა არ არის შექმნილი, მისგან საჭიროა მხოლოდ მონაცემების მიწოდება hbase:meta-დან და HFiles-ის გაფორმების შემდეგ გადატვირთეთ BlockCache მონაცემები და შეინახეთ MemStore ბუფერი დისკზე, თუ ის ცარიელი არ არის.

3. HBASE-დან მონაცემების კითხვა

თუ ვივარაუდებთ, რომ კლიენტს უკვე აქვს ყველა ინფორმაცია hbase:meta-დან (იხ. პუნქტი 2), მაშინ მოთხოვნა მიდის პირდაპირ RS-ში, სადაც ინახება საჭირო გასაღები. პირველი, ძიება ხორციელდება MemCache-ში. იმისდა მიუხედავად, არის თუ არა მონაცემები იქ, თუ არა, ძებნა ასევე ხორციელდება ბლოკკატის ბუფერში და, საჭიროების შემთხვევაში, HFiles– ში. თუ ფაილში მონაცემები იქნა ნაპოვნი, იგი მოთავსებულია Blockcache- ში და შემდეგ მოთხოვნით უფრო სწრაფად დაუბრუნდება. Hfile- ში ძებნა შედარებით სწრაფია Bloom ფილტრის გამოყენების წყალობით, ე.ი. მცირე რაოდენობის მონაცემების წაკითხვის შემდეგ, ის დაუყოვნებლივ განსაზღვრავს, შეიცავს თუ არა ეს ფაილი საჭირო გასაღებს და თუ არა, შემდეგ გადადის შემდეგზე.

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

4. მონაცემთა ქეშირება

MemStore და BlockCache ბუფერები იკავებენ გამოყოფილი on-heap RS მეხსიერების 80%-მდე (დანარჩენი დაცულია RS სერვისის ამოცანებისთვის). თუ ტიპიური გამოყენების რეჟიმი ისეთია, რომ პროცესები წერენ და დაუყოვნებლივ კითხულობენ იმავე მონაცემებს, მაშინ აზრი აქვს BlockCache-ის შემცირებას და MemStore-ის გაზრდას, რადგან როდესაც მონაცემების ჩაწერა არ შედის ქეშში წასაკითხად, BlockCache გამოყენებული იქნება ნაკლებად ხშირად. BlockCache ბუფერი შედგება ორი ნაწილისგან: LruBlockCache (ყოველთვის ჩართულია) და BucketCache (ჩვეულებრივ off-heap ან SSD-ზე). BucketCache უნდა იქნას გამოყენებული, როდესაც არის ბევრი კითხვის მოთხოვნა და ისინი არ ჯდება LruBlockCache-ში, რაც იწვევს Garbage Collector-ის აქტიურ მუშაობას. ამავდროულად, არ უნდა ელოდოთ შესრულების რადიკალურ ზრდას წაკითხული ქეშის გამოყენებით, მაგრამ ჩვენ ამას დავუბრუნდებით მე-8 პუნქტში.

არის ერთი BlockCache მთელი RS-ისთვის და არის ერთი MemStore თითოეული ცხრილისთვის (თითო სვეტის ოჯახისთვის).

როგორც აღწერილი თეორიულად, წერისას, მონაცემები არ შედის ქეშში და მართლაც, ასეთი პარამეტრები CACHE_DATA_ON_WRITE ცხრილისთვის და “Cache DATA on Write” RS-ისთვის დაყენებულია false-ზე. თუმცა, პრაქტიკაში, თუ ჩვენ ჩავწერთ მონაცემებს MemStore-ში, შემდეგ გავრეცხავთ მას დისკზე (ამით გავასუფთავებთ), შემდეგ წაშლით შედეგად მიღებულ ფაილს, შემდეგ მისაღებად მოთხოვნის შესრულებით ჩვენ წარმატებით მივიღებთ მონაცემებს. უფრო მეტიც, თუნდაც მთლიანად გამორთოთ BlockCache და შეავსოთ ცხრილი ახალი მონაცემებით, შემდეგ გადააყენოთ MemStore დისკზე, წაშალოთ ისინი და მოითხოვოთ სხვა სესიიდან, ისინი მაინც იქნება სადღაც ამოღებული. ასე რომ, HBase ინახავს არა მხოლოდ მონაცემებს, არამედ იდუმალ საიდუმლოებებსაც.

hbase(main):001:0> create 'ns:magic', 'cf'
Created table ns:magic
Took 1.1533 seconds
hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'
Took 0.2610 seconds
hbase(main):003:0> flush 'ns:magic'
Took 0.6161 seconds
hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash
hbase(main):002:0> get 'ns:magic', 'key1'
 cf:c      timestamp=1534440690218, value=try_to_delete_me

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

5. მონაცემთა პარტიული დამუშავება MultiGet/MultiPut

ცალკეული მოთხოვნების დამუშავება (Get/Put/Delete) საკმაოდ ძვირადღირებული ოპერაციაა, ასე რომ, თუ ეს შესაძლებელია, თქვენ უნდა დააკავშიროთ ისინი სიაში ან სიაში, რაც საშუალებას გაძლევთ მიიღოთ მნიშვნელოვანი ეფექტურობა. ეს განსაკუთრებით ეხება ჩაწერის ოპერაციას, მაგრამ კითხვისას არის შემდეგი შეცდომა. ქვემოთ მოცემული გრაფიკი აჩვენებს MemStore-დან 50 ჩანაწერის წაკითხვის დროს. კითხვა შესრულდა ერთ ძაფში და ჰორიზონტალური ღერძი აჩვენებს კლავიშების რაოდენობას მოთხოვნაში. აქ ხედავთ, რომ ერთ მოთხოვნაში ათას კლავიშამდე გაზრდისას შესრულების დრო ეცემა, ე.ი. სიჩქარე იზრდება. თუმცა, ნაგულისხმევად ჩართული MSLAB რეჟიმით, ამ ზღვრის შემდეგ იწყება შესრულების რადიკალური ვარდნა და რაც უფრო დიდია მონაცემების რაოდენობა ჩანაწერში, მით უფრო გრძელია მუშაობის დრო.

ტესტები ჩატარდა ვირტუალურ მანქანაზე, 8 ბირთვით, ვერსია HBase 2.0.0-cdh6.0.0-beta1.

MSLAB რეჟიმი შექმნილია გროვის ფრაგმენტაციის შესამცირებლად, რაც ხდება ახალი და ძველი თაობის მონაცემების შერევის გამო. როგორც გამოსავალი, როდესაც MSLAB ჩართულია, მონაცემები მოთავსებულია შედარებით მცირე უჯრედებში (ნაწილებად) და მუშავდება ნაწილებად. შედეგად, როდესაც მოთხოვნილ მონაცემთა პაკეტში მოცულობა აღემატება გამოყოფილ ზომას, შესრულება მკვეთრად ეცემა. მეორეს მხრივ, ამ რეჟიმის გამორთვა ასევე არ არის მიზანშეწონილი, რადგან ეს გამოიწვევს GC-ის გამო გაჩერებას მონაცემთა ინტენსიური დამუშავების მომენტებში. კარგი გამოსავალია უჯრედის მოცულობის გაზრდა აქტიური წერის შემთხვევაში ჩასმის საშუალებით, კითხვასთან ერთად. აღსანიშნავია, რომ პრობლემა არ წარმოიქმნება, თუ ჩაწერის შემდეგ გაუშვით flush ბრძანება, რომელიც აბრუნებს MemStore-ს დისკზე, ან თუ ჩატვირთავთ BulkLoad-ის გამოყენებით. ქვემოთ მოყვანილი ცხრილი გვიჩვენებს, რომ მოთხოვნები MemStore-დან უფრო დიდი (და იგივე რაოდენობის) მონაცემებისთვის იწვევს შენელებას. თუმცა, მოცულობის გაზრდით ჩვენ ვაბრუნებთ დამუშავების დროს ნორმალურ რეჟიმში.

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

6. ცხრილების რეგიონებად დაყოფის სტრატეგია (გაყოფა)

ვინაიდან HBase არის გასაღების მნიშვნელობის საცავი და დაყოფა ხორციელდება გასაღებით, ძალზე მნიშვნელოვანია მონაცემთა თანაბრად გაყოფა ყველა რეგიონში. მაგალითად, ასეთი ცხრილის სამ ნაწილად დაყოფა გამოიწვევს მონაცემების სამ რეგიონად დაყოფას:

ეს ხდება, რომ ეს იწვევს მკვეთრ შენელებას, თუ მოგვიანებით დატვირთული მონაცემები ჰგავს, მაგალითად, გრძელ მნიშვნელობებს, მათი უმეტესობა იწყება იგივე ციფრით, მაგალითად:

1000001
1000002
...
1100003

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

HexStringSplit – აქცევს კლავიშს თექვსმეტობით დაშიფრულ სტრიქონად დიაპაზონში "00000000" => "FFFFFFFF" და ავსებს მარცხნივ ნულებს.

UniformSplit – აქცევს კლავიშს ბაიტის მასივში თექვსმეტობითი კოდირებით დიაპაზონში "00" => "FF" და ავსებს მარჯვნივ ნულებით.

გარდა ამისა, შეგიძლიათ მიუთითოთ ნებისმიერი დიაპაზონი ან გასაღებების ნაკრები გაყოფისთვის და დააკონფიგურიროთ ავტომატური გაყოფა. თუმცა, ერთ-ერთი უმარტივესი და ეფექტური მიდგომაა UniformSplit და ჰეშის შეერთების გამოყენება, მაგალითად, ყველაზე მნიშვნელოვანი ბაიტის წყვილი გასაღების CRC32 (rowkey) ფუნქციისა და თავად rowkey-ის მეშვეობით:

Hash + Rowkey

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

7. შეცდომის ტოლერანტობა და მონაცემთა ლოკალიზაცია

ვინაიდან მხოლოდ ერთი რეგიონია პასუხისმგებელი გასაღებების თითოეულ კომპლექტზე, RS ავარიასთან ან დეკომისიაციასთან დაკავშირებული პრობლემების გადაწყვეტა არის ყველა საჭირო მონაცემის შენახვა HDFS-ში. როდესაც RS ეცემა, ოსტატი ამას აღმოაჩენს ზუკერის კვანძზე გულისცემის არარსებობის გზით. შემდეგ ის ანიჭებს სერვისულ რეგიონს სხვა RS-ს და რადგან HFiles ინახება განაწილებულ ფაილურ სისტემაში, ახალი მფლობელი კითხულობს მათ და აგრძელებს მონაცემთა მომსახურებას. თუმცა, ვინაიდან ზოგიერთი მონაცემი შეიძლება იყოს MemStore-ში და არ ჰქონდა დრო HFiles-ში მოხვედრისთვის, WAL, რომელიც ასევე ინახება HDFS-ში, გამოიყენება ოპერაციების ისტორიის აღსადგენად. ცვლილებების გამოყენების შემდეგ, RS-ს შეუძლია უპასუხოს მოთხოვნებს, მაგრამ ეს ნაბიჯი იწვევს იმ ფაქტს, რომ ზოგიერთი მონაცემი და მათი მომსახურე პროცესი მთავრდება სხვადასხვა კვანძზე, ე.ი. ლოკალიზაცია მცირდება.

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

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

ტესტი ჩატარდა 3 DataNodes-ზე და 4 RS-ზე (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads). HBase ვერსია 1.2.0-cdh5.14.2

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

ასევე, ძირითადი დატკეპნა არ ახდენს გავლენას MemStore-ის მდგომარეობაზე; მის დისკზე გადასატანად და კომპაქტურად უნდა გამოიყენოთ flush (connection.getAdmin().flush(TableName.valueOf(tblName))).

8. პარამეტრები და შესრულება

როგორც უკვე აღვნიშნეთ, HBase აჩვენებს თავის უდიდეს წარმატებას იქ, სადაც მას არაფრის გაკეთება არ სჭირდება BulkLoad-ის შესრულებისას. თუმცა, ეს ეხება უმეტეს სისტემებსა და ადამიანებს. თუმცა, ეს ხელსაწყო უფრო შესაფერისია მონაცემთა ნაყარი დიდ ბლოკებში შესანახად, ხოლო თუ პროცესი მოითხოვს წაკითხვისა და ჩაწერის მრავალ კონკურენტულ მოთხოვნას, გამოიყენება ზემოთ აღწერილი Get and Put ბრძანებები. ოპტიმალური პარამეტრების დასადგენად, გაშვება განხორციელდა ცხრილის პარამეტრებისა და პარამეტრების სხვადასხვა კომბინაციით:

• 10 ძაფი ერთდროულად 3-ჯერ ზედიზედ გაუშვა (ამას ძაფების ბლოკი ვუწოდოთ).
• ბლოკში ყველა ძაფის მუშაობის დრო იყო საშუალოდ და ეს იყო ბლოკის მუშაობის საბოლოო შედეგი.
• ყველა თემა მუშაობდა იმავე ცხრილით.
• ძაფის ბლოკის ყოველი დაწყების დაწყებამდე ჩატარდა ძირითადი დატკეპნა.
• თითოეულმა ბლოკმა შეასრულა შემდეგი ოპერაციებიდან მხოლოდ ერთი:

-Დადება
- მიღება
- გააკეთე+განათავსე

• თითოეულმა ბლოკმა შეასრულა თავისი მოქმედების 50 გამეორება.
• ჩანაწერის ბლოკის ზომაა 100 ბაიტი, 1000 ბაიტი ან 10000 ბაიტი (შემთხვევითი).
• ბლოკები გაშვებული იყო მოთხოვნილი გასაღებების სხვადასხვა რაოდენობით (ერთი ან 10).
• ბლოკები გაშვებული იყო სხვადასხვა მაგიდის პარამეტრებში. პარამეტრები შეიცვალა:

— BlockCache = ჩართული ან გამორთულია
— BlockSize = 65 KB ან 16 KB
- ტიხრები = 1, 5 ან 30
— MSLAB = ჩართულია ან გამორთულია

ასე რომ, ბლოკი ასე გამოიყურება:

ა. MSLAB რეჟიმი ჩართულია/გამორთული იყო.
ბ. შეიქმნა ცხრილი, რომლისთვისაც დაყენებული იყო შემდეგი პარამეტრები: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
გ. შეკუმშვა დაყენებული იყო GZ-ზე.
დ. ამოქმედდა 10 თემა ერთდროულად ამ ცხრილში 1/10 ჩასმა/მიღება/მიღება+ჩამოწერის ოპერაციებით 100/1000/10000 ბაიტის ჩანაწერებით, ზედიზედ 50 მოთხოვნაზე (შემთხვევითი ღილაკები).
ე. დ პუნქტი სამჯერ გაიმეორა.
ვ. ყველა ძაფის მუშაობის დრო იყო საშუალოდ.

ყველა შესაძლო კომბინაცია შემოწმდა. პროგნოზირებადია, რომ სიჩქარე შემცირდება ჩანაწერის ზომის გაზრდით, ან ქეშირების გამორთვა გამოიწვევს შენელებას. თუმცა, მიზანი იყო თითოეული პარამეტრის გავლენის ხარისხისა და მნიშვნელობის გაგება, ამიტომ შეგროვებული მონაცემები შეტანილი იქნა ხაზოვანი რეგრესიის ფუნქციის შეყვანაში, რაც შესაძლებელს ხდის მნიშვნელოვნების შეფასებას t- სტატისტიკის გამოყენებით. ქვემოთ მოცემულია ბლოკების შედეგები, რომლებიც ასრულებენ Put ოპერაციებს. კომბინაციების სრული ნაკრები 2*2*3*2*3 = 144 ვარიანტი + 72 ტკ. ზოგიერთი გაკეთდა ორჯერ. აქედან გამომდინარე, ჯამში 216 გარბენია:

ტესტირება ჩატარდა მინი-კლასტერზე, რომელიც შედგებოდა 3 DataNodes და 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads). HBase ვერსია 1.2.0-cdh5.14.2.

ჩასმის ყველაზე მაღალი სიჩქარე 3.7 წამი მიღწეული იქნა გამორთული MSLAB რეჟიმით, მაგიდაზე ერთი დანაყოფით, ჩართულია BlockCache, BlockSize = 16, ჩანაწერები 100 ბაიტი, 10 ცალი პაკეტზე.
ჩასმის ყველაზე დაბალი სიჩქარე 82.8 წმ მიიღეს ჩართული MSLAB რეჟიმით, მაგიდაზე ერთი დანაყოფით, ჩართულია BlockCache, BlockSize = 16, ჩანაწერები 10000 ბაიტი, თითო 1.

ახლა მოდით შევხედოთ მოდელს. ჩვენ ვხედავთ R2-ზე დაფუძნებული მოდელის კარგ ხარისხს, მაგრამ აბსოლუტურად ნათელია, რომ ექსტრაპოლაცია აქ უკუნაჩვენებია. სისტემის ფაქტობრივი ქცევა, როდესაც პარამეტრები იცვლება, არ იქნება წრფივი; ეს მოდელი საჭიროა არა პროგნოზირებისთვის, არამედ იმის გასაგებად, თუ რა მოხდა მოცემულ პარამეტრებში. მაგალითად, აქ Student-ის კრიტერიუმიდან ვხედავთ, რომ BlockSize და BlockCache პარამეტრებს მნიშვნელობა არ აქვს Put ოპერაციისთვის (რომელიც ზოგადად საკმაოდ პროგნოზირებადია):

მაგრამ ის ფაქტი, რომ დანაყოფების რაოდენობის გაზრდა იწვევს შესრულების შემცირებას, გარკვეულწილად მოულოდნელია (ჩვენ უკვე ვნახეთ BulkLoad-ით დანაყოფების რაოდენობის გაზრდის დადებითი გავლენა), თუმცა გასაგებია. პირველ რიგში, დამუშავებისთვის, თქვენ უნდა შექმნათ მოთხოვნა 30 რეგიონში ერთის ნაცვლად და მონაცემთა მოცულობა არ არის ისეთი, რომ ამან მოგება მოიტანოს. მეორეც, მთლიანი ოპერაციული დრო განისაზღვრება ყველაზე ნელი RS-ით და ვინაიდან DataNodes-ის რაოდენობა ნაკლებია RS-ების რაოდენობაზე, ზოგიერთ რეგიონს აქვს ნულოვანი ლოკალიზაცია. მოდით, გადავხედოთ ხუთეულს:

ახლა შევაფასოთ Get Blocks– ის შესრულების შედეგები:

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

დაბოლოს, მოდით გადავხედოთ ბლოკის მოდელს, რომელიც ჯერ შესრულდა მიიღეთ და შემდეგ დავაყენეთ:

აქ ყველა პარამეტრი მნიშვნელოვანია. და ლიდერების შედეგები:

9. დატვირთვის ტესტირება

დაბოლოს, ჩვენ დავიწყებთ მეტ-ნაკლებად ღირსეულ დატვირთვას, მაგრამ ყოველთვის უფრო საინტერესოა, როდესაც რაიმე შედარება გაქვთ. კასანდრას მთავარი დეველოპერი DataStax-ის ვებსაიტზე არის დასკვნები NT რიგი NoSQL საცავები, მათ შორის HBase ვერსია 0.98.6-1. ჩატვირთვა განხორციელდა 40 თემა, მონაცემთა ზომა 100 ბაიტი, SSD დისკები. Read-Modify-Write ოპერაციების ტესტირების შედეგმა აჩვენა შემდეგი შედეგები.

რამდენადაც მე მესმის, კითხვა ჩატარდა 100 ჩანაწერის ბლოკში და 16 HBase კვანძისთვის, DataStax ტესტმა აჩვენა 10 ათასი ოპერაცია წამში.

საბედნიეროა, რომ ჩვენს კლასტერს ასევე აქვს 16 კვანძი, მაგრამ არ არის ძალიან "გაგვიმართლა", რომ თითოეულს აქვს 64 ბირთვი (თემა), ხოლო DataStax ტესტში არის მხოლოდ 4. მეორეს მხრივ, მათ აქვთ SSD დისკები, ჩვენ კი HDD. ან მეტი HBase-ისა და CPU-ის უტილიზაციის ახალი ვერსია დატვირთვის დროს პრაქტიკულად მნიშვნელოვნად არ გაიზარდა (ვიზუალურად 5-10 პროცენტით). თუმცა, შევეცადოთ დავიწყოთ ამ კონფიგურაციის გამოყენება. ცხრილის ნაგულისხმევი პარამეტრები, წაკითხვა ხორციელდება 0-დან 50 მილიონამდე კლავიშების დიაპაზონში შემთხვევით (ანუ, არსებითად ყოველ ჯერზე ახალი). ცხრილი შეიცავს 50 მილიონ ჩანაწერს, დაყოფილია 64 დანაყოფი. გასაღებები ჰეშირებულია crc32-ის გამოყენებით. ცხრილის პარამეტრები ნაგულისხმევია, MSLAB ჩართულია. 40 ძაფების გაშვებით, თითოეული ძაფი კითხულობს 100 შემთხვევით კლავიშებს და დაუყოვნებლივ წერს გენერირებულ 100 ბაიტს უკან ამ კლავიშებზე.

სტენდი: 16 DataNode და 16 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 თემა). HBase ვერსია 1.2.0-cdh5.14.2.

საშუალო შედეგი უახლოვდება 40 ათას ოპერაციას წამში, რაც მნიშვნელოვნად უკეთესია ვიდრე DataStax ტესტში. თუმცა, ექსპერიმენტული მიზნებისთვის, შეგიძლიათ ოდნავ შეცვალოთ პირობები. სავსებით ნაკლებად სავარაუდოა, რომ ყველა სამუშაო განხორციელდეს ექსკლუზიურად ერთ მაგიდაზე და ასევე მხოლოდ უნიკალურ გასაღებებზე. დავუშვათ, რომ არსებობს გასაღებების გარკვეული „ცხელი“ ნაკრები, რომელიც ქმნის ძირითად დატვირთვას. მაშასადამე, შევეცადოთ შევქმნათ დატვირთვა უფრო დიდი ჩანაწერებით (10 KB), ასევე პარტიაში 100, 4 სხვადასხვა ცხრილებში და შევზღუდოთ მოთხოვნილი კლავიშების დიაპაზონი 50 ათასამდე. ქვემოთ მოცემული გრაფიკი გვიჩვენებს 40 თემის გაშვებას, თითოეული ძაფი იკითხება. 100 კლავიშის ნაკრები და დაუყოვნებლივ წერს შემთხვევით 10 KB ამ კლავიშებზე.

სტენდი: 16 DataNode და 16 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 თემა). HBase ვერსია 1.2.0-cdh5.14.2.

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

კითხვა და დაუყოვნებლივ წერა ერთ-ერთი ყველაზე რთული სამუშაო სცენარია HBase-ისთვის. თუ თქვენ გააკეთებთ მხოლოდ მცირე მოთხოვნებს, მაგალითად 100 ბაიტს, აერთიანებთ მათ პაკეტებში 10-50 ათასი ცალი, შეგიძლიათ მიიღოთ ასობით ათასი ოპერაცია წამში და მსგავსი სიტუაციაა მხოლოდ წაკითხვის მოთხოვნებთან დაკავშირებით. აღსანიშნავია, რომ შედეგები რადიკალურად უკეთესია ვიდრე DataStax-ის მიერ მოპოვებული შედეგები, ყველაზე მეტად 50 ათასიანი ბლოკების მოთხოვნის გამო.

სტენდი: 16 DataNode და 16 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 თემა). HBase ვერსია 1.2.0-cdh5.14.2.

10. დასკვნები

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

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

წყარო: www.habr.com