HBase'i kasutamise teooria ja praktika

Tere! Minu nimi on Danil Lipovoy, meie meeskond Sbertechiis on hakanud kasutama HBase'i operatiivsete andmete salvestamiseks. Selle uurimise käigus on kogunenud teadmisi, mille tahtsime süsteematiseerida ja kirja panna (loodame, et see on paljudele kasulik). Allpool esitatud eksperimentid viidi läbi HBase'i versioonidega 1.2.0-cdh5.14.2 ja 2.0.0-cdh6.0.0-beta1.

1. Üldine arhitektuur
2. Andmete kirjutamine HBASE'sse
3. Andmete lugemine HBASE'st
4. Andmete vahemälu
5. Partii töötlemine MultiGet/MultiPut
6. Tabelite väljajagamise strateegia (splitting)
7. Talitlushäired, tihendamine ja andmete kohalikkus
8. Seaded ja jõudlus
9. Koormustestimine
10. Järeldused

1. Üldine arhitektuur

Reserv Master jälgib aktiivse sõlme ZooKeeperi heartbeat'i ja kaotuse korral võtab meisterfunktsioonid enda kanda.

2. Andmete kirjutamine HBASE'sse

Alustame kõige lihtsamast juhtumist – võtme-väärtuse objekti kirjutamine mingisse tabelisse funktsiooniga put(rowkey). Klient peab kõigepealt välja selgitama, kus asub juureregionaalserver (Root Region Server – RRS), mis salvestab tabeli hbase:meta. Selle teabe saab ta ZooKeeperilt. Seejärel pöördub ta RRS-i poole ja loeb tabeli hbase:meta, millest ta tuvastab, milline RegionServer (RS) vastutab antud rowkey võtme andmete salvestamise eest huvipakkuvas tabelis. Edasi, et meta-tabelit kasutada, vahemälestab klient selle ja seega järgnevate päringute vastuvõtt toimub kiiremini, otse RS-iga.

Seejärel kirjutab RS, saades päringu, kõigepealt selle WriteAheadLog'i (WAL), mis on vajalik taastamiseks, kui süsteem peaks kokku kukkuma. Seejärel salvestab andmed MemStore'i. See on mälu vahemälu, mis sisaldab antud regiooni järjestatud võtmete kogumit. Tabel võib olla jagatud regioonideks (partitsioonideks), millest igaüks sisaldab omavahel mitteühtivaid võtmete komplekte. See võimaldab regioonide jagamist erinevatele serveritele, et saavutada paremat jõudlust. Kuid hoolimata selle väite ilmsetest eeliseid, näeme hiljem, et see ei toimi kõigis olukordades.

Pärast salvestuse paigutamist MemStore'i naaseb kliendile vastus, et salvestus on edukalt tehtud. Sellegipoolest salvestatakse see tõeliselt ainult vahemällu ja jõuab ketta peale alles pärast teatud ajavahemiku möödumist või uute andmete täitmise korral.

Kustutamisoperatsiooni (Delete) sooritamisel ei toimu andmete füüsilist kustutamist. Need lihtsalt märgitakse kustutatuks, samas kui tegelik hävitamine toimub major compact'i funktsiooni käivitamisel, millest lähemalt räägitakse punktis 7.

HFile formaadis failid kogunevad HDFS-is ja aeg-ajalt käivitatakse minor compact'i protsess, mis lihtsalt liidab väiksed failid suuremateks, midagi kustutamata. Aja jooksul muutub see probleemiks, mis avaldub andmete lugemisel (kust me räägime hiljem).

Peale eespool kirjeldatud laadimisprotsessi on olemas palju tõhusam protseduur, milles seisneb tõeliselt selle andmebaasi üks tugevamaid külgi – BulkLoad. See seisneb selles, et me ise valmistame HFiles'd ja paigutame need kettale, mis võimaldab suurepärast skaleerimist ja saavutada üsna häid kiirus. Sisuliselt on piiranguks mitte HBase, vaid riistvara võimalused. Allpool on toodud laadimistulemused klastris, mis koosneb 16 RegionServerist ja 16 NodeManager YARNist (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 niiti), HBase'i versioon 1.2.0-cdh5.14.2.

