HBasen käytön teoria ja käytäntö

Hyvää iltapäivää Nimeni on Danil Lipovoy, tiimimme Sbertechissä alkoi käyttää HBasea operatiivisten tietojen tallennusvälineenä. Sen opiskelun aikana on kertynyt kokemusta, jota halusin systematisoida ja kuvata (toivomme, että siitä on hyötyä monille). Kaikki alla olevat kokeet suoritettiin HBase-versioilla 1.2.0-cdh5.14.2 ja 2.0.0-cdh6.0.0-beta1.

1. Yleinen arkkitehtuuri
2. Kirjoitetaan tietoja HBASEen
3. Tietojen lukeminen HBASEsta
4. Tietojen välimuisti
5. Erätietojen käsittely MultiGet/MultiPut
6. Strategia taulukoiden jakamiseksi alueiksi (jakaminen)
7. Vikasietoisuus, tiivistys ja tiedon paikka
8. Asetukset ja suorituskyky
9. Stressitestaus
10. Tulokset

1. Yleinen arkkitehtuuri

Varaisäntä kuuntelee ZooKeeper-solmun aktiivisen sydämenlyöntiä ja ottaa katoamisen yhteydessä hoitaakseen isäntälaitteen toiminnot.

2. Kirjoita tiedot HBASEen

Ensin tarkastellaan yksinkertaisinta tapausta - avainarvoobjektin kirjoittamista taulukkoon put(rowkey) -komennolla. Asiakkaan on ensin selvitettävä, missä hbase:meta-taulukon tallentava Root Region Server (RRS) sijaitsee. Hän saa nämä tiedot ZooKeeperiltä. Tämän jälkeen se käyttää RRS:ää ja lukee hbase:meta-taulukon, josta se poimii tiedot siitä, mikä RegionServer (RS) on vastuussa tietyn riviavaimen tietojen tallentamisesta kiinnostavaan taulukkoon. Tulevaa käyttöä varten asiakas tallentaa metataulukon välimuistiin, ja siksi seuraavat puhelut menevät nopeammin suoraan RS:ään.

Seuraavaksi RS saatuaan pyynnön kirjoittaa sen ensin WriteAheadLogiin (WAL), joka on välttämätön palautumiseen kaatumisen sattuessa. Tallentaa sitten tiedot MemStoreen. Tämä on muistissa oleva puskuri, joka sisältää lajiteltuja avaimia tietylle alueelle. Taulukko voidaan jakaa alueisiin (osioihin), joista jokainen sisältää hajautettujen avainten joukon. Tämän avulla voit sijoittaa alueita eri palvelimille parantaaksesi suorituskykyä. Tämän lausunnon ilmeisyydestä huolimatta näemme kuitenkin myöhemmin, että tämä ei toimi kaikissa tapauksissa.

Kun merkintä on asetettu MemStoreen, asiakkaalle palautetaan vastaus, että merkintä on tallennettu onnistuneesti. Todellisuudessa se kuitenkin tallennetaan vain puskuriin ja pääsee levylle vasta tietyn ajan kuluttua tai kun se on täytetty uudella tiedolla.

"Poista"-toimintoa suoritettaessa tietoja ei fyysisesti poisteta. Ne merkitään yksinkertaisesti poistetuiksi, ja itse tuhoutuminen tapahtuu tärkeimmän kompaktin toiminnon kutsumishetkellä, joka on kuvattu tarkemmin kappaleessa 7.

HFile-muodossa olevat tiedostot kerätään HDFS:ään ja ajoittain käynnistetään pieni kompakti prosessi, joka yksinkertaisesti yhdistää pienet tiedostot suurempiin poistamatta mitään. Ajan myötä tämä muuttuu ongelmaksi, joka ilmenee vain dataa luettaessa (palaamme tähän hieman myöhemmin).

Yllä kuvatun latausprosessin lisäksi on olemassa paljon tehokkaampi menettely, joka on ehkä tämän tietokannan vahvin puoli - BulkLoad. Se johtuu siitä, että muodostamme itsenäisesti HFiles ja laitamme ne levylle, mikä antaa meille mahdollisuuden skaalata täydellisesti ja saavuttaa erittäin kunnollisia nopeuksia. Itse asiassa rajoitus ei ole HBase, vaan laitteiston ominaisuudet. Alla on käynnistystulokset klusterista, joka koostuu 16 RegionServeristä ja 16 NodeManager YARN:sta (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 säiettä), HBase-versio 1.2.0-cdh5.14.2.

