HBase'i teooria ja praktika

Tere päevast! Mina olen Danil Lipovoy, meie meeskond Sbertechi's on hakanud HBase'i kasutama operatiivandmete salvestamiseks. Selle uurimise käigus on kogunenud kogemusi, mida soovisime süsteematisteerida ja kirjeldada (loodame, et sellest on paljudele abi). Kõik allpool toodud eksperimendid viidi läbi versioonidega HBase 1.2.0-cdh5.14.2 ja 2.0.0-cdh6.0.0-beta1.

1. Üldine arhitektuur
2. Andmete salvestamine HBASE-s
3. Andmete lugemine HBASE-st
4. Andmete vahemälu
5. Andmete partii töötlemine MultiGet/MultiPut
6. Tabelite jagamise strateegia piirkondadeks (sharding)
7. Veakindlus, kompakteerimine ja andmete kohalikkus
8. Seaded ja jõudlus
9. Koormuse testimine
10. Järeldused

1. Üldine arhitektuur

Varu Master kuulab aktiivse sõlme ZooKeeper'is heartbeat'i ja kaotamise korral võtab Master'i funktsioonid enda kanda.

2. Andmete salvestamine HBASE-s

Alustame kõige lihtsama juhtumiga – võtme-väärtuse objekti salvestamine tabelisse kasutades put(rowkey). Klient peab esmalt kindlaks tegema, kus asub juure piirkonna server (Root Region Server — RRS), mis salvestab tabelit hbase:meta. Selle teabe saab ta ZooKeeper'ist. Seejärel pöördub ta RRS-i poole ja loeb tabelit hbase:meta, millest ta tõmbab välja teabe, milline RegionServer (RS) vastutab antud võtme rowkey seotud andmete salvestamise eest huvipakkuvas tabelis. Jätkuva kasutamise eesmärgil vahemälu tabelit kliendile ja seega lähevad edasised päringud kiiremini, otseselt RS-i.

Seejärel kirjutab RS, saades päringu, esmalt selle WriteAheadLog'i (WAL), mis on vajalik taastumiseks, kui midagi läheb valesti. Seejärel salvestab ta andmed MemStore'i. See on mälu puhver, mis sisaldab antud piirkonna sorteeritud võtmete kogumit. Tabel võib jagada piirkondadeks (partitsioonideks), millest igaüks sisaldab üksteisega mitte ühtivat võtmete kogumit. See võimaldab piirkondi erinevates serverites paigutades saavutada kõrgemat jõudlust. Siiski, hoolimata selle väite ilmsusest, näeme hiljem, et see ei toimi kõikides olukordades.

Pärast salvestuse paigutamist MemStore'i saab klient vastuse, et salvestus on edukalt tehtud. Samas hoitakse seda tegelikult ainult puhvers ja jõuab kettale alles pärast teatud aja möödumist või selle täitumisel uutega.

Tehtava "Delete" käigus ei toimu füüsilist andmete kustutamist. Need märgitakse lihtsalt kui kustutatud ja tegelik hävitamine toimub major compact funktsiooni käivitamise hetkel, millest on rohkem juttu punktis 7.

HFile formaadis failid kogunevad HDFS-s ja aeg-ajalt käivitatakse minor compact protsess, mis lihtsalt liidab väikesed failid suuremateks, midagi kustutamata. Aja jooksul muutub see probleemiks, mis avaldub ainult andmete lugemisel (sellest räägime natuke hiljem).

Lisaks ülaltoodud andmete laadimise protsessile on olemas palju tõhusam protseduur, mille keskmes on brändi kõige tugevam külg – BulkLoad. See seisneb selles, et me ise vormistame HFiles ja paneme need kettale, mis võimaldab suurepärast skaleerimist ning saavutada üsna korralikke kiirusnumbreid. Sisuliselt on piiranguks mitte HBase, vaid riistvara võimalused. Allpool on toodud laadimistulemused klastrilt, mis koosneb 16 RegionServerist ja 16 NodeManager YARN-ist (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 niidid), HBase versioon 1.2.0-cdh5.14.2.