Siit on näha, et suurendades tabeli partitsioonide (regioonide) arvu, samuti Spark'i executoreid, saame laadimiskiirusel lisanduse. Samuti sõltub kiirus kirjutamise mahust. Suured plokid annavad tõusu MB/sekundis, väiksed aga lisatud kirjete arvu ajas, kui kõik muud tingimused on võrdsed.

Samuti on võimalik laadimist käivitada kahes tabelis samaaegselt ja saavutada kiirus kahekordistumine. Allpool on näha, et 10 KB plokkide kirjutamine kahes tabelis toimub kiirusel umbes 600 MB/sek igaühe kohta (kokku 1275 MB/sek), mis vastab ühe tabeli kirjutamise kiirusel 623 MB/sek (vt punkt 11 ülal).

Siiski näitab teine käivitus 50 KB kirjetega, et laadimiskiirus kasvab enam-vähem mitteolemasolevalt, mis viitab piirväärtuste lähenemisele. Samas tuleb arvestada, et HBASEle ei tekitata peaaegu mingeid koormusi, kõik, mida temalt nõutakse, on kõigepealt andmete edastamine hbase:meta-st, ja pärast HFiles'i paigaldamist andmete BlockCache'i tühjendamine ning MemStore'i vahemälu salvestamine kettale, kui see pole tühi.

3. Andmete lugemine HBASE'st

Kui arvata, et kogu teave hbase:meta on klient juba olemas (vt p.2), siis saadetakse päring kohe sellele RS-ile, kus vajalik võti asub. Esmalt otsitakse MemCache'is. Sõltumata sellest, kas seal on andmeid või mitte, otsitakse ka BlockCache'i puhvris ja vajadusel HFailes. Kui andmed leitakse failist, paigutatakse need BlockCache'i ja järgmise päringu korral tagastatakse need kiiremini. Otsing HFailes toimub suhteliselt kiiresti, kasutades Bloom'i filtrit, mis tähendab, et väikese andmemahtude lugemise korral määrab see kohe, kas fail sisaldab vajalikku võtit; kui ei, siis minnakse järgmise juurde.

Saades andmed neist kolmest allikast, koostab RS vastuse. Konkreetsemalt võib ta vajadusel edastada mitu leitud objekti versiooni, kui klient on nõudnud versioonide ajalugu.

4. Andmete vahemälu

MemStore ja BlockCache puhvrite maht võib ulatuda kuni 80% RS-i määratud on-heap mälust (ülejäänud on reserveeritud RS-i teenindavateks ülesanneteks). Kui tüüpiline kasutusrežiim on selline, et protsessid kirjutavad ja kohe loevad neid andmeid, siis on mõttekas vähendada BlockCache'i ja suurendada MemStore'i, kuna kirjutamisel ei satu andmed lugemiseks puhvri, mistõttu BlockCache'i kasutamine toimub harvem. BlockCache'i puhver koosneb kahest osast: LruBlockCache (alati on-heap) ja BucketCache (enamasti off-heap või SSD-l). BucketCache'i kasutamine on otstarbekas, kui lugemisepäringute arv on väga suur ja need ei mahu LruBlockCache'i, mis toob kaasa aktiivse Garbage Collector'i töö. Siiski ei maksa oodata kiirusetõusu lugemisekahe kasutamisel, kuid selle juurde naaseme veel p. 8.

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

Kuidas detailsemalt Teoorias, andmeid kirjutades ei satu need puhvri, ja tõepoolest on selle tabeli ja RS-i jaoks parameetrid CACHE_DATA_ON_WRITE seadistatud valele. Kuid praktikas, kui kirjutada andmed MemStore'i, siis seejärel see kettale tühjendada (sellega puhastades), pärast seda fail kustutada, saame get päringuga edukalt andmed. Ja isegi kui täielikult BlockCache keelata ja tabel uute andmetega täita, ning saavutada MemStore'i kirjutamine kettale, need kustutada ja teises sessioonis küsida, tõmmatakse need ikkagi kuskilt välja. Nii et HBase hoiab endas mitte ainult andmeid, vaid ka salapäraseid mõistatusi.

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

Parameeter „Cache DATA on Read“ on seadistatud valele. Kui teil on ideid, on oodatud arutamiseks kommentaarides.

5. Andmete grupi töötlemine MultiGet/MultiPut