Täällä voit nähdä, että lisäämällä taulukon osioiden (alueiden) määrää sekä Spark-suorittajia, saamme lisäyksen latausnopeuteen. Nopeus riippuu myös tallennusvoimakkuudesta. Suuret lohkot lisäävät MB/s, pienet lohkot lisättyjen tietueiden määrää aikayksikköä kohti, kaikkien muiden asioiden ollessa sama.

Voit myös aloittaa lataamisen kahteen pöytään samanaikaisesti ja saada kaksinkertaisen nopeuden. Alta näet, että 10 KB:n lohkojen kirjoittaminen kahteen taulukkoon kerralla tapahtuu noin 600 MB/s nopeudella kummassakin (yhteensä 1275 MB/s), mikä osuu yhteen kirjoitusnopeuden kanssa yhteen taulukkoon 623 MB/s (ks. nro 11 yllä)

Mutta toinen ajo 50 kt:n tietueilla osoittaa, että latausnopeus kasvaa hieman, mikä osoittaa sen lähestyvän raja-arvoja. Samanaikaisesti sinun on pidettävä mielessä, että itse HBASE:lle ei käytännössä luoda kuormitusta, se tarvitsee vain antaa tiedot ensin hbase:metasta ja HFiles-asetuksen jälkeen nollaa BlockCache-tiedot ja tallenna MemStore-puskuri levylle, jos se ei ole tyhjä.

3. Tietojen lukeminen HBASEsta

Jos oletetaan, että asiakkaalla on jo kaikki tiedot hbase:metasta (katso kohta 2), niin pyyntö menee suoraan RS:ään, johon vaadittu avain on tallennettu. Ensin haku suoritetaan MemCachessa. Riippumatta siitä, onko siellä dataa vai ei, haku suoritetaan myös BlockCache-puskurissa ja tarvittaessa HFilesissa. Jos tiedostosta löytyi tietoja, se sijoitetaan BlockCacheen ja palautetaan nopeammin seuraavassa pyynnössä. Haku HFilessä on suhteellisen nopeaa Bloom-suodattimen käytön ansiosta, ts. Kun se on lukenut pienen määrän tietoa, se määrittää välittömästi, sisältääkö tämä tiedosto vaaditun avaimen, ja jos ei, siirtyy seuraavaan.

Saatuaan tiedot näistä kolmesta lähteestä RS muodostaa vastauksen. Erityisesti se voi siirtää useita löydettyjä versioita objektista kerralla, jos asiakas pyytää versiointia.

4. Tietojen välimuisti

MemStore- ja BlockCache-puskurit vievät jopa 80 % varatusta keon RS-muistista (loppu on varattu RS-palvelutehtäviin). Jos tyypillinen käyttötila on sellainen, että prosessit kirjoittavat ja lukevat saman tiedon välittömästi, on järkevää vähentää BlockCachea ja lisätä MemStorea, koska Kun kirjoitettavat tiedot eivät pääse välimuistiin lukemista varten, BlockCachea käytetään harvemmin. BlockCache-puskuri koostuu kahdesta osasta: LruBlockCache (aina kasossa) ja BucketCache (yleensä off-heap tai SSD-levyllä). BucketCachea tulee käyttää, kun lukupyyntöjä on paljon eivätkä ne mahdu LruBlockCacheen, mikä johtaa roskienkeräimen aktiiviseen työhön. Samaan aikaan sinun ei pitäisi odottaa radikaalia suorituskyvyn kasvua lukuvälimuistin käytöstä, mutta palaamme tähän kappaleessa 8

Koko RS:lle on yksi BlockCache, ja jokaiselle pöydälle on yksi MemStore (yksi jokaiselle sarakeperheelle).