Siit on näha, et partitsioonide (regioonide) arvu ning Spark'i eksekutorite suurendamisega saame laadimiskiiruse suurenemise. Samuti sõltub kiirus kirjutamise mahust. Suured plokid annavad tõusu MB/sek mõõtmisel, väiksemad aga sisse kirjutatud kirjade arvu ajas, kui kõik muud tingimused on võrdsed.

Samuti saab käivitada laadimise kahes tabelis samaaegselt ning saavutada kiiruskahekordistumine. Allpool on nähtav, et 10 KB plokkide kirjutamine kahte tabelisse toimub kiirusel umbes 600 Mb/sek igasse (kokku 1275 Mb/sek), mis vastab ühte tabelisse kirjutamise kiirusel 623 MB/sek (vt punkt 11 ülevale).

Kuid teine käivitamine 50 KB kirjete kirjutamisega näitab, et laadimiskiirus tõuseb juba minimaalsetes määrades, mis viitab sellele, et lähme piirväärtuste suunas. Pealegi tuleb arvestada, et HBASE-le endale ei tekkida praktiliselt mingit koormust; kõik, mis sellest nõutakse, on esmalt andmete andmine hbase:meta-st ja seejärel HFiles'i lisamisel BlockCache'i tühjendamine ning MemStore'i buffri salvestamine kettale, kui see pole tühi.

3. Andmete lugemine HBASE-st

Kui eeldada, et kogu teave hbase:meta on juba kliendil olemas (vt p.2), siis läheb päring kohe sellele RS-ile, kus vajalik võti asub. Esiteks toimub otsing MemCache'is. Sõltumata sellest, kas seal on andmeid või mitte, toimub otsing ka BlockCache'i puhveres ja vajadusel HFiles'is. Kui andmed leiti failist, salvestatakse need BlockCache'i ja järgmise päringu korral tagastatakse need kiiremini. Otsing HFiles'is toimub suhteliselt kiiresti, kasutades Bloomi filtrit, mis tähendab, et lugedes väikest andmehulka, määrab ta kohe, kas see fail sisaldab vajalikku võtit ja kui ei, siis liikuda järgmise juurde.

Saades andmed neist kolmest allikast, vormib RS vastuse. Eriti võib ta edastada mitu leitud objekti versiooni, kui klient küsis versioonisust.

4. Andmete vahemälu

MemStore'i ja BlockCache'i puhvritäiendus moodustab kuni 80% eraldatud on-heap mälu RS jaoks (ülejäänud on reserveeritud RS teenuste jaoks). Kui tüüpiline kasutusrežiim on selline, et protsessid kirjutavad ja loevad kohe neid samu andmeid, siis on mõistlik vähendada BlockCache'i ja suurendada MemStore'i, kuna kirjutades ei pääse andmed lugemiseks puhvri, seega toimub BlockCache'i kasutamine harvem. BlockCache puhver koosneb kahest osast: LruBlockCache (alati on-heap) ja BucketCache (tavaliselt off-heap või SSD-l). BucketCache'i tuleks kasutada, kui on väga palju lugemisepäringuid ja need ei mahu LruBlockCache'i, mis toob kaasa aktiivse Garbage Collectori töö. Samas ei tasu oodata radikaalset jõudluse kasvu lugemisvahemälu kasutamiselt, kuid sellest räägime veel p. 8.

BlockCache on kogu RS-i kaupa, samas on iga tabeli jaoks oma MemStore (iga Column Family jaoks üks).