Ainulaadsete päringute (Get/Put/Delete) töötlemine on üsna kulukas operatsioon, seetõttu tuleks neid võimaluse korral ühendada Listi või Listiga, mis võimaldab saavutada märkimisväärset jõudluse tõusu. Eriti puudutab see kirjutamisoperatsiooni, kuid lugemisel on järgmine peidul kõrvaline probleem. Alloleval graafikul on näidatud 50 000 kirje lugemise aega MemStore'ist. Lugemine toimus ühes lõimes ning horisontaalsel teljel on näidatud päringu võtmete arvu. Siit on näha, et kui võtmete arv ühe päringu korral suureneb tuhandeni, siis täitmisaja vähenemine toimub, s.t. kiirus suureneb. Kuid kui vaikimisi MSLAB-režiim on sisse lülitatud, algab pärast seda piiri äkiline jõudluse langemine, ja see tuleneb sellest, et mis rohkem andmeid salvestatakse, seda pikem on töötlemisaeg.

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

MSLAB režiim on mõeldud heap-i fragmenteeringute vähendamiseks, mis tekivad uute ja vanade andmete segunemise tõttu. Lahenduseks, kui MSLAB on sisse lülitatud, paigutatakse andmed suhteliselt väikestesse rakkudesse (chunk) ja töödeldakse partii kaupa. Selle tulemusena, kui nõutud andmepaketi maht ületab määratud suuruse, siis jõudlus langeb järsult. Teiselt poolt ei ole soovitatav selle režiimi väljalülitamine, kuna see toob kaasa peatuste tekkimise GC tõttu andmeid intensiivselt töödeldes. Heaks lahenduseks on rakendusmahu suurendamine, kui samal ajal toimub kirjutamine put-i kaudu koos lugemisega. Tasub märkida, et probleemi ei teki, kui pärast kirjutamist täita flush käsk, mis tühjendab MemStore kettale, või kui laetakse andmeid BulkLoad'i kaudu. Allolevas tabelis on näidatud, et päringud suuremate andmete MemStore'ist (ja sama koguse) toovad kaasa aeglustumise. Kuid suurendades chunksize'i, saame töötlemise aega normaliseerida.

Lisaks chunksize'i suurendamisele aitab andmete jagamine piirkondade kaupa, st tabelite jagamine. See toob kaasa, et iga piirkonna jaoks tuleb vähem päringuid ja kui need mahtusid rakku, jääb vastus heaks.

6. Tabelite jagamise strateegia piirkondade kaupa (splittimine)

Kuna HBase on key-value salvestus ja partitsioneerimine toimub võtme järgi, on äärmiselt oluline andmeid ühtlaselt kõigi piirkondade vahel jagada. Näiteks sellise tabeli partitsioneerimine kolme osaks toob kaasa, et andmed jagatakse kolme piirkonna vahel:

Mõnikord põhjustab see järske aeglustumisi, kui edaspidi laaditavad andmed on näiteks long väärtustes, mis enamasti algavad sama numbriga, näiteks:

1000001
1000002
…
1100003

Kuna võtmed salvestatakse baitide massiivina, siis kõik nad alustavad ühtmoodi ja kuuluvad ühte piirkonda #1, mis hoiab seda võtme vahemikku. On mitu jagamise strateegiat:

HexStringSplit – Muudab võtmeks kümnendsüsteemis koodi vahemikus "00000000" => "FFFFFFFF" ja täidab vasakult nullidega.

UniformSplit – Muudab võtmeks baitide massiivi, mis on kümnendsüsteemis kood vahemikus "00" => "FF" ja täidab parelt nullidega.

Samuti saab määrata mis tahes vahemiku või võtmete kogumi jagamiseks ja seadistada autotööstust. Siiski on üks lihtsamaid ja tõhusamaid lähenemisviise UniformSplit ja hash'i ühendamise kasutamine, näiteks esimesed kaks baiti võtme töötlemisel funktsiooni CRC32(rowkey) kaudu ja tegelik rowkey:

hash + rowkey

Siis jaotatakse kõik andmed ühtlaselt piirkondade vahel. Lugemisel visatakse esimesed kaks baiti lihtsalt kõrvale ja jäetakse alles algne võti. Samuti kontrollib RS andmete ja võtmete arvu piirkonnas ja kui limiidid ületatakse, jagab selle automaatselt osadeks.

7. Vigade taluvus ja andmete kohalolek

Kuna iga võtme seeria eest vastutab ainult üks piirkond, on RS-i või selle väljalülitamisega seotud probleemide lahenduseks kõik vajalikud andmed hoida HDFS-is. RS-i rikke korral avastab master selle ZooKeeperis südametuksis oleva sõlme kaudu. Siis määrab ta hallatava piirkonna teisele RS-ile ja kuna HFiles salvestatakse jaotatud failisüsteemi, loeb uus peremees need välja ja jätkab andmete teenindamist. Kuid kuna osa andmeid võib olla MemStore'is ja pole veel HFilesisse jõudnud, kasutatakse toimingute ajaloos WAL-i, mis samuti hoitakse HDFS-is. Pärast muudatuste elluviimist suudab RS päringutele vastata, kuid liikumine viib selleni, et osa andmeid ja nende teenindamise protsessid asuvad erinevates sõlmedes, st lokaliteed vähendatakse.

Probleemi lahenduseks on major compaction – see protseduur viib failid nende sõlmedesse, mis nende eest vastutavad (seal, kus nende piirkonnad asuvad), mille tulemusena suureneb selle protseduuri ajal järsult koormus võrku ja kettale. Kuid edaspidi kiireneb juurdepääs andmetele oluliselt. Lisaks teostab major_compaction kõigi HFiles'ide ühendamist üheks failiks piirkonna raames ja puhastab andmeid tabeli seadistuste järgi. Näiteks võib määrata objekti versioonide arvu, mida tuleb säilitada, või selle eluiga, pärast mille möödumist objekt füüsiliselt eemaldatakse.

See protseduur võib positiivselt mõjutada HBase'i toimimist. Allolev pilt näitab, kuidas jõudlus halvenes aktiivsete andmete kirjutamise tõttu. Näha on, kuidas ühte tabelisse kirjutas 40 haru ja 40 haru luges andmeid samal ajal. Kirjutavad harud genereerisid üha rohkem HFiles'e, mida lugesid teised harud. tulemuseks on see, et järjest rohkem andmeid on vajalik mälust eemaldada ja lõpuks hakkab tööle GC, mis praktiliselt halvab kogu töö. Major compactioni käivitamine viis kogunenud segaduse puhastamiseni ja jõudluse taastamiseni.

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

On oluline märkida, et major compaction viidi läbi "elava" tabeli peal, kuhu kirjutati ja loeti aktiivselt andmeid. Võrgus esines väiteid, et see võib põhjustada vale vastust andmete lugemise ajal. Kontrollimiseks käivitati protsess, mis genereeris uusi andmeid ja kirjutas need tabelisse. Seejärel loeti kohe ja võrreldi, kas saadud väärtus kattus salvestatuga. Selle protsessi käigus käivitati umbes 200 korda major compaction ja mitte ühtegi riket ei registreeritud. Probleem võib ilmneda harva ja ainult kõrgete koormuste korral, seega on siiski turvalisem plaane teha, peatades kirjutamise ja lugemise protsessid ning teostada puhastust, vältides nii GC languseid.

Samuti ei mõjuta major compaction MemStore'i seisukorda, et selle andmeid kettale kirjutada ja kompaktida, tuleb kasutada flush (connection.getAdmin().flush(TableName.valueOf(tblName))).

8. Seaded ja jõudlus

Nagu juba mainitud, on HBase kõige edukam seal, kus tal pole vaja midagi teha, BulkLoad'i teostamisel. Kuid see kehtib enamiku süsteemide ja inimeste kohta. Siiski sobib see tööriist pigem andmete massiliseks salvestamiseks suurtel blokkidel, samas kui, kui protsess nõuab paljude konkurentsivõimeliste lugemise ja kirjutamise päringute täitmist, kasutatakse ülalnimetatud Get ja Put käske. Optimaalsete parameetrite määramiseks viidi läbi katseid erinevate tabeli parameetrite ja seadistuste kombinatsioonide korral:

• Käivitati 10 lõime korraga 3 korda järjest (nimetame seda lõimeblokiks).
• Kõigi lõimede töötamise aeg plokis keskmistati ja see oli ploki lõppkokkuvõte.
• Kõik lõimed töötasid ühe ja sama tabeliga.
• Iga lõimeploki käivituse eel viidi läbi major compaction.
• Iga plokk teostas ainult ühte järgmistest tegevustest:

— Put
— Get
— Get+Put

• Iga plokk teostas 50 000 kordust oma tegevuses.
• Bloki kirje suurus on 100 baiti, 1000 baiti või 10000 baiti (random).
• Plokid käivitati erineva arvuga küsitavaid võtmeid (kas üks võti või 10).
• Plokid käivitati erinevate tabeli seadistustega. Muudeti parameetreid:

— BlockCache = sisse või välja
— BlockSize = 65 Kb või 16 Kb
— Partitsioonid = 1, 5 või 30
— MSLAB = sisse või välja

Nii et plokk näeb välja järgmine:

a. Kujundati MSLAB režiimi sisse/välja.
b. Loodi tabel, millele seadistati järgmised parameetrid: BlockCache = true/none, BlockSize = 65/16 Kb, Partitsioonid = 1/5/30.
c. Seati GZ tihendamine.
d. Käivitati 10 lõime korraga, tehes 1/10 operatsioonidest put/get/get+put sellele tabelile 100/1000/10000 baiti, teostades järjest 50 000 päringut (võtmed on juhuslikud).
e. Punkt d kordus kolm korda.
f. Kõigi lõimede töötamise aeg keskmistati.

Kontrolliti kõiki võimalikke kombinatsioone. Õige on, et kui kirje suurus suureneb, siis kiirus langeb või et kui vahemälu keelatakse, toob see aeglustumist. Siiski oli eesmärk mõista iga parameetri mõju ulatust ja tähtsust, seetõttu esitati kogutud andmed lineaarse regressiooni funktsiooni sisendiks, mis võimaldab hinnata usaldusväärsust t-statistika abil. Allpool on esitatud tulemused, mis on seotud Put operatsioone teostavate plokkidega. Täielik kombinatsioonide kogum 2*2*3*2*3 = 144 varianti + 72, kuna mõned viidi ellu kaks korda. Seega kokku 216 käivitust:

Testimine toimus 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õrgeim sisestuskiirus 3.7 sec saavutati MSLAB režiimi välja lülitamisel, tabelis, millel oli üks partitsioon, sisse lülitatud BlockCache, BlockSize = 16, 100 baidi kirjeid, 10 tükki pakis.
Madalaim sisestuskiirus 82.8 sec saavutati MSLAB režiimi sisse lülitamisel, tabelis, millel oli üks partitsioon, sisse lülitatud BlockCache, BlockSize = 16, 10000 baidi kirjeid, 1 tükk.

Nüüd vaatame mudelit. Näeme head mudeli kvaliteeti R2 kaudu, kuid täiesti selge on, et ekstrapoleerimine on siin sobimatu. Reaalne süsteemi käitumine parameetrite muutumisel ei ole lineaarne, see mudel on vajalik mitte ennustamiseks, vaid mõistmiseks, mis on juhtunud antud parameetrite jooksul. Näiteks näeme siin Stüdiendi kriteeriumi järgi, et Put operatsiooni osas ei oma parameetrid BlockSize ja BlockCache (mis on üldiselt üsna ennustatav):

Kuid on üllatav, et partitsioonide arvu suurenemine toob kaasa jõudluse languse (oleme juba näinud positiivset mõju partitsioonide arvu suurendamisel BulkLoad'i puhul), kuigi see on arusaadav. Esiteks peab töötlemiseks vormistama päringud 30 piirkonna suhtes, mitte ühe, samas kui andmemaht ei ole piisavalt suur, et see eeliseid tooks. Teiseks, tööaja määrab aeglasem RS, ja kuna DataNode'ide arv on vähem kui RS'i arv, on osa piirkondadest nullkohalikud. Vaatame nüüd paremaid tulemusi:

Nüüd hinnakem Get blokkide täitmise tulemusi:

Partitsioonide arv on kaotanud oma tähtsuse, mis on tõenäoliselt seletatav asjaoluga, et andmed vahemälus, ja lugemisvahemälu on kõige olulisem (statistiliselt) parameeter. Loomulikult on päringutes sõnumite arvu suurendamine samuti väga kasulik jõudluse jaoks. Parimad tulemused:

Ja lõpuks vaatame plokki, mis täitis kõigepealt get'i ja seejärel put'i:

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

9. Koormustestimine

Ja lõpuks käivitame üsna korraliku koormuse, kuid alati on huvitav, kui on millega võrrelda. DataStaxi veebisaidil - Cassandra peamise arendaja juures on tulemused NoSQL hoiustamisrida, sealhulgas HBase versioon 0.98.6-1. Laadimine toimus 40 voogu, andmemaht 100 baiti, SSD kettad. Testimise tulemus Read-Modify-Write operatsioonide jaoks näitas selliseid tulemusi.

Nii palju kui ma aru sain, viidi lugemine läbi 100 kirje kaupa ja 16 node HBase testis DataStax näitas 10 000 operatsiooni sekundis.

Oleneb, et meie klastris on samuti 16 node, kuid mitte just "õnnestunud", et igas on 64 südamikku (voogu), samas kui DataStaxi testis oli vaid 4. Teisest küljest on neil SSD kettad, samas kui meil on HDD ja uuem HBase versioon, ning CPU koormus katsetamise ajal ei suurenenud pea üldse (visuaalselt 5-10 protsenti). Sellegipoolest proovime selle konfiguratsiooniga käivitada. Tabelite seadistused on vaikeseaded, lugemine toimub võti vahemikus 0 kuni 50 miljonit juhuslikult (st tegelikult iga kord uus). Tabelis on 50 miljonit kirjet, jagatud 64 partitsiooniks. Võtmed on krüptitud crc32 alusel. Tabelite seadistused on vaikeseaded, MSLAB on sisse lülitatud. Käivitame 40 voogu, iga voog loeb komplekti 100 juhuslikku võtit ja kohe kirjutab genereeritud 100 baiti nende võtmete kaudu tagasi.

Stend: 16 DataNode 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 operatsioonile sekundis, mis on oluliselt parem kui DataStaxi testis. Siiski, katse eesmärgil on mõnevõrra võimalik tingimusi muuta. On üsna ebatõenäoline, et kogu töö toimub ainult ühe tabeliga ja ainult ainulaadsete võtmetega. Oletame, et on olemas mingi 'kuum' võti komplekt, mis genereerib peamise koormuse. Seetõttu proovime luua koormuse suuremate rekorditega (10 KB), samuti komplektidena 100, neljas eri tabelis ja piirates nõutava võtme vahemiku 50 000. Alloleval graafikul on näidatud 40 voolu käivitamine, iga voog loeb komplekti 100 võtit ja kohe kirjutab juhuslikud 10 KB nende võtmete kaudu tagasi.

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

Koormuse ajal käivitati mitu korda major compaction, nagu eelnevalt näidatud, et ilma selle protseduurita tootlikkus järk-järgult halveneb, kuid selle teostamise ajal tekib samuti täiendav koormus. Langused on põhjustatud erinevatest põhjustest. Mõnikord lõpetavad vood töö ja nende taaskäivitamise ajal tekib paus, mõnikord loovad kolmandate osapoolte rakendused koormuse klastrile.

Lugemine ja kohe kirjutamine - on üks raskemaid stsenaariume HBase tööks. Kui teha ainult väikeste suurustega put päringuid, näiteks 100 baiti, ühendades need 10-50 tuhat tükki komplekti, saab tuua sadu tuhandeid operatsioone sekundis, ja sama kehtib ka ainult lugemisjärgsete päringute kohta. Tuleb märkida, et tulemused on radikaalselt paremad kui need, mis saadi DataStaxiga, ennekõike 50 000 tüki komplekti päringute tõttu.

Stend: 16 DataNode 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 kohandatav, kuid paljude parameetrite mõju jääb endiselt teadmata. Osa neist on testitud, kuid ei kuulu lõppkogumi testidesse. Näiteks eelnevad eksperimendid näitasid, et DATA_BLOCK_ENCODING parameetritel, mis kodeerivad teavet naaberates lahtrites olevate väärtuste abil, on väike tähtsus, mis on mõistetav juhuslikult genereeritud andmete jaoks. Suure hulga korduvate objektide kasutamisel võib kasu olla märkimisväärne. Üldiselt võib öelda, et HBase jätab mulje tõsise ja läbimõeldud andmebaasina, mis suurte andmeblokiga toimingute puhul võib olla piisavalt efektiivne. Eriti kui on võimalik lugemis- ja kirjutamisprotsessid ajaliselt lahku viia.

Kui midagi on teie arvates ebapiisavalt kajastatud, olen valmis rääkima lähemalt. Pakume oma kogemuste jagamist või arutame, kui te millegagi ei nõustu.

Allikas: habr.com