miten kuvattu teoriassa kirjoitettaessa tiedot eivät mene välimuistiin ja itse asiassa sellaiset parametrit CACHE_DATA_ON_WRITE taulukolle ja "Cache DATA on Write" RS:lle asetetaan epätosi. Käytännössä kuitenkin, jos kirjoitamme tiedot MemStoreen, huuhtelemme sen sitten levylle (täten tyhjennämme sen), poistamme sitten tuloksena olevan tiedoston, niin saamme tiedot onnistuneesti suorittamalla hakupyynnön. Lisäksi, vaikka poistat BlockCachen kokonaan käytöstä ja täytät taulukon uusilla tiedoilla, palautat sitten MemStoren levylle, poistat ne ja pyydät niitä toisesta istunnosta, ne silti haetaan jostain. Joten HBase ei tallenna vain tietoja, vaan myös salaperäisiä mysteereitä.

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

Parametri "Cache DATA on Read" on asetettu arvoon false. Jos sinulla on ideoita, tervetuloa keskustelemaan niistä kommenteissa.

5. Erätietojen käsittely MultiGet/MultiPut

Yksittäisten pyyntöjen käsittely (Get/Put/Delete) on melko kallis toimenpide, joten jos mahdollista, ne kannattaa yhdistää Listiksi tai Listiksi, mikä mahdollistaa merkittävän suorituskyvyn parantamisen. Tämä pätee erityisesti kirjoitusoperaatioon, mutta luettaessa on seuraava sudenkuoppa. Alla olevassa kaaviossa näkyy aika lukea 50 000 tietuetta MemStoresta. Lukeminen suoritettiin yhdessä säikeessä ja vaaka-akselilla näkyy pyynnön avainten lukumäärä. Tässä näkyy, että kun kasvatetaan tuhanteen avaimeen yhdessä pyynnössä, suoritusaika laskee, ts. nopeus kasvaa. Kuitenkin, kun MSLAB-tila on oletusarvoisesti käytössä, tämän kynnyksen jälkeen suorituskyky alkaa laskea radikaalisti, ja mitä suurempi datamäärä tietueessa on, sitä pidempi on toiminta-aika.

Testit suoritettiin virtuaalikoneella, 8 ydintä, versio HBase 2.0.0-cdh6.0.0-beta1.

MSLAB-tila on suunniteltu vähentämään kasan pirstoutumista, joka johtuu uuden ja vanhan sukupolven tietojen sekoittumisesta. Kiertokeinona, kun MSLAB on käytössä, tiedot sijoitetaan suhteellisen pieniin soluihin (paloihin) ja käsitellään paloina. Tämän seurauksena, kun pyydetyn datapaketin määrä ylittää varatun koon, suorituskyky laskee jyrkästi. Toisaalta tämän tilan kytkeminen pois päältä ei myöskään ole suositeltavaa, koska se johtaa GC:n aiheuttamiin pysähdyksiin intensiivisen tietojenkäsittelyn hetkinä. Hyvä ratkaisu on kasvattaa solun volyymiä, jos kirjoitetaan aktiivisesti putin kautta samaan aikaan lukemisen kanssa. On syytä huomata, että ongelmaa ei ilmene, jos suoritat tallennuksen jälkeen huuhtelukomennon, joka palauttaa MemStoren levylle, tai jos lataat BulkLoadilla. Alla oleva taulukko osoittaa, että MemStoresta suuremman (ja saman määrän) datan kyselyt hidastavat. Kuitenkin suurentamalla kappaleen kokoa palautamme käsittelyajan normaaliksi.

Osan koon kasvattamisen lisäksi auttaa tietojen jakaminen alueittain, ts. pöydän jakaminen. Tämä johtaa siihen, että jokaiselle alueelle tulee vähemmän pyyntöjä, ja jos ne mahtuvat soluun, vastaus pysyy hyvänä.

6. Strategia taulukoiden jakamiseksi alueiksi (jakaminen)

Koska HBase on avainarvovarasto ja osiointi tapahtuu avaimella, on erittäin tärkeää jakaa tiedot tasaisesti kaikille alueille. Esimerkiksi tällaisen taulukon osiointi kolmeen osaan johtaa siihen, että tiedot jaetaan kolmeen alueeseen:

Tämä johtaa jyrkkään hidastumiseen, jos myöhemmin ladatut tiedot näyttävät esimerkiksi pitkiltä arvoilta, joista suurin osa alkaa samalla numerolla, esim.

1000001
1000002
...
1100003