Kuidas kirjeldatud teoorias, kui andmed kirjutatakse vahemällu, siis need ei jõua sinna ja tõepoolest, sellised parameetrid CACHE_DATA_ON_WRITE tabeli jaoks ja "Cache DATA on Write" RS-i jaoks on seatud väärtusele false. Kuid praktikast, kui kirjutada andmed MemStore'i, seejärel kustutada see kettale (puhastades selguse mõttes), seejärel eemaldada saadud fail, siis tehes get päringu saame andmed edukalt. Lisaks, isegi kui täielikult blokeerida BlockCache ja täita tabel uute andmetega, siis saavutades MemStore'i väljalülitamise kettale, kustutades need ja küsides teises sessioonis, need ikka kuskilt saadakse. Seega HBase hoiab endas mitte ainult andmeid, vaid ka salapäraseid mõistatusi.

hbase(main):001:0> create 'ns:magic', 'cf'
Loodud tabel ns:magic
Kestis 1.1533 sekundit
hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'
Kestis 0.2610 sekundit
hbase(main):003:0> flush 'ns:magic'
Kestis 0.6161 sekundit
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

Parameeter „Cache DATA on Read” on seadistatud vale. Kui teil on ideid, siis teretulnud arutama seda kommentaarides.

5. Andmete paketiline töötlemine MultiGet/MultiPut

Üksikute päringute (Get/Put/Delete) töötlemine on üsna kallis operatsioon, seetõttu tuleks neid võimalusel ühendatud Listi või Listide alla koondada, mis toob kaasa märkimisväärse jõudluse kasvu. Eriti kehtib see kirjutamise operatsioonide jaoks, kuid lugemise puhul on järgmine peidetud karikas. Alloleval graafikul on näidatud 50 000 märkme lugemise aega MemStores. Lugemine toimus ühes olles ja horisontaalsel teljel on näidatud päringu võtmete arv. Siit on näha, et kui võtmete arv ühes päringus suureneb kuni tuhandeni, siis täitmisaja kestus langeb, st kiirus suureneb. Kuid vaike- MSLABi režiimi aktiveerimisel hakkab pärast seda piiri jõudluse järsult langema, kusjuures andmete maht kirje sisse mõjutab kestust.

Testid viidi läbi virtuaalkeskkonnas, 8 tuuma, HBase versioon 2.0.0-cdh6.0.0-beta1.

MSLAB režiim on loodud vähendama heap'i fragmentatsiooni, mis tuleneb uue ja vana põlvkonna andmete segunemisest. Probleemi lahendusena andmed MSLAB režiimi aktiveerimisel paigutatakse suhteliselt väikestesse rakkudesse (chunk) ja töödeldakse portsjonitena. Tulemuseks on see, et kui küsitud andmepaketi maht ületab reserveeritud suuruse, siis jõudlus langeb järsult. Teiselt poolt ei ole antud režiimi väljalülitamine soovitatav, kuna see võib põhjustada peatuseid GC tõttu intensiivse andmetöötluse hetkedel. Hea lahendus on suurendada rakuga mahte, kui kirjutamist teostatakse put'i kaudu samal ajal lugemisega. Tuleb märkida, et see probleem ei esine, kui pärast kirjutamist antakse käsk flush, mis kirjutab MemStore'i kettale, või kui laadimist teostatakse BulkLoad abil. Allolevas tabelis on näidatud, et päringud MemStore'ist suuremate (ja sama arvu) andmete puhul põhjustavad aeglustumist. Kuid suurendades chunksize'i, toob oleme töötluse aega normaali juurde.

Lisaks chunksize'i suurendamisele aitab andmete jagamine regioonide kaupa, st tabelite jagamine. See vähendab igale regioonile jõudvate päringute arvu ning kui need on lahtris, siis jääb vastus hea.

6. Tabelite jagamise strateegia regioonide vahel (jagamine)

Kuna HBase on võtme-väärtuse salvestus ja jaotamine toimub võtme järgi, on väga oluline jagada andmed ühtlaselt kõikide regioonide vahel. Näiteks teeb kolme ossa jagamine, et andmed jagatakse kolme regiooniks:

Mõnikord toob see kaasa järsu aeglustumise, kui hiljem laaditavad andmed on näiteks long väärtustes, mis enamikul juhtudel algavad sama numbriga, näiteks:

1000001
1000002
…
1100003

Kuna võtmed salvestatakse baitide massiivina, hakkavad kõik nad samamoodi ja kuuluvad ühte regioon #1, mis salvestab selle võtme vahemiku. On mitmeid jagamise strateegiaid:

HexStringSplit – Muunib võtme stringiks, kasutades kuuesüsteemi kodeeringut vahemikus "00000000" => "FFFFFFFF", täiendades vasakule nullidega.

UniformSplit – Muunib võtme baitide massiiviks, kasutades kuuesüsteemi kodeeringut vahemikus "00" => "FF", täiendades paremale nullidega.

Lisaks saab määrata igasuguseid vahemikke või võtmete kogumeid jagamiseks ja seadistada automaatse jagamise. Siiski on üks lihtsamaid ja tõhusamaid lähenemisviise UniformSplit ja hash'i kleepimise kasutamine, näiteks vanema paari baitidest, kus võtme jooksutatakse läbi CRC32(rowkey) funktsiooni ja tõelise rowkey:

hash + rowkey

Siis jagatakse kõik andmed ühtlaselt regioonide vahel. Lugemise käigus lihtsalt visatakse esimesed kaks baitit ära ja jääb algne võti. Samuti kontrollib RS regioonis andmete ja võtmete arvu ning ületades piirangud jagab selle automaatselt osadeks.

7. Tõrketaluvus ja andmete lokaalsus

Kuna iga võtme komplekti haldab ainult üks piirkond, on RS-i väljalangemise või väljalaskmise probleemide lahenduseks kõigi vajalike andmete salvestamine HDFS-i. Kui RS laguneb, tuvastab master selle ZooKeeperis südamepeatu kaudu. Siis määrab ta hooldatava piirkonna teisele RS-ile ja kuna HFiles on salvestatud jaotatud failisüsteemi, loeb uus omanik need välja ja jätkab andmete teenindamist. Kuid kuna osa andmetest võib olla MemStores ja ei ole jõudnud HFilesse, kasutatakse operatsioonide ajaloo taastamiseks WAL-i, mis on samuti salvestatud HDFS-i. Pärast muudatuste pealekandmist suudab RS vastata päringutele, kuid ümberpaiknemine põhjustab, et osa andmeid ja neid teenindavad protsessid paiknevad erinevates sõlmedes, st lokaalsus väheneb.

Probleemi lahenduseks on major compaction – see protseduur liigutab faile nendele sõlmedele, mis nende eest vastutavad (seal, kus nende piirkonnad asuvad), mistõttu suureneb selle protseduuri käigus oluliselt võrgu- ja kettakoormus. Siiski kiireneb hiljem juurdepääs andmetele. Lisaks viib major_compaction kõik HFiles kokku üheks failiks piirkonna piiresse ning puhastab andmed vastavalt tabeli seadistustele. Näiteks saab määrata objekti versioonide arvu, mida tuleb säilitada, või eluaega, pärast mille möödumist objekt füüsiliselt kustutatakse.

See protseduur võib avaldada väga positiivset mõju HBase tööle. Alloleval pildil on nähtav, kuidas jõudlus on degradeerunud aktiivse andmete kirjutamise tõttu. Näha on, kuidas ühte tabelisse kirjutas 40 voogu ja 40 voogu luges andmeid samaaegselt. Kirjutamisvood vormivad üha rohkem ja rohkem HFiles, mida teised vood välja loevad. Tulemuseks on, et üha rohkem andmeid tuleb mälust eemaldada ja lõpuks hakkab töötama GC, mis praktiliselt halvab kogu töö. Major compactioni käivitamine viis tekkinud ummikute puhastamiseni ja jõudluse taastamiseni.

Test viidi läbi 3 DataNode'i ja 4 RS-i (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 lõime). HBase versioon 1.2.0-cdh5.14.2

Tuleb märkida, et major compactioni käivitamine toimus „elavas“ tabelis, kuhu kirjutati ja loeti andmeid aktiivselt. Internetis kohtas väidet, et see võib tuua kaasa ebaõige vastuse andmete lugemisel. Kontrollimiseks käivitati protsess, mis genereeris uusi andmeid ja kirjutas need tabelisse, millele järgnes kohene lugemine ja kontrollimine, kas saadud väärtus vastab sellele, mis oli kirjutatud. Selle protsessi käigus käivitati umbes 200 korda major compaction ja ühtegi viga ei registreeritud. Võib-olla probleem avaldub harva ja ainult kõrge koormuse ajal, seega on ohutum siiski planeeritult peatada kirjutamis- ja lugemisprotsessid ning teostada puhastus, vältides selliseid GC kukkumisi.

Samuti ei mõjuta major compaction MemStore'i olekut, selle kettale kirjutamiseks ja kompaktimiseks tuleb kasutada flush'i (connection.getAdmin().flush(TableName.valueOf(tblName))).

8. Seaded ja jõudlus

Nagu juba mainitud, saavutab HBase kõige suurema edusammuga seal, kus tal ei ole vaja midagi teha, BulkLoad'i teostamisel. Siiski kehtib see enamikus süsteemides ja inimeste jaoks. Kuid see tööriist sobib pigem suurte andmepakettide massiliseks paigutamiseks, samas kui kui protsess nõuab paljude samaaegsete lugemis- ja kirjutamisülesannete täitmist, kasutatakse ülaltoodud Get ja Put käske. Optimaalsete parameetrite määramiseks viidi läbi katseid erinevate tabelite parameetrite ja seadistuste kombinatsioonidega:

• Käivitati 10 voogu korraga 3 korda järjest (nimetame seda voogude blokkiks).
• Kogu voogude blokeeri tööaeg keskmistati ja see oli blokeerimise töö tulem.
• Kõik vood töötasid sama tabeliga.
• Iga voogude bloki käivitamise eel viidi läbi major compaction.
• Iga blokk sooritas ainult ühte järgmistest toimingutest:

— Put
— Get
— Get+Put

• Iga blokk sooritas 50 000 kordust oma toimingul.
• Kirje suurus blokis on 100 baiti, 1000 baiti või 10000 baiti (juhuslik).
• Blokke käivitati erineva soovitud võtmete arvuga (kas üks võti või 10).
• Blokke käivitati erinevate tabelite seadistustega. Muudetud parameetrid:

— BlockCache = sisse lülitatud või välja lülitatud
— BlockSize = 65 KB või 16 KB
— Partitsioonide arv = 1, 5 või 30
— MSLAB = sisse lülitatud või välja lülitatud

Nii näeb blokk välja:

a. MSLAB režiim lülitati sisse/välja.
b. Loodi tabel, millele kehtestati järgmised parameetrid: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
c. Seati juurde GZ kokkusurumine.
d. Käivitati 10 lõime, mis teostasid 1/10 put/get/get+put operatsiooni selle tabeliga, kus kirjed olid suurustega 100/1000/10000 baiti, teostades järjestikuselt 50 000 päringut (võtmed on juhuslikud).
e. Punkt d kordus kolm korda.
f. Kõigi lõimede tööaeg keskmistati.

Käsitleti kõiki võimalikke kombinatsioone. Eeldatavalt, kui kirje suurus suureneb, siis kiirus langeb või et vahemälu keelamine viib aeglustumiseni. Siiski oli eesmärk mõista iga parameetri mõju ulatust ja tähtsust, seetõttu edastati kogutud andmed lineaarse regressiooni funktsiooni sisendiks, mis võimaldab hinnata usaldusväärsust t-statistika abil. Allpool on toodud tulemused Put operatsioone teostavate plokkide töö kohta. Täielik kombinatsioonide arv 2*2*3*2*3 = 144 varianti + 72, kuna mõned olid teostatud kaks korda. Seega kokku 216 käivitust:

Testimine viidi läbi mini-klastril, mis koosnes 3 DataNode'ist ja 4 RS'ist (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 lõime). HBase versioon 1.2.0-cdh5.14.2.

Kõige kõrgem sisestamise kiirus 3.7 sekundi jooksul saavutati MSLAB režiimi väljalülitamisel, ühes osaga tabelis, koos lubatud BlockCache'iga, BlockSize = 16, kirjed 100 baiti 10 tükki pakis.
Kõige madalam sisestamise kiirus 82.8 sekundi jooksul saavutati MSLAB režiimi sisselülitamisel, ühes osaga tabelis, koos lubatud BlockCache'iga, BlockSize = 16, kirjed 10000 baiti 1 tükiga.

Nüüd vaatame mudelit. Näeme, et mudeli kvaliteet R2 järgi on hea, kuid on täiesti selge, et siit ekstrapoleerimine on vastunäidustatud. Süsteemi reaalsed käitumised parameetrite muutmisel ei ole lineaarsed, see mudel on vajalik mitte prognoosimiseks, vaid mõistmiseks, mis juhtus antud parameetrite piires. Näiteks näeme siin, et Stuudi kriitiumi järgi ei oma Put operatsiooni puhul BlockSize ja BlockCache parameetrid tähtsust (mis on üldiselt üsna eeldatav):

Kuid see, et arvu suurenemine osade arvus vähendab jõudlust, on pisut ootamatu (oleme juba näinud positiivset mõju osade arvu suurenemisel BulkLoad'i puhul), kuigi see on seletatav. Esiteks, töötlemiseks tuleb vormistada päringud 30 piirkonda asemel ühe suhtes, ning andmemaht ei ole piisavalt suur, et see kasu tooks. Teiseks määrab kogu tööaeg kõige aeglasem RS, ning kuna DataNode'ide arv on väiksem RS-ide arvust, siis osa piirkondadest ei oma null-lokaalsust. Ja vaatame viit liidrit:

Nüüd hindame Get plokkide täitmise tulemusi:

Osade arv on kaotanud oma tähtsuse, mis võib seletuda sellega, et andmed on hästi vahemälus ja lugemise vahemälu on kõige olulisem (statistiliselt) parameeter. Loomulikult on päringus sõnumite arvu suurendamine samuti päris kasulik jõudlusele. Parimad tulemused:

Ja lõpuks vaatame plokki, mis tegi kõigepealt get ja seejärel put:

Siin on kõik parameetrid olulised. Ja liidrite tulemused:

9. Koormuse testimine

Ja lõpuks käivitame enam-vähem korraliku koormuse, kuid alati on huvitavam, kui on, millega võrrelda. DataStaxi veebisaidil - Cassandra peamise arendaja juures on tulemused NoSQL hoiustamise NT rida, sealhulgas HBase versioon 0.98.6-1. Laadimist tehti 40 lõime kaudu, andmemaht oli 100 baiti, SSD kettad. Testimise tulemused operatsioonide Read-Modify-Write näitasid selliseid tulemusi.

Kuidas ma aru sain, lugemine toimus 100 kirje kaupa ja 16 HBase nodi puhul näitas DataStaxi test tootlikkust 10 tuhat operatsiooni sekundis.

Hea, et meie klastris on samuti 16 sõlme, kuid mitte just "hea" on see, et igas on 64 tuuma (voogu), samas kui DataStaxi testis oli vaid 4. Teiselt poolt on neil SSD terad, meil aga HDD ja uuem HBase versioon ning CPU kasutamine koormuse ajal suurenes praktiliselt mitte oluliselt (visuaalselt 5–10 protsenti). Kuid proovime siiski selle konfiguratsiooniga alustada. Tabelid on vaikeseaded, lugemine toimub võtmevahemikus 0–50 miljonit juhuslikult (st iga kord sisuliselt uus). Tabelis on 50 miljonit kirjet, jagatud 64 partitsiooniks. Võtmed on crc32 järgi hashitud. Tabelid on vaikeseadetes, MSLAB on sisse lülitatud. Käivitame 40 voogu, iga voog loeb 100 juhusliku võtme komplekti ja kirjutab kohe 100 genereeritud bitti tagasi nende võtmete alla.

Stend: 16 DataNode'i ja 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 voogu). HBase versioon 1.2.0-cdh5.14.2.

Keskmine tulemus on lähemal 40 000 tehingule sekundis, mis on oluliselt parem kui DataStaxi testis. Kuid eksperimendi eesmärgil on mõistlik täiendada mõningaid tingimusi. Üksikutel juhtudel on vähetõenäoline, et kogu töö käib ainult ühe tabeliga ja ainult unikaalsete võtmetega. Oletame, et on olemas mingi "kuum" võtme komplekt, mis genereerib peamise koormuse. Seetõttu proovime luua koormust suuremate kirjetega (10 KB), samuti pakkidena 100, 4 erinevas tabelis ja piirates nõutavate võtmete vahemiku 50 tuhandele. Alloleval graafikul on näidatud 40 voolu käivitamine, iga voog loeb 100 võtme komplekti ja kirjutab juurde juhuslikud 10 KB nende võtmete alla.

Stend: 16 DataNode'i ja 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 voogu). HBase versioon 1.2.0-cdh5.14.2.

Koormuse käigus käivitati mitu korda major compaction, nagu eespool näidatud, ilma selle protseduurita väheneb tõhusus aja jooksul, kuid selle teostamise ajal tekib ka täiendav koormus. Langused on põhjustatud erinevatest teguritest. Mõnikord lõpetasid vood töö ja kuni nende taaskäivitamiseni tekkis paus, mõnikord aitasid kolmandate osapoolte rakendused koormust tekitada klastris.

Lugemine ja kohe kirjutamine on HBase'i jaoks üks keerulisemaid tööstsenaariume. Kui teha ainult väikeseid put-päringuid, näiteks 100 bait, kombineerides need partii kaupa 10-50 tuhat, võib saavutada sadu tuhandeid toiminguid sekundis, ja sarnane olukord kehtib ka ainult lugemise päringute puhul. Tuleb märkida, et tulemused on radikaalselt paremad võrreldes DataStaxiga, peamiselt tänu 50 tuhande kaupa blokeeritud päringutele.

Stend: 16 DataNode'i ja 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 voogu). HBase versioon 1.2.0-cdh5.14.2.

10. Järeldused

See süsteem on piisavalt paindlikult seadistatav, kuid paljude parameetrite mõju jääb endiselt teadmata. Osa neist on testitud, kuid ei kuulunud lõplikku testide kogumisse. Näiteks eelnevad eksperimendid näitasid, et parameeter DATA_BLOCK_ENCODING, mis kodeerib teavet, kasutades naaberloomuste väärtusi, on oluliselt vähem märkimisväärne, mis on arusaadav juhuslike andmete jaoks. Suure hulga korduvate objektide kasutamisel võib võit olla märkimisväärne. Üldiselt võib öelda, et HBase jätab mulje tõsisest ja läbimõeldud andmebaasist, mis võib suurtel andmeblokiga töötledes olla piisavalt tõhus. Eriti juhul, kui on võimalik lugemise ja kirjutamise protsessid ajaliselt lahutada.

Kui midagi tundub teie arvates ebapiisavalt käsitletud, olen valmis rääkima lähemalt. Soovitame jagada oma kogemusi või arutada, kui millegagi ei nõustu.

Allikas: habr.com