HBase-dən istifadə nəzəriyyəsi və təcrübəsi

Günortanız Xeyir Mənim adım Danil Lipovoy, Sbertech-dəki komandamız HBase-dən əməliyyat məlumatlarının saxlanması kimi istifadə etməyə başladı. Onu öyrənmək zamanı sistemləşdirmək və təsvir etmək istədiyim təcrübə toplandı (ümid edirik ki, çoxları üçün faydalı olacaq). Aşağıdakı bütün təcrübələr HBase 1.2.0-cdh5.14.2 və 2.0.0-cdh6.0.0-beta1 versiyaları ilə aparılmışdır.

1. Ümumi memarlıq
2. HBASE-ə məlumatların yazılması
3. HBASE-dən məlumatların oxunması
4. Məlumatların Keşləşdirilməsi
5. MultiGet/MultiPut verilənlərin toplu işlənməsi
6. Cədvəlləri bölgələrə bölmək üçün strategiya (bölmə)
7. Səhvlərə dözümlülük, sıxlaşdırma və məlumatların yerləşməsi
8. Parametrlər və performans
9. Stress Testi
10. Tapıntılar

1. Ümumi memarlıq

Ehtiyat Master ZooKeeper qovşağında aktiv olanın ürək döyüntüsünü dinləyir və yoxa çıxdıqda masterun funksiyalarını öz üzərinə götürür.

2. Məlumatları HBASE-ə yazın

Əvvəlcə ən sadə hala baxaq - put(rowkey) istifadə edərək cədvələ açar-dəyər obyektinin yazılması. Müştəri əvvəlcə hbase:meta cədvəlini saxlayan Kök Region Serverinin (RRS) harada yerləşdiyini öyrənməlidir. O, bu məlumatı ZooKeeper-dən alır. Bundan sonra o, RRS-ə daxil olur və hbase:meta cədvəlini oxuyur, buradan maraq cədvəlində verilmiş sətir düyməsi üçün məlumatların saxlanmasına cavabdeh olan RegionServer (RS) haqqında məlumat çıxarır. Gələcək istifadə üçün, meta cədvəli müştəri tərəfindən yaddaşda saxlanılır və buna görə də sonrakı zənglər birbaşa RS-ə daha sürətli gedir.

Bundan sonra, RS sorğu qəbul edərək, ilk növbədə onu qəza halında bərpa etmək üçün lazım olan WriteAheadLog-a (WAL) yazır. Sonra məlumatları MemStore-da saxlayır. Bu, müəyyən bir bölgə üçün çeşidlənmiş düymələr dəstini ehtiva edən yaddaşda buferdir. Cədvəl hər birində ayrı-ayrı düymələr dəsti olan bölgələrə (arakəsmələrə) bölünə bilər. Bu, daha yüksək performans əldə etmək üçün bölgələri müxtəlif serverlərdə yerləşdirməyə imkan verir. Ancaq bu ifadənin açıq-aşkar olmasına baxmayaraq, sonradan görəcəyik ki, bu, bütün hallarda işləmir.

MemStore-a giriş yerləşdirdikdən sonra müştəriyə girişin uğurla saxlandığına dair cavab qaytarılır. Ancaq əslində o, yalnız buferdə saxlanılır və yalnız müəyyən bir müddət keçdikdən sonra və ya yeni məlumatlarla doldurulduqdan sonra diskə daxil olur.

"Sil" əməliyyatını yerinə yetirərkən məlumatlar fiziki olaraq silinmir. Onlar sadəcə olaraq silinmiş kimi qeyd olunur və məhvetmə özü 7-ci bənddə daha ətraflı təsvir olunan əsas kompakt funksiyanın çağırılması anında baş verir.

HFile formatında olan fayllar HDFS-də toplanır və vaxtaşırı kiçik kompakt proses işə salınır ki, bu da sadəcə olaraq kiçik faylları heç nəyi silmədən daha böyüklərə birləşdirir. Zaman keçdikcə bu, yalnız məlumatları oxuyarkən ortaya çıxan problemə çevrilir (bir az sonra bu məsələyə qayıdacağıq).

Yuxarıda təsvir edilən yükləmə prosesinə əlavə olaraq, bu verilənlər bazasının bəlkə də ən güclü tərəfi olan daha təsirli bir prosedur var - BulkLoad. Bu, müstəqil olaraq HFiles formalaşdırmaq və onları diskə yerləşdirməyimizdən ibarətdir ki, bu da bizə mükəmməl miqyas almağa və çox layiqli sürətlərə nail olmağa imkan verir. Əslində burada məhdudiyyət HBase deyil, hardware imkanlarıdır. Aşağıda 16 RegionServer və 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 ip), HBase versiyası 1.2.0-cdh5.14.2-dən ibarət klaster üzrə yükləmə nəticələri verilmişdir.

Burada görə bilərsiniz ki, cədvəldə arakəsmələrin (regionların), həmçinin Spark icraçılarının sayını artırmaqla yükləmə sürətinin artmasına nail oluruq. Həmçinin, sürət qeyd həcmindən asılıdır. Böyük bloklar MB/san artımını, kiçik bloklar isə vaxt vahidinə daxil edilmiş qeydlərin sayında artım verir, bütün digər şeylər bərabərdir.

Siz həmçinin eyni anda iki masaya yükləməyə başlaya və ikiqat sürət əldə edə bilərsiniz. Aşağıda görə bilərsiniz ki, 10 KB blokun eyni anda iki cədvələ yazılması hər birində təxminən 600 MB/san sürətlə baş verir (cəmi 1275 MB/san), bu da bir cədvələ yazma sürəti 623 MB/san ilə üst-üstə düşür (bax. yuxarıda № 11)

Lakin 50 KB qeydlərlə ikinci qaçış yükləmə sürətinin bir qədər artdığını göstərir ki, bu da onun limit dəyərlərə yaxınlaşdığını göstərir. Eyni zamanda, nəzərə almaq lazımdır ki, HBASE-nin özündə praktiki olaraq heç bir yük yaradılmır, ondan tələb olunan hər şey əvvəlcə hbase:meta-dan məlumat vermək və HFiles-i astarladıqdan sonra BlockCache məlumatlarını yenidən qurun və yadda saxlayın. Disk üçün MemStore buferi, boş deyilsə.

3. HBASE-dən məlumatların oxunması

Əgər güman etsək ki, müştəri artıq hbase:meta-dan bütün məlumatlara malikdir (bax 2-ci bənd), onda sorğu birbaşa tələb olunan açarın saxlandığı RS-ə gedir. Birincisi, axtarış MemCache-də aparılır. Orada məlumatların olub-olmamasından asılı olmayaraq, axtarış BlockCache buferində və lazım olduqda HFiles-da da aparılır. Əgər məlumat faylda tapılıbsa, o, BlockCache-ə yerləşdirilir və növbəti sorğuda daha tez qaytarılacaq. Bloom filtrinin istifadəsi sayəsində HFile-da axtarış nisbətən sürətlidir, yəni. az miqdarda məlumat oxuduqdan sonra dərhal bu faylda tələb olunan açarın olub-olmadığını müəyyənləşdirir və əgər yoxdursa, növbəti birinə keçir.

Bu üç mənbədən məlumat aldıqdan sonra RS cavab yaradır. Xüsusilə, müştəri versiyanı tələb edərsə, o, eyni anda bir obyektin bir neçə tapılmış versiyasını ötürə bilər.

4. Məlumatların keşləşdirilməsi

MemStore və BlockCache buferləri ayrılmış yığın RS yaddaşının 80%-ə qədərini tutur (qalanı RS xidmət tapşırıqları üçün qorunur). Tipik istifadə rejimi proseslərin eyni məlumatları yazması və dərhal oxumasıdırsa, BlockCache-i azaltmaq və MemStore-u artırmaq məna kəsb edir, çünki Məlumatların yazılması oxumaq üçün önbelleğe daxil olmadıqda, BlockCache daha az istifadə ediləcək. BlockCache buferi iki hissədən ibarətdir: LruBlockCache (həmişə yığında) və BucketCache (adətən yığından kənarda və ya SSD-də). BucketCache çoxlu oxu sorğuları olduqda və LruBlockCache-ə uyğun gəlmədikdə istifadə edilməlidir ki, bu da Garbage Collector-un aktiv işinə səbəb olur. Eyni zamanda, oxunan keşdən istifadə etməklə performansın köklü artımını gözləməməlisiniz, lakin biz buna 8-ci bənddə qayıdacayıq.

Bütün RS üçün bir BlockCache var və hər cədvəl üçün bir MemStore var (hər Sütun Ailəsi üçün bir).

Kimi təsvir edilmişdir nəzəri olaraq, yazarkən verilənlər önbelleğe daxil olmur və həqiqətən də cədvəl üçün CACHE_DATA_ON_WRITE və RS üçün “Yazmaqda DATA Cache” parametrləri yanlış olaraq təyin edilir. Bununla belə, praktikada məlumatı MemStore-a yazsaq, sonra onu diskə silsək (beləliklə, onu təmizləyirik), sonra yaranan faylı silin, sonra get sorğusunu yerinə yetirməklə məlumatları uğurla qəbul edəcəyik. Üstəlik, BlockCache-ni tamamilə söndürsəniz və cədvəli yeni məlumatlarla doldursanız, sonra MemStore-u diskə sıfırlasanız, onları silsəniz və başqa sessiyadan tələb etsəniz belə, onlar hələ də haradansa bərpa olunacaq. Beləliklə, HBase təkcə məlumatları deyil, həm də sirli sirləri saxlayır.

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

"Oxunanda DATA Cache" parametri yanlış olaraq təyin edilib. Hər hansı bir fikriniz varsa, şərhlərdə müzakirə etməyə xoş gəlmisiniz.

5. MultiGet/MultiPut verilənlərin toplu işlənməsi

Tək sorğuların işlənməsi (Get/Put/Delete) kifayət qədər bahalı əməliyyatdır, ona görə də mümkünsə, onları Siyahıya və ya Siyahıya birləşdirməlisiniz ki, bu da sizə əhəmiyyətli performans artımı əldə etməyə imkan verir. Bu xüsusilə yazma əməliyyatı üçün doğrudur, lakin oxuyarkən aşağıdakı tələ var. Aşağıdakı qrafik MemStore-dan 50 qeydin oxunma vaxtını göstərir. Oxuma bir ipdə aparıldı və üfüqi ox sorğudakı düymələrin sayını göstərir. Burada görə bilərsiniz ki, bir sorğuda min düymə artırıldıqda icra müddəti azalır, yəni. sürəti artır. Bununla belə, MSLAB rejimi standart olaraq aktivləşdirildikdə, bu hədddən sonra performansda köklü azalma başlayır və qeyddəki məlumatların miqdarı nə qədər çox olarsa, əməliyyat müddəti bir o qədər uzun olur.

Testlər virtual maşında, 8 nüvəli, HBase 2.0.0-cdh6.0.0-beta1 versiyasında aparılıb.

MSLAB rejimi yeni və köhnə nəsil məlumatların qarışması nəticəsində yaranan yığın parçalanmasını azaltmaq üçün nəzərdə tutulmuşdur. Çözüm kimi, MSLAB işə salındıqda, məlumatlar nisbətən kiçik hüceyrələrə (parçalara) yerləşdirilir və parçalara bölünür. Nəticədə, tələb olunan məlumat paketindəki həcm ayrılmış ölçüdən artıq olduqda, performans kəskin şəkildə aşağı düşür. Digər tərəfdən, bu rejimi söndürmək də məqsədəuyğun deyil, çünki məlumatların intensiv işlənməsi anlarında GC səbəbiylə dayanmalara səbəb olacaqdır. Yaxşı bir həll, oxumaqla eyni vaxtda put vasitəsilə aktiv yazma vəziyyətində hüceyrə həcmini artırmaqdır. Qeyd etmək lazımdır ki, qeyddən sonra MemStore-u diskə sıfırlayan flush əmrini yerinə yetirsəniz və ya BulkLoad-dan istifadə edərək yükləsəniz, problem yaranmır. Aşağıdakı cədvəl göstərir ki, MemStore-dan daha böyük (və eyni miqdarda) məlumat üçün sorğular yavaşlama ilə nəticələnir. Bununla belə, parça ölçüsünü artırmaqla biz emal vaxtını normal vəziyyətə qaytarırıq.

Parça ölçüsünü artırmaqla yanaşı, məlumatların bölgələrə bölünməsi kömək edir, yəni. masanın parçalanması. Bu, hər bölgəyə daha az sorğunun gəlməsi ilə nəticələnir və əgər onlar hücrəyə uyğun gəlsə, cavab yaxşı olaraq qalır.

6. Cədvəllərin bölgələrə bölünməsi strategiyası (bölmə)

HBase açar-dəyər saxlama yeri olduğundan və bölmələr açarla həyata keçirildiyi üçün məlumatları bütün bölgələr üzrə bərabər şəkildə bölmək son dərəcə vacibdir. Məsələn, belə bir cədvəli üç hissəyə bölmək verilənlərin üç bölgəyə bölünməsi ilə nəticələnəcək:

Daha sonra yüklənmiş məlumatlar, məsələn, çoxu eyni rəqəmlə başlayan uzun dəyərlərə bənzəyirsə, bu, kəskin yavaşlamaya səbəb olur, məsələn:

1000001
1000002
...
1100003

Düymələr bayt massivi kimi saxlandığından, onların hamısı eyni şəkildə başlayacaq və bu düymələr diapazonunu saxlayan eyni №1 bölgəyə aid olacaq. Bir neçə bölmə strategiyası var:

HexStringSplit – Açarı "00000000" => "FFFFFFFF" diapazonunda onaltılıq kodlanmış sətirə çevirir və solda sıfırlarla doldurur.

UniformSplit – Açarı "00" => "FF" diapazonunda onaltılıq kodlaşdırma və sağda sıfırlarla doldurma ilə bayt massivinə çevirir.

Bundan əlavə, siz bölmə üçün istənilən diapazonu və ya düymələr dəstini təyin edə və avtomatik bölməni konfiqurasiya edə bilərsiniz. Bununla belə, ən sadə və ən təsirli yanaşmalardan biri UniformSplit və hash birləşməsinin istifadəsidir, məsələn, açarı CRC32(rowkey) funksiyası və sətir düyməsinin özü vasitəsilə işlədən baytların ən əhəmiyyətli cütü:

hash + rowkey

Sonra bütün məlumatlar regionlar üzrə bərabər paylanacaq. Oxuyarkən ilk iki bayt sadəcə atılır və orijinal açar qalır. RS həmçinin regiondakı məlumatların və açarların miqdarına nəzarət edir və limitlər keçərsə, onu avtomatik olaraq hissələrə bölür.

7. Arızaya dözümlülük və məlumatların lokalizasiyası

Hər bir açar dəsti üçün yalnız bir bölgə məsul olduğundan, RS qəzaları və ya istismardan çıxarılması ilə bağlı problemlərin həlli bütün lazımi məlumatları HDFS-də saxlamaqdır. RS düşdükdə usta bunu ZooKeeper qovşağında ürək döyüntüsünün olmaması ilə aşkar edir. Sonra xidmət edilən bölgəni başqa bir RS-ə təyin edir və HFiles paylanmış fayl sistemində saxlandığından, yeni sahib onları oxuyur və məlumatlara xidmət etməyə davam edir. Bununla belə, məlumatların bir hissəsi MemStore-da ola biləcəyindən və HFiles-a daxil olmaq üçün vaxt olmadığından, əməliyyatların tarixini bərpa etmək üçün HDFS-də də saxlanılan WAL istifadə olunur. Dəyişikliklər tətbiq edildikdən sonra RS sorğulara cavab verə bilir, lakin hərəkət bəzi məlumatların və onlara xidmət edən proseslərin müxtəlif qovşaqlarda başa çatmasına səbəb olur, yəni. yerlilik azalır.

Problemin həlli əsas sıxılmadır - bu prosedur faylları onlar üçün məsul olan qovşaqlara (bölgələrinin yerləşdiyi yerə) köçürür, nəticədə bu prosedur zamanı şəbəkə və disklərdə yük kəskin şəkildə artır. Bununla belə, gələcəkdə məlumatlara çıxış nəzərəçarpacaq dərəcədə sürətlənir. Bundan əlavə, major_compaction bütün HFiles-ın region daxilində bir faylda birləşməsini həyata keçirir və həmçinin cədvəl parametrlərindən asılı olaraq məlumatları təmizləyir. Məsələn, siz saxlanılmalı olan obyektin versiyalarının sayını və ya obyektin fiziki olaraq silinməsindən sonra istifadə müddətini təyin edə bilərsiniz.

Bu prosedur HBase-in işinə çox müsbət təsir göstərə bilər. Aşağıdakı şəkil aktiv məlumatların qeydə alınması nəticəsində performansın necə aşağı düşdüyünü göstərir. Burada 40 mövzunun bir cədvələ necə yazdığını və 40 mövzunun eyni vaxtda məlumatları oxuduğunu görə bilərsiniz. Yazı mövzuları digər mövzular tərəfindən oxunan daha çox HFiles yaradır. Nəticədə, getdikcə daha çox məlumat yaddaşdan silinməlidir və nəticədə GC işə başlayır ki, bu da praktiki olaraq bütün işləri iflic edir. Əsas sıxlaşdırmanın işə salınması nəticədə yaranan zibilin təmizlənməsinə və məhsuldarlığın bərpasına səbəb oldu.

Test 3 DataNode və 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 ip) üzərində aparılıb. HBase versiyası 1.2.0-cdh5.14.2

Qeyd etmək lazımdır ki, məlumatların aktiv şəkildə yazıldığı və oxunduğu "canlı" cədvəldə əsas sıxılma işə salındı. İnternetdə bunun məlumatları oxuyarkən səhv cavab verə biləcəyinə dair bir bəyanat var idi. Yoxlamaq üçün yeni məlumatlar yaradan və cədvələ yazan bir proses işə salındı. Bundan sonra dərhal oxudum və alınan dəyərin yazılanlarla üst-üstə düşdüyünü yoxladım. Bu proses davam edərkən, əsas sıxılma təxminən 200 dəfə aparıldı və heç bir nasazlıq qeydə alınmadı. Ola bilsin ki, problem nadir hallarda və yalnız yüksək yükləmə zamanı ortaya çıxır, ona görə də yazı və oxu proseslərini planlaşdırıldığı kimi dayandırmaq və bu cür GC azalmalarının qarşısını almaq üçün təmizləmə aparmaq daha təhlükəsizdir.

Həmçinin, əsas sıxılma MemStore-un vəziyyətinə təsir göstərmir, onu diskə köçürmək və sıxlaşdırmaq üçün siz flush (connection.getAdmin().flush(TableName.valueOf(tblName))) istifadə etməlisiniz.

8. Parametrlər və performans

Artıq qeyd edildiyi kimi, HBase ən böyük uğurunu BulkLoad-ı yerinə yetirərkən heç nə etməyə ehtiyac duymadığı yerdə göstərir. Ancaq bu, əksər sistemlərə və insanlara aiddir. Bununla belə, bu alət məlumatların böyük bloklarda toplu şəkildə saxlanması üçün daha uyğundur, halbuki proses bir neçə rəqabətli oxumaq və yazma sorğularını tələb edirsə, yuxarıda təsvir olunan Get və Qoy əmrləri istifadə olunur. Optimal parametrləri müəyyən etmək üçün masa parametrləri və parametrlərinin müxtəlif birləşmələri ilə işə salındılar:

• Ardıcıl olaraq 10 dəfə 3 mövzu işə salındı ​​(bunu mövzular bloku adlandıraq).
• Blokdakı bütün iplərin işləmə müddəti orta hesablanmış və blokun işinin yekun nəticəsi olmuşdur.
• Bütün mövzular eyni cədvəllə işləyirdi.
• İp blokunun hər başlamazdan əvvəl böyük bir sıxılma aparıldı.
• Hər bir blok aşağıdakı əməliyyatlardan yalnız birini yerinə yetirdi:

-Qoy
-Alın
-Al+Qoy

• Hər blok öz əməliyyatının 50 iterasiyasını yerinə yetirdi.
• Yazının blok ölçüsü 100 bayt, 1000 bayt və ya 10000 baytdır (təsadüfi).
• Bloklar müxtəlif sayda tələb olunan düymələrlə işə salındı ​​(ya bir açar, ya da 10).
• Bloklar müxtəlif masa parametrləri altında işlədilib. Parametrlər dəyişdirildi:

— BlockCache = aktiv və ya söndürülür
— BlockSize = 65 KB və ya 16 KB
— Bölmələr = 1, 5 və ya 30
— MSLAB = aktiv və ya qeyri-aktiv

Beləliklə, blok belə görünür:

a. MSLAB rejimi yandırıldı/söndü.
b. Aşağıdakı parametrlərin təyin olunduğu cədvəl yaradıldı: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
c. Sıxılma GZ olaraq təyin edildi.
d. 10/1/10 baytlıq qeydlərlə bu cədvəldə 100/1000 put/get/get+put əməliyyatlarını yerinə yetirməklə eyni vaxtda 10000 ip işə salındı, ardıcıl olaraq 50 sorğu yerinə yetirildi (təsadüfi düymələr).
e. d nöqtəsi üç dəfə təkrarlandı.
f. Bütün iplərin işləmə müddəti orta hesablanmışdır.

Bütün mümkün birləşmələr sınaqdan keçirildi. Proqnozlaşdırıla bilər ki, rekord ölçü artdıqca sürət azalacaq və ya keşləməni söndürmək yavaşlamağa səbəb olacaq. Bununla belə, məqsəd hər bir parametrin təsirinin dərəcəsini və əhəmiyyətini başa düşmək idi, buna görə də toplanmış məlumatlar xətti reqressiya funksiyasının girişinə daxil edilmişdir ki, bu da t-statistikadan istifadə edərək əhəmiyyətini qiymətləndirməyə imkan verir. Aşağıda Put əməliyyatlarını yerinə yetirən blokların nəticələri verilmişdir. Kombinasiyaların tam dəsti 2*2*3*2*3 = 144 seçim + 72 tk. bəziləri iki dəfə edilib. Beləliklə, cəmi 216 qaçış var:

Sınaq 3 DataNode və 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 ip) ibarət mini-klasterdə aparılıb. HBase versiyası 1.2.0-cdh5.14.2.

3.7 saniyəlik ən yüksək daxiletmə sürəti MSLAB rejimi söndürüldükdə, bir bölmə ilə bir masada, BlockCache aktivləşdirilmiş, BlockSize = 16, 100 bayt qeydlər, paket başına 10 ədəd ilə əldə edilmişdir.
82.8 saniyəlik ən aşağı daxiletmə sürəti MSLAB rejimi aktiv olduqda, BlockCache aktivləşdirilmiş, BlockSize = 16, hər biri 10000 bayt olmaqla bir bölmə ilə masada əldə edilmişdir.

İndi modelə baxaq. R2 əsasında modelin yaxşı keyfiyyətini görürük, lakin burada ekstrapolyasiyanın əks göstəriş olduğu tamamilə aydındır. Parametrlər dəyişdikdə sistemin faktiki davranışı xətti olmayacaq, bu model proqnozlar üçün deyil, verilmiş parametrlər daxilində baş verənləri başa düşmək üçün lazımdır. Məsələn, burada Tələbə meyarından görürük ki, BlockSize və BlockCache parametrləri Put əməliyyatı üçün əhəmiyyət kəsb etmir (bu, ümumiyyətlə, proqnozlaşdırıla biləndir):

Lakin arakəsmələrin sayının artırılmasının performansın azalmasına səbəb olması bir qədər gözlənilməzdir (BulkLoad ilə arakəsmələrin sayının artırılmasının müsbət təsirini artıq görmüşük), başa düşülən olsa da. Birincisi, emal üçün bir əvəzinə 30 bölgəyə sorğu yaratmalısınız və məlumatların həcmi o qədər də deyil ki, bu, qazanc gətirsin. İkincisi, ümumi əməliyyat müddəti ən yavaş RS ilə müəyyən edilir və DataNodların sayı RS-lərin sayından az olduğundan, bəzi bölgələrdə sıfır lokalizasiya var. Yaxşı, ilk beşliyə baxaq:

İndi Get bloklarının icrasının nəticələrini qiymətləndirək:

Bölmələrin sayı əhəmiyyətini itirdi, bu, ehtimal ki, məlumatların yaxşı saxlanması və oxunan yaddaşın ən əhəmiyyətli (statistik) parametr olması ilə izah olunur. Təbii ki, sorğuda mesajların sayını artırmaq da performans üçün çox faydalıdır. Ən yüksək xallar:

Yaxşı, nəhayət, əvvəlcə alın və sonra qoyulan blokun modelinə baxaq:

Burada bütün parametrlər əhəmiyyətlidir. Və liderlərin nəticələri:

9. Yük testi

Yaxşı, nəhayət, biz daha çox və ya daha az layiqli bir yük açacağıq, lakin müqayisə etmək üçün bir şeyiniz olduqda həmişə daha maraqlıdır. Cassandra-nın əsas inkişaf etdiricisi olan DataStax-ın saytında var tapıntılar HBase versiyası 0.98.6-1 daxil olmaqla, bir sıra NoSQL anbarlarının NT. Yükləmə 40 mövzu, məlumat ölçüsü 100 bayt, SSD disklər tərəfindən həyata keçirildi. Oxu-Dəyişdir-Yaz əməliyyatlarının sınaqdan keçirilməsinin nəticəsi aşağıdakı nəticələri göstərdi.

Anladığım qədər, oxu 100 qeyddən ibarət bloklarda aparıldı və 16 HBase qovşağı üçün DataStax testi saniyədə 10 min əməliyyat performans göstərdi.

Sevindirici haldır ki, bizim klasterimizdə də 16 qovşaq var, lakin hər birində 64 nüvənin (yivlərin) olması çox da “şanslı” deyil, DataStax testində isə cəmi 4 var. Digər tərəfdən, onların SSD diskləri var, bizdə isə HDD-lər var. və ya daha çox HBase-in yeni versiyası və yükləmə zamanı CPU istifadəsi praktiki olaraq əhəmiyyətli dərəcədə artmadı (vizual olaraq 5-10 faiz). Bununla belə, bu konfiqurasiyadan istifadə etməyə çalışaq. Defolt cədvəl parametrləri, oxuma təsadüfi olaraq 0-dan 50 milyona qədər əsas diapazonda həyata keçirilir (yəni hər dəfə yenidir). Cədvəldə 50 bölməyə bölünmüş 64 milyon qeyd var. Açarlar crc32 istifadə edərək hashing edilir. Cədvəl parametrləri standartdır, MSLAB aktivdir. 40 başlığı işə salaraq, hər bir ip 100 təsadüfi düymələr dəstini oxuyur və yaradılan 100 baytı dərhal bu düymələrə yazır.

Stend: 16 DataNode və 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 ip). HBase versiyası 1.2.0-cdh5.14.2.

Orta nəticə saniyədə 40 min əməliyyata yaxındır ki, bu da DataStax testindən xeyli yaxşıdır. Ancaq eksperimental məqsədlər üçün şərtləri bir az dəyişə bilərsiniz. Bütün işlərin yalnız bir masada, həm də yalnız unikal açarlarda aparılacağı ehtimalı azdır. Tutaq ki, əsas yükü yaradan müəyyən "isti" düymələr dəsti var. Buna görə də, daha böyük qeydlərlə (10 KB), həmçinin 100-lük partiyalarda, 4 müxtəlif cədvəldə və tələb olunan açarların diapazonunu 50 minlə məhdudlaşdırmağa çalışaq.Aşağıdakı qrafik 40 mövzunun işə salınmasını göstərir, hər mövzu oxuyur 100 düymə dəsti və dərhal bu düymələrə təsadüfi 10 KB yazır.

Stend: 16 DataNode və 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 ip). HBase versiyası 1.2.0-cdh5.14.2.

Yükləmə zamanı, yuxarıda göstərildiyi kimi, əsas sıxılma bir neçə dəfə işə salındı, bu prosedur olmadan performans tədricən pisləşəcək, lakin icra zamanı əlavə yük də yaranır. Zəifləmələr müxtəlif səbəblərdən yaranır. Bəzən mövzular işləməyi başa vurdu və yenidən işə salınarkən fasilə yarandı, bəzən üçüncü tərəf proqramları klasterdə yük yaratdı.

Oxumaq və dərhal yazmaq HBase üçün ən çətin iş ssenarilərindən biridir. Əgər siz yalnız kiçik put sorğuları etsəniz, məsələn, 100 bayt, onları 10-50 min ədəd paketlərə birləşdirsəniz, saniyədə yüz minlərlə əməliyyat əldə edə bilərsiniz və vəziyyət yalnız oxunan sorğularla oxşardır. Nəticələrin DataStax tərəfindən əldə edilənlərdən köklü şəkildə daha yaxşı olduğunu qeyd etmək lazımdır, ən çox 50 minlik bloklardakı sorğulara görə.

Stend: 16 DataNode və 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 ip). HBase versiyası 1.2.0-cdh5.14.2.

10. Nəticələr

Bu sistem olduqca çevik şəkildə konfiqurasiya edilmişdir, lakin çox sayda parametrin təsiri hələ də naməlum olaraq qalır. Onlardan bəziləri sınaqdan keçirildi, lakin nəticədə ortaya çıxan test dəstinə daxil edilmədi. Məsələn, ilkin təcrübələr təsadüfi yaradılan məlumatlar üçün başa düşülən qonşu hüceyrələrdən alınan dəyərlərdən istifadə edərək məlumatları kodlayan DATA_BLOCK_ENCODING kimi parametrin əhəmiyyətsiz olduğunu göstərdi. Çox sayda dublikat obyektlərdən istifadə etsəniz, qazanc əhəmiyyətli ola bilər. Ümumiyyətlə, deyə bilərik ki, HBase kifayət qədər ciddi və yaxşı düşünülmüş verilənlər bazası təəssüratı yaradır ki, bu da böyük verilənlər blokları ilə əməliyyatlar apararkən kifayət qədər məhsuldar ola bilər. Xüsusən də oxuma və yazma proseslərini vaxtında ayırmaq mümkün olarsa.

Fikrinizcə kifayət qədər açıqlanmayan bir şey varsa, sizə daha ətraflı məlumat verməyə hazıram. Sizi təcrübənizi bölüşməyə və ya bir şeylə razılaşmadığınız təqdirdə müzakirə etməyə dəvət edirik.

Mənbə: www.habr.com