Koska avaimet on tallennettu tavutaulukkona, ne kaikki alkavat samalla tavalla ja kuuluvat samaan alueeseen #1, joka tallentaa tämän avainalueen. Osiointistrategioita on useita:

HexStringSplit – Muuttaa avaimen heksadesimaalikoodatuksi merkkijonoksi alueella "00000000" => "FFFFFFFF" ja täyttö vasemmalla nolilla.

UniformSplit – Muuttaa avaimen tavutaulukoksi, jossa on heksadesimaalikoodaus alueella "00" => "FF" ja oikealla täyttö nolilla.

Lisäksi voit määrittää minkä tahansa alueen tai näppäinjoukon jakamista varten ja määrittää automaattisen jakamisen. Yksi yksinkertaisimmista ja tehokkaimmista lähestymistavoista on kuitenkin UniformSplit ja hash-ketjutuksen käyttö, esimerkiksi merkittävin tavupari avaimen suorittamisesta CRC32(rowkey)-funktion ja itse rivinäppäimen kautta:

hash + rivinäppäin

Sitten kaikki tiedot jaetaan tasaisesti alueiden kesken. Lukeessa kaksi ensimmäistä tavua yksinkertaisesti hylätään ja alkuperäinen avain säilyy. RS hallitsee myös datan ja avainten määrää alueella ja, jos rajat ylittyvät, jakaa ne automaattisesti osiin.

7. Vikasietoisuus ja tietojen sijainti

Koska vain yksi alue on vastuussa kustakin avainjoukosta, ratkaisu RS-kaatumisiin tai käytöstä poistamiseen liittyviin ongelmiin on tallentaa kaikki tarvittavat tiedot HDFS:ään. Kun RS putoaa, isäntä havaitsee tämän, koska ZooKeeper-solmussa ei ole sykettä. Sitten se määrittää palvelevan alueen toiselle RS:lle ja koska HF-tiedostot on tallennettu hajautettuun tiedostojärjestelmään, uusi omistaja lukee ne ja jatkaa tietojen palvelemista. Koska osa tiedoista saattaa kuitenkin olla MemStoressa, eikä niillä ehtinyt päästä HFilesiin, WAL:ia, joka on myös tallennettu HDFS:ään, käytetään toimintahistorian palauttamiseen. Muutosten voimaantulon jälkeen RS pystyy vastaamaan pyyntöihin, mutta muutto johtaa siihen, että osa tiedoista ja niitä palvelevista prosesseista päätyy eri solmuihin, ts. paikkakunta vähenee.

Ratkaisu ongelmaan on suuri tiivistys - tämä toimenpide siirtää tiedostot niistä vastaaviin solmuihin (missä niiden alueet sijaitsevat), minkä seurauksena tämän toimenpiteen aikana verkon ja levyjen kuormitus kasvaa jyrkästi. Tulevaisuudessa tietojen saatavuus kuitenkin nopeutuu huomattavasti. Lisäksi major_compaction suorittaa kaikkien HF-tiedostojen yhdistämisen yhdeksi tiedostoksi alueella ja myös puhdistaa tiedot taulukon asetuksista riippuen. Voit esimerkiksi määrittää objektin versioiden määrän, jotka on säilytettävä, tai eliniän, jonka jälkeen objekti fyysisesti poistetaan.

Tällä menettelyllä voi olla erittäin myönteinen vaikutus HBasen toimintaan. Alla olevassa kuvassa näkyy, kuinka suorituskyky heikkeni aktiivisen datan tallennuksen seurauksena. Täältä näet kuinka 40 säiettä kirjoitti yhteen taulukkoon ja 40 säiettä lukee tietoja samanaikaisesti. Kirjoitussäikeet tuottavat yhä enemmän HF-tiedostoja, joita muut säikeet lukevat. Tämän seurauksena yhä enemmän dataa on poistettava muistista ja lopulta GC alkaa toimia, mikä käytännössä halvaantaa kaiken työn. Suuren tiivistyksen käynnistäminen johti syntyneiden roskien poistamiseen ja tuottavuuden palautumiseen.

Testi suoritettiin 3 DataNodilla ja 4 RS:llä (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 säiettä). HBase-versio 1.2.0-cdh5.14.2

On syytä huomata, että suuri tiivistys käynnistettiin "live"-taulukossa, johon dataa kirjoitettiin ja luettiin aktiivisesti. Netissä oli lausunto, että tämä voi johtaa virheelliseen vastaukseen dataa luettaessa. Tarkistamiseksi käynnistettiin prosessi, joka loi uutta dataa ja kirjoitti sen taulukkoon. Sen jälkeen luin ja tarkistin heti, onko tuloksena kirjoitettu arvo yhtäpitävä. Kun tämä prosessi oli käynnissä, suuri tiivistys ajettiin noin 200 kertaa eikä yhtäkään vikaa kirjattu. Ehkä ongelma ilmaantuu harvoin ja vain suuren kuormituksen aikana, joten on turvallisempaa pysäyttää kirjoitus- ja lukuprosessit suunnitellusti ja suorittaa puhdistus tällaisten GC-vikojen estämiseksi.

Suurempi tiivistys ei myöskään vaikuta MemStoren tilaan; sen huuhtelemiseksi levylle ja tiivistämiseksi sinun on käytettävä huuhtelua (connection.getAdmin().flush(TableName.valueOf(tblName))).

8. Asetukset ja suorituskyky

Kuten jo mainittiin, HBase osoittaa suurimman menestyksensä silloin, kun sen ei tarvitse tehdä mitään, kun se suorittaa BulkLoadin. Tämä koskee kuitenkin useimpia järjestelmiä ja ihmisiä. Tämä työkalu soveltuu kuitenkin paremmin tietojen tallentamiseen suurissa lohkoissa, kun taas jos prosessi vaatii useita kilpailevia luku- ja kirjoituspyyntöjä, käytetään yllä kuvattuja Get- ja Put-komentoja. Optimaalisten parametrien määrittämiseksi käynnistettiin erilaisia ​​​​taulukkoparametrien ja -asetusten yhdistelmiä:

• 10 säiettä käynnistettiin samanaikaisesti 3 kertaa peräkkäin (kutsutaanko tätä lankalohkoksi).
• Lohkon kaikkien säikeiden toiminta-ajasta laskettiin keskiarvo ja se oli lohkon toiminnan lopputulos.
• Kaikki langat toimivat samalla taulukolla.
• Ennen jokaista kierrelohkon aloitusta suoritettiin suuri tiivistys.
• Jokainen lohko suoritti vain yhden seuraavista toiminnoista:

-Laittaa
-Saada
-Hae+Put

• Jokainen lohko suoritti toimintansa 50 000 iteraatiota.
• Tietueen lohkokoko on 100 tavua, 1000 tavua tai 10000 XNUMX tavua (satunnainen).
• Lohkot käynnistettiin eri määrillä pyydettyjä avaimia (joko yksi avain tai 10).
• Lohkot ajettiin eri pöytäasetuksilla. Parametrit muutettu:

— BlockCache = päällä tai pois päältä
— BlockSize = 65 kt tai 16 kt
— Osiot = 1, 5 tai 30
— MSLAB = käytössä tai poissa käytöstä

Joten lohko näyttää tältä:

a. MSLAB-tila laitettiin päälle/pois.
b. Luotiin taulukko, jolle asetettiin seuraavat parametrit: BlockCache = tosi/ei mitään, BlockSize = 65/16 Kb, Osio = 1/5/30.
c. Pakkaukseksi asetettiin GZ.
d. 10 säiettä käynnistettiin samanaikaisesti suorittaen 1/10 put/get/get+put -operaatiota tähän taulukkoon 100/1000/10000 tavun tietueilla, suorittaen 50 000 kyselyä peräkkäin (satunnaisavaimet).
e. Kohta d toistettiin kolme kertaa.
f. Kaikkien säikeiden käyttöajasta laskettiin keskiarvo.

Kaikki mahdolliset yhdistelmät testattiin. On ennakoitavissa, että nopeus laskee tietueen koon kasvaessa tai välimuistin poistaminen käytöstä hidastaa. Tavoitteena oli kuitenkin ymmärtää kunkin parametrin vaikutuksen aste ja merkitys, joten kerätyt tiedot syötettiin lineaarisen regressiofunktion syötteeseen, joka mahdollistaa merkityksen arvioinnin t-tilastoilla. Alla on Put-operaatioita suorittavien lohkojen tulokset. Täysi sarja yhdistelmiä 2*2*3*2*3 = 144 vaihtoehtoa + 72 tk. jotkut tehtiin kahdesti. Ajoja on siis yhteensä 216:

Testaus suoritettiin miniklusterilla, joka koostui 3 DataNodista ja 4 RS:stä (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 säiettä). HBase-versio 1.2.0-cdh5.14.2.

Suurin lisäysnopeus, 3.7 sekuntia, saavutettiin MSLAB-tilan ollessa pois päältä, taulukossa, jossa oli yksi osio, BlockCache käytössä, BlockSize = 16, tietueet 100 tavua, 10 kappaletta per pakkaus.
Pienin lisäysnopeus, 82.8 sekuntia, saavutettiin MSLAB-tilan ollessa käytössä, taulukossa, jossa oli yksi osio, BlockCache käytössä, BlockSize = 16, tietueet 10000 1 tavua, XNUMX kukin.

Katsotaan nyt mallia. Näemme R2:een perustuvan mallin hyvän laadun, mutta on täysin selvää, että ekstrapolointi on tässä vasta-aiheista. Järjestelmän todellinen käyttäytyminen parametrien muuttuessa ei ole lineaarista, tätä mallia ei tarvita ennustamiseen, vaan sen ymmärtämiseen, mitä annettujen parametrien sisällä tapahtui. Esimerkiksi tässä näemme Studentin kriteeristä, että BlockSize- ja BlockCache-parametreilla ei ole merkitystä Put-operaation kannalta (joka on yleensä melko ennustettavissa):

Mutta tosiasia, että osioiden määrän lisääminen johtaa suorituskyvyn laskuun, on jokseenkin odottamatonta (olemme jo nähneet osioiden määrän lisäämisen positiivisen vaikutuksen BulkLoadilla), vaikkakin ymmärrettävää. Ensinnäkin käsittelyä varten sinun on luotava pyyntöjä 30 alueelle yhden sijasta, eikä datamäärä ole niin suuri, että se tuottaisi voittoa. Toiseksi kokonaistoiminta-aika määräytyy hitain RS:n mukaan, ja koska DataSolmujen lukumäärä on pienempi kuin RS:ien lukumäärä, joillakin alueilla on nollapaikka. No, katsotaanpa viittä parasta:

Arvioidaan nyt Get blockien suorittamisen tuloksia:

Osioiden määrä on menettänyt merkityksensä, mikä todennäköisesti selittyy sillä, että tiedot ovat hyvin välimuistissa ja lukuvälimuisti on (tilastollisesti) merkittävin parametri. Luonnollisesti viestien määrän lisääminen pyynnössä on myös erittäin hyödyllistä suorituskyvyn kannalta. Parhaat pisteet:

No, lopuksi katsotaan lohkon mallia, joka ensin suoritti get ja sitten laittaa:

Kaikki parametrit ovat tärkeitä tässä. Ja johtajien tulokset:

9. Kuormitustestaus

No, vihdoin lanseeraamme enemmän tai vähemmän kunnollisen kuorman, mutta se on aina mielenkiintoisempaa, kun on jotain, johon vertailla. Cassandran keskeisen kehittäjän DataStaxin verkkosivuilla on tulokset NT useista NoSQL-tallennusvälineistä, mukaan lukien HBase-versio 0.98.6-1. Lataus suoritettiin 40 säiettä, datan koko 100 tavua, SSD-levyjä. Read-Modify-Write-operaatioiden testauksen tulos osoitti seuraavat tulokset.

Ymmärtääkseni lukeminen suoritettiin 100 tietueen lohkoissa ja 16 HBase-solmulle DataStax-testi osoitti suorituskyvyn 10 tuhatta operaatiota sekunnissa.

Onneksi klusterissamme on myös 16 solmua, mutta ei ole kovin "onneksi", että jokaisessa on 64 ydintä (säiettä), kun taas DataStax-testissä niitä on vain 4. Toisaalta heillä on SSD-asemat, kun taas meillä kiintolevyt tai enemmän uusi HBase-versio ja suorittimen käyttöaste ei käytännössä noussut merkittävästi (visuaalisesti 5-10 prosenttia). Yritetään kuitenkin aloittaa tämän kokoonpanon käyttö. Taulukon oletusasetukset, lukeminen suoritetaan avainalueella 0-50 miljoonaa satunnaisesti (eli olennaisesti uusina joka kerta). Taulukko sisältää 50 miljoonaa tietuetta, jotka on jaettu 64 osioon. Avaimet on hajautettu crc32:lla. Taulukkoasetukset ovat oletusarvoisia, MSLAB on käytössä. 40 säiettä käynnistäessään jokainen säiettä lukee 100 satunnaisen avaimen joukon ja kirjoittaa välittömästi luodut 100 tavua takaisin näihin avaimiin.

Jalusta: 16 DataNodea ja 16 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 säiettä). HBase-versio 1.2.0-cdh5.14.2.

Keskimääräinen tulos on lähempänä 40 tuhatta operaatiota sekunnissa, mikä on merkittävästi parempi kuin DataStax-testissä. Kokeilutarkoituksiin voit kuitenkin muuttaa olosuhteita hieman. On melko epätodennäköistä, että kaikki työ suoritetaan yksinomaan yhdellä pöydällä ja myös vain ainutlaatuisilla avaimilla. Oletetaan, että on olemassa tietty "kuuma" näppäinsarja, joka tuottaa pääkuorman. Siksi yritetään luoda kuorma suuremmilla tietueilla (10 KB), myös 100:n erissä, 4 eri taulukossa ja rajoittamalla pyydettyjen avainten valikoima 50 tuhanteen. Alla oleva kaavio näyttää 40 säikeen käynnistämisen, jokainen säiettä lukee 100 näppäinsarjan ja kirjoittaa välittömästi satunnaisen 10 kilotavua näihin avaimiin takaisin.

Jalusta: 16 DataNodea ja 16 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 säiettä). HBase-versio 1.2.0-cdh5.14.2.

Kuorman aikana käynnistettiin useita kertoja isotiivistys, kuten yllä on esitetty, ilman tätä menettelyä suorituskyky heikkenee vähitellen, mutta suorituksen aikana syntyy myös lisäkuormitusta. Tappiot johtuvat useista syistä. Joskus säikeet lopettivat toimintansa ja niiden uudelleenkäynnistyksen aikana oli tauko, joskus kolmannen osapuolen sovellukset kuormittivat klusterin.

Lukeminen ja heti kirjoittaminen on yksi HBasen vaikeimmista työskenaarioista. Jos teet vain pieniä, esim. 100 tavun, putoamispyyntöjä, yhdistämällä ne 10-50 tuhannen kappaleen pakkauksiin, voit saada satoja tuhansia operaatioita sekunnissa, ja sama tilanne on vain luku -pyyntöjen kanssa. On syytä huomata, että tulokset ovat radikaalisti parempia kuin DataStaxin saamat tulokset, mikä johtuu ennen kaikkea 50 tuhannen lohkoista.

Jalusta: 16 DataNodea ja 16 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 säiettä). HBase-versio 1.2.0-cdh5.14.2.

10. Päätelmät

Tämä järjestelmä on varsin joustavasti konfiguroitu, mutta useiden parametrien vaikutus on edelleen tuntematon. Jotkut niistä testattiin, mutta niitä ei sisällytetty tuloksena olevaan testisarjaan. Esikokeet osoittivat esimerkiksi sellaisen parametrin, kuten DATA_BLOCK_ENCODING, merkityksettömän merkityksen, joka koodaa tietoa viereisten solujen arvoilla, mikä on ymmärrettävää satunnaisesti generoidulle datalle. Jos käytät suurta määrää päällekkäisiä objekteja, vahvistus voi olla merkittävä. Yleisesti voidaan sanoa, että HBase antaa vaikutelman melko vakavasta ja hyvin harkitusta tietokannasta, joka voi olla varsin tuottava suoritettaessa operaatioita suurilla tietolohkoilla. Varsinkin jos luku- ja kirjoitusprosessit on mahdollista erottaa ajoissa.

Jos mielestäsi on jotain, jota ei ole paljastettu tarpeeksi, olen valmis kertomaan sinulle tarkemmin. Kutsumme sinut jakamaan kokemuksiasi tai keskustelemaan, jos olet eri mieltä jostakin.

Lähde: will.com