Arratsalde on Nire izena Danil Lipovoy da, Sbertech-eko gure taldea HBase erabiltzen hasi zen datu operatiboetarako biltegiratze gisa. Hori aztertzean, sistematizatu eta deskribatu nahi nuen esperientzia pilatu da (askorentzat erabilgarria izatea espero dugu). Beheko esperimentu guztiak HBase 1.2.0-cdh5.14.2 eta 2.0.0-cdh6.0.0-beta1 bertsioekin egin ziren.
- Arkitektura orokorra
- HBASEra datuak idazten
- HBASEko datuak irakurtzea
- Datuen cachea
- Batch datuen tratamendua MultiGet/MultiPut
- Taulak eskualdetan banatzeko estrategia (banatzea)
- Akatsen tolerantzia, trinkotzea eta datuen lokalizazioa
- Ezarpenak eta errendimendua
- Estres probak
- Findings
1. Arkitektura orokorra
Backup Masterrak aktiboaren taupadak entzuten ditu ZooKeeper nodoan eta, desagertzen bada, maisuaren funtzioak hartzen ditu.
2. Idatzi datuak HBASEra
Lehenik eta behin, ikus dezagun kasurik errazena: gako-balioaren objektu bat idaztea taula batean put(rowkey) erabiliz. Bezeroak hbase:meta taula gordetzen duen Root Region Server (RRS) non dagoen jakin behar du lehenik. Informazio hori ZooKeeper-etik jasotzen du. Horren ostean, RRS-ra sartzen da eta hbase:meta taula irakurtzen du, eta bertatik informazioa ateratzen du zein RegionServer (RS) arduratzen den errenkada-tekla jakin baterako datuak interesatzen den taulan gordetzeko. Etorkizunean erabiltzeko, meta taula bezeroak cachean gordetzen du eta, beraz, ondorengo deiak azkarrago joaten dira, zuzenean RSra.
Ondoren, RS-k eskaera bat jaso ondoren, lehenik eta behin WriteAheadLog-en (WAL) idazten du, hau da, hutsegite baten kasuan berreskuratzeko beharrezkoa dena. Ondoren, datuak MemStore-n gordetzen ditu. Hau memoriako buffer bat da, eskualde jakin baterako gako-multzo ordenatua daukana. Taula bat eskualdetan (partiziotan) bana daiteke, eta horietako bakoitzak gako-multzo bateratu bat dauka. Horrek zerbitzari desberdinetan eskualdeak jar ditzakezu errendimendu handiagoa lortzeko. Hala ere, adierazpen hau agerikoa den arren, aurrerago ikusiko dugu horrek ez duela funtzionatzen kasu guztietan.
MemStore-n sarrera bat jarri ondoren, erantzuna itzultzen zaio bezeroari sarrera behar bezala gorde dela esanez. Dena den, errealitatean buffer batean bakarrik gordetzen da eta denbora tarte jakin bat igaro ondoren edo datu berriez betetakoan bakarrik iristen da diskora.
"Ezabatu" eragiketa egitean, datuak ez dira fisikoki ezabatzen. Ezabatu gisa markatzen dira besterik gabe, eta suntsipena bera funtzio trinko nagusia deitzeko unean gertatzen da, 7. paragrafoan zehatzago deskribatzen dena.
HFile formatuan dauden fitxategiak HDFSn metatzen dira eta noizean behin prozesu trinko txikia abiarazten da, fitxategi txikiak handiekin bateratzen dituena ezer ezabatu gabe. Denborarekin, datuak irakurtzean bakarrik agertzen den arazo bat bihurtzen da (geroago itzuliko gara hona).
Goian deskribatutako karga-prozesuaz gain, prozedura askoz eraginkorragoa dago, agian datu-base honen alderik indartsuena - BulkLoad. HFileak modu independentean eratu eta diskoan jartzen ditugula datza, eta horrek ezin hobeto eskalatu eta abiadura oso duinak lortzen ditu. Izan ere, hemen muga ez da HBase, hardwarearen gaitasunak baizik. Jarraian, 16 RegionServers eta 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 hari), HBase bertsioa 1.2.0-cdh5.14.2 osatutako kluster batean daude abiarazte-emaitzak.
Hemen ikus dezakezu taulako partizio (eskualde) kopurua handituz, baita Spark exekutatzaileak ere, deskarga-abiadura handitzen dugula. Gainera, abiadura grabazioaren bolumenaren araberakoa da. Bloke handiek MB/seko igoera ematen dute, bloke txikiek denbora-unitateko txertatutako erregistro kopuruan, gainerako gauza guztiak berdinak izanik.
Bi mahaitan kargatzen ere has zaitezke aldi berean eta abiadura bikoitza lor dezakezu. Jarraian ikus dezakezu 10 KB-ko blokeak aldi berean bi taulatan idaztea 600 MB/seg inguruko abiaduran gertatzen dela bakoitzean (guztira 1275 MB/seg), eta horrek bat dator taula batean 623 MB/seg idazteko abiadurarekin (ikus goiko 11. zenbakia)
Baina 50 KB-ko erregistroekin bigarren exekuzioak erakusten du deskarga-abiadura apur bat hazten ari dela, eta horrek adierazten du muga-balioetara hurbiltzen ari dela. Aldi berean, kontuan izan behar duzu HBASEn ia ez dagoela kargarik sortu, lehenik hbase:meta-ko datuak ematea da eta HFFiles lerrokatu ondoren, BlockCache-ko datuak berrezarri eta gorde MemStore buffer diskoan, hutsik ez badago.
3. HBASEko datuak irakurtzea
Suposatzen badugu bezeroak dagoeneko baduela hbase:meta-ko informazio guztia (ikus 2. puntua), eskaera zuzenean RS-ra doa behar den gakoa gordetzen den. Lehenik eta behin, bilaketa MemCache-n egiten da. Bertan datuak egon ala ez, bilaketa BlockCache bufferean eta, behar izanez gero, HFiles-en ere egiten da. Fitxategian datuak aurkitu badira, BlockCache-n jartzen dira eta hurrengo eskaeran azkarrago itzuliko dira. HFile-n bilaketa nahiko azkarra da Bloom iragazkiaren erabilerari esker, hau da. datu kopuru txiki bat irakurrita, berehala zehazten du fitxategi honek beharrezko gakoa duen ala ez eta, hala ez bada, hurrengora pasatzen da.
Hiru iturri hauetatik datuak jasota, RS-k erantzun bat sortzen du. Bereziki, objektu baten aurkitutako hainbat bertsio transferi ditzake aldi berean bezeroak bertsioa eskatu badu.
4. Datuen cachea
MemStore eta BlockCache buffer-ek esleitutako RS memoriaren % 80 arte hartzen dute (gainerakoa RS zerbitzu-zerbitzuetarako gordeta dago). Erabilera-modu tipikoa prozesuek datu berdinak idazten eta berehala irakurtzen dituztenean bada, orduan zentzuzkoa da BlockCache murriztea eta MemStore handitzea, izan ere. Datuak idazten ez direnean irakurtzeko cachean sartzen, BlockCache gutxiagotan erabiliko da. BlockCache buffer-ak bi atal ditu: LruBlockCache (beti pilatuta) eta BucketCache (normalean pilatik kanpo edo SSD batean). BucketCache irakurketa-eskaera asko daudenean eta LruBlockCache-n sartzen ez direnean erabili behar da, eta horrek Garbage Collector-en lan aktiboa dakar. Aldi berean, ez zenuke errendimenduaren gorakada erradikala espero behar irakurritako cachea erabiltzeagatik, baina 8. paragrafoan itzuliko gara.
BlockCache bat dago RS osorako, eta MemStore bat dago taula bakoitzeko (bat zutabe-familia bakoitzeko).
Bezala teorian, idazterakoan, datuak ez dira cachean sartzen eta, hain zuzen ere, taularako CACHE_DATA_ON_WRITE eta RSrako "Cache DATA on Write" parametroak faltsu gisa ezartzen dira. Hala ere, praktikan, MemStore-n datuak idazten baditugu, gero diskora garbitu (horrela garbitzen dugu), eta gero ezabatu sortzen den fitxategia, orduan lortu eskaera bat exekutatuta datuak ongi jasoko ditugu. Gainera, BlockCache erabat desgaitu eta taula datu berriekin betetzen baduzu, gero MemStore diskora berrezarri, ezabatu eta beste saio batetik eskatu, oraindik nonbaitetik berreskuratuko dira. Beraz, HBase-k datuak ez ezik, misterio misteriotsuak ere gordetzen ditu.
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
"Cache DATA on Read" parametroa faltsua da. Ideiarik baduzu, ongi etorri iruzkinetan eztabaidatzera.
5. Batch datuen tratamendua MultiGet/MultiPut
Eskaera bakarrak prozesatzea (Lortu/Jarri/Ezabatu) nahiko eragiketa garestia da, beraz, ahal izanez gero, Zerrenda edo Zerrenda batean konbinatu beharko zenituzke, eta horrek errendimendu handiago bat lortzeko aukera ematen dizu. Hau bereziki egia da idazketa-eragiketari dagokionez, baina irakurtzean honako zuloa dago. Beheko grafikoak MemStoreko 50 erregistro irakurtzeko denbora erakusten du. Irakurketa hari batean egin da eta ardatz horizontalak eskaeraren gako kopurua erakusten du. Hemen ikus dezakezu eskaera batean mila gakoetara handitzean, exekuzio denbora jaisten dela, hau da. abiadura handitzen da. Hala ere, MSLAB modua lehenespenez gaituta dagoenez, atalase horren ondoren errendimenduaren beherakada nabarmena hasten da, eta zenbat eta datu kopuru handiagoa erregistroan, orduan eta luzeagoa izango da funtzionamendu-denbora.
Probak makina birtual batean egin ziren, 8 nukleoan, HBase 2.0.0-cdh6.0.0-beta1 bertsioan.
MSLAB modua pilaren zatiketa murrizteko diseinatuta dago, belaunaldi berriko eta zaharreko datuak nahasteagatik gertatzen dena. Konponbide gisa, MSLAB gaituta dagoenean, datuak gelaxka txiki samarretan (zatietan) jartzen dira eta zatika prozesatzen dira. Ondorioz, eskatutako datu-paketearen bolumenak esleitutako tamaina gainditzen duenean, errendimendua nabarmen jaisten da. Bestalde, modu hau desaktibatzea ere ez da komeni, datuen tratamendu intentsiboko uneetan GCren ondorioz geldialdiak eragingo baititu. Irtenbide on bat zelula-bolumena handitzea da idazketa aktiboaren kasuan, put bidez irakurketaren aldi berean. Kontuan izan behar da arazoa ez dela gertatzen, grabatu ondoren, MemStore diskoan berrezartzen duen garbiketa komandoa exekutatzen baduzu edo BulkLoad erabiliz kargatzen baduzu. Beheko taulak erakusten du MemStore-tik datu handiagoak (eta kopuru berekoak) egindako kontsultak moteltzea eragiten duela. Hala ere, zatiaren tamaina handituz prozesatzeko denbora normaltasunera itzuliko dugu.
Chunksia handitzeaz gain, datuak eskualdeka banatzeak laguntzen du, hau da. mahai zatiketa. Horren ondorioz, eskualde bakoitzerako eskaera gutxiago iristen dira eta gelaxka batean sartzen badira, erantzuna ona izaten jarraitzen du.
6. Taulak eskualdetan banatzeko estrategia (banatzea)
HBase gako-balioen biltegiratze bat denez eta partizioa gakoz egiten denez, oso garrantzitsua da datuak eskualde guztietan uniformeki banatzea. Adibidez, taula hori hiru zatitan banatzeak datuak hiru eskualdetan banatuko ditu:
Gertatzen da horrek moteltze handia ekartzen duela gero kargatutako datuek, adibidez, balio luzeak badituzte, gehienak zifra beretik hasten direnak, adibidez:
1000001
1000002
...
1100003
Gakoak byte-matrize gisa gordetzen direnez, guztiak berdin hasiko dira eta #1 eskualde berekoak izango dira gako sorta hau gordetzeko. Hainbat zatiketa estrategia daude:
HexStringSplit - Gakoa kodetutako kate hamaseimal batean bihurtzen du "00000000" barrutian => "FFFFFFFF" eta ezkerraldean zeroekin betetzea.
UniformSplit - Gakoa "00" => "FF" barrutian kodeketa hamaseimala duen byte-matrize bihurtzen du eta eskuinaldean zeroekin betetzea.
Horrez gain, zatitzeko eta zatiketa automatikorako konfiguratzeko edozein sorta edo gako multzo zehaztu dezakezu. Hala ere, hurbilketa sinple eta eraginkorrenetako bat UniformSplit eta hash kateamendua erabiltzea da, adibidez, gakoa CRC32(rowkey) funtzioaren eta rowkey bera exekutatzeko byte-pare esanguratsuena:
hash + rowkey
Ondoren, datu guztiak uniformeki banatuko dira eskualdeetan. Irakurtzean, lehenengo bi byteak baztertzen dira eta jatorrizko gakoa geratzen da. RS-k eskualdeko datu eta gako kopurua ere kontrolatzen du eta, mugak gainditzen badira, automatikoki zatitan zatitzen du.
7. Akatsen tolerantzia eta datuen lokaltasuna
Gako-multzo bakoitzaren erantzule eskualde bakarra denez, RS-ren hutsegiteekin edo deskargarekin lotutako arazoen konponbidea HDFSn beharrezkoak diren datu guztiak gordetzea da. RS erortzen denean, maisuak hau detektatzen du ZooKeeper nodoan taupadak ez direlako. Ondoren, zerbitzatutako eskualdea beste RS bati esleitzen dio eta HFfileak fitxategi sistema banatu batean gordetzen direnez, jabe berriak irakurtzen ditu eta datuak zerbitzatzen jarraitzen du. Hala ere, datu batzuk MemStore-n egon daitezkeenez eta HFiles-en sartzeko astirik izan ez dutenez, WAL, HDFS-n ere gordetzen dena, eragiketen historia berreskuratzeko erabiltzen da. Aldaketak aplikatu ondoren, RS-k eskaerei erantzuteko gai da, baina mugimenduak datu batzuk eta haiek zerbitzatzen dituzten prozesuek nodo ezberdinetan amaitzea dakar, hau da. lokala gutxitzen ari da.
Arazoaren konponbidea trinkotze handia da - prozedura honek fitxategiak haien arduradunak diren nodoetara eramaten ditu (haien eskualdeak dauden tokietara), eta, ondorioz, prozedura honetan sarean eta diskoen karga nabarmen handitzen da. Hala ere, etorkizunean datuetarako sarbidea nabarmen bizkortzen da. Gainera, major_compaction-ek HFile guztiak eskualde bateko fitxategi batean bateratzen ditu eta datuak garbitzen ditu taularen ezarpenen arabera. Adibidez, gorde behar den objektu baten bertsio kopurua edo objektua fisikoki ezabatuko den iraupena zehaztu dezakezu.
Prozedura honek oso eragin positiboa izan dezake HBaseren funtzionamenduan. Beheko irudiak erakusten du errendimendua nola hondatu den datuen grabazio aktiboaren ondorioz. Hemen ikus dezakezu 40 hari taula batean nola idatzi duten eta 40 hari aldi berean datuak irakurtzen dituzten. Idazteko hariak gero eta HFitxategi gehiago sortzen dira, beste hari batzuek irakurtzen dituztenak. Ondorioz, gero eta datu gehiago kendu behar dira memoriatik eta azkenean GC funtzionatzen hasten da, eta horrek ia lan guztia geldiarazten du. trinkotze handia martxan jartzeak ondoriozko hondakinak garbitzea eta produktibitatea berreskuratzea ekarri zuen.
Proba 3 DataNodes eta 4 RS-tan egin zen (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 hari). HBase bertsioa 1.2.0-cdh5.14.2
Aipatzekoa da trinkotze handia "zuzeneko" taula batean abiarazi zela, eta bertan datuak aktiboki idatzi eta irakurri ziren. Sarean, datuak irakurtzerakoan erantzun oker bat ekar zezakeela adierazi zuen. Egiaztatzeko, datu berriak sortu eta taula batean idatzi zituen prozesu bat abiarazi zen. Horren ondoren, berehala irakurri eta egiaztatu nuen ea emaitzaren balioa bat zetorren idatzitakoarekin. Prozesu hau martxan zegoen bitartean, trinkotze handia 200 aldiz egin zen eta ez zen hutsegite bakar bat ere erregistratu. Agian arazoa oso gutxitan agertzen da eta karga handian bakarrik, beraz, seguruagoa da idazketa- eta irakurketa-prozesuak aurreikusitako moduan gelditzea eta garbiketa egitea, GC-ren murrizketa saihesteko.
Gainera, trinkotze handiak ez dio MemStore-ren egoerari eragiten; diskora garbitzeko eta trinkotzeko, garbiketa erabili behar duzu (connection.getAdmin().flush(TableName.valueOf(tblName))).
8. Ezarpenak eta errendimendua
Esan bezala, HBase-k bere arrakastarik handiena erakusten du ezer egin behar ez duen tokian, BulkLoad exekutatzen denean. Hala ere, sistema eta pertsona gehienei aplikatzen zaie. Hala ere, tresna hau egokiagoa da datuak bloke handietan masiboki gordetzeko, prozesuak irakurketa- eta idazketa-eskaera anitz eskatzen baditu, goian deskribatutako Lortu eta Jarri komandoak erabiltzen dira. Parametro optimoak zehazteko, taularen parametroen eta ezarpenen hainbat konbinaziorekin abiarazi ziren:
- 10 hari aldi berean abiarazi ziren 3 aldiz jarraian (dei diezaiogun hari bloke bat).
- Bloke bateko hari guztien funtzionamendu-denbora batez bestekoa zen eta blokearen eragiketaren azken emaitza zen.
- Hari guztiak mahai berdinarekin lan egin zuten.
- Hari-blokearen hasiera bakoitzaren aurretik, trinkotze handia egin zen.
- Bloke bakoitzak eragiketa hauetako bakarra egin zuen:
-Jarri
β Lortu
βLortu+Jarri
- Bloke bakoitzak bere funtzionamenduaren 50 iterazio egin zituen.
- Erregistro baten bloke-tamaina 100 byte, 1000 byte edo 10000 byte da (ausazko).
- Blokeak eskatutako gako kopuru ezberdinekin abiarazi ziren (tekla bat edo 10).
- Blokeak mahaiaren ezarpen ezberdinetan exekutatu ziren. Parametroak aldatu dira:
β BlockCache = aktibatuta edo desaktibatuta
β BlockSize = 65 KB edo 16 KB
β Partizioak = 1, 5 edo 30
β MSLAB = gaituta edo desgaituta
Beraz, blokeak itxura hau du:
a. MSLAB modua aktibatu/desaktibatu da.
b. Parametro hauek ezarri ziren taula bat sortu zen: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
c. Konpresioa GZn ezarri zen.
d. 10 hari abiarazi ziren aldi berean 1/10 put/get/get+put eragiketak egiten taula honetan 100/1000/10000 byteko erregistroekin, 50 kontsulta jarraian eginez (ausazko gakoak).
e. d puntua hiru aldiz errepikatu zen.
f. Hari guztien funtzionamendu-denbora batez bestekoa izan da.
Konbinazio posible guztiak probatu ziren. Aurreikus daiteke erregistroaren tamaina handitzen den heinean abiadura jaitsi egingo dela edo cachea desgaitzeak moteltzea eragingo duela. Hala ere, parametro bakoitzaren eraginaren maila eta esangura ulertzea zen helburua, beraz, bildutako datuak erregresio lineal funtzio baten sarreran sartu ziren, eta horrek esangura t-estatistikak erabiliz ebaluatzea ahalbidetzen du. Jarraian Put eragiketak egiten dituzten blokeen emaitzak daude. Konbinazio multzo osoa 2*2*3*2*3 = 144 aukera + 72 tk. batzuk bi aldiz egin zituzten. Beraz, 216 lasterketa dira guztira:
Probak 3 DataNodes eta 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 hari) osatutako minikluster batean egin ziren. HBase bertsioa 1.2.0-cdh5.14.2.
3.7 segundoko txertatze-abiadura handiena MSLAB modua desaktibatuta lortu da, partizio bat duen mahai batean, BlockCache gaituta, BlockSize = 16, 100 byteko erregistroak, 10 pieza pakete bakoitzeko.
82.8 segundoko txertatze-abiadura baxuena MSLAB modua gaituta lortu da, partizio bat duen taula batean, BlockCache gaituta, BlockSize = 16, 10000 byteko erregistroak, bakoitza 1.
Ikus dezagun orain eredua. R2n oinarritutako ereduaren kalitate ona ikusten dugu, baina guztiz argi dago hemen estrapolazioa kontraindikatuta dagoela. Parametroak aldatzen direnean sistemaren benetako portaera ez da lineala izango; eredu hau ez da beharrezkoa iragarpenetarako, emandako parametroetan gertatutakoa ulertzeko baizik. Adibidez, hemen Ikaslearen irizpidearen arabera ikusten dugu BlockSize eta BlockCache parametroek ez dutela axola Put eragiketarako (normalean nahiko aurreikusgarria dena):
Baina partizio kopurua handitzeak errendimenduaren murrizketa dakarrela ezustekoa da (dagoeneko ikusi dugu BulkLoad-ekin partizio kopurua handitzeak duen eragin positiboa), ulergarria bada ere. Lehenik eta behin, prozesatzeko, 30 eskualdetara eskaerak sortu behar dituzu baten ordez, eta datuen bolumena ez da irabazia emango duen. Bigarrenik, funtzionamendu-denbora osoa RS motelenak zehazten du, eta DataNode kopurua RS kopurua baino txikiagoa denez, eskualde batzuek zero toki dute. Tira, ikus ditzagun lehen bostei:
Orain ebalua ditzagun Get blokeak exekutatzeko emaitzak:
Partizio kopuruak garrantzia galdu du, ziurrenik datuak cachean ondo gordeta egoteak eta irakurritako cachea (estatistikoki) parametrorik esanguratsuena izateak azaltzen du. Jakina, eskaera bateko mezu kopurua handitzea ere oso erabilgarria da errendimendurako. Puntuazio onenak:
Tira, azkenik, ikus dezagun lehen lortu eta gero jarri zuen blokearen eredua:
Hemen parametro guztiak esanguratsuak dira. Eta buruzagien emaitzak:
9. Karga-probak
Beno, azkenean karga gutxi-asko duin bat jarriko dugu martxan, baina beti da interesgarriagoa zerekin alderatzeko duzunean. DataStax-en webgunean, Cassandraren garatzaile nagusia, dago NoSQL biltegiratze batzuen NT, HBase 0.98.6-1 bertsioa barne. Kargatzea 40 hari, datuen tamaina 100 byte, SSD diskoen bidez egin zen. Irakurri-Aldatu-Idatzi eragiketen probak ondorengo emaitzak erakutsi zituen.
Nik ulertzen dudanez, irakurketa 100 erregistroko blokeetan egin zen eta 16 HBase nodoetarako, DataStax probak segundoko 10 mila operazioko errendimendua erakutsi zuen.
Zorionekoa da gure klusterrak ere 16 nodo izatea, baina ez da oso βzortetsuaβ bakoitzak 64 nukleo (hariak) izatea, DataStax proban, berriz, 4 baino ez. Bestalde, SSD unitateak dituzte, guk HDDak ditugun bitartean. edo gehiago HBase-ren eta CPU-ren erabileraren bertsio berria kargan zehar ia ez zen nabarmen handitu (ikusmenean ehuneko 5-10). Hala ere, saia gaitezen konfigurazio hau erabiltzen hasten. Taularen ezarpen lehenetsiak, irakurketa 0 eta 50 milioi bitarteko gakoen artean egiten da ausaz (hau da, funtsean, aldi bakoitzean berria). Taulak 50 milioi erregistro ditu, 64 partiziotan banatuta. Gakoak hash egiten dira crc32 erabiliz. Taularen ezarpenak lehenetsiak dira, MSLAB gaituta dago. 40 hari abiaraziz, hari bakoitzak ausazko 100 gako multzo bat irakurtzen du eta berehala idatziko ditu sortutako 100 byteak gako horietara.
Stand: 16 DataNode eta 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 hari). HBase bertsioa 1.2.0-cdh5.14.2.
Batez besteko emaitza segundoko 40 mila eragiketatik gertuago dago, hau da, DataStax proban baino nabarmen hobea da. Hala ere, helburu esperimentaletarako, baldintzak apur bat alda ditzakezu. Oso zaila da lan guztiak mahai batean soilik egitea, eta gako bakarrean ere bakarrik. Demagun karga nagusia sortzen duen gako multzo "bero" bat dagoela. Hori dela eta, saia gaitezen karga bat sortzen erregistro handiagoekin (10 KB), 100eko sortetan ere, 4 taula ezberdinetan eta eskatutako gakoen sorta 50 milara mugatuz.Beheko grafikoan 40 hariren abiarazpena erakusten da, hari bakoitzak irakurtzen du. 100 gako multzo bat eta berehala idazten du ausazko 10 KB tekla horien atzealdean.
Stand: 16 DataNode eta 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 hari). HBase bertsioa 1.2.0-cdh5.14.2.
Karga bitartean, trinkotze handia abiarazi zen hainbat aldiz, goian erakusten den moduan, prozedura hori gabe, errendimendua pixkanaka degradatuko da, baina karga gehigarria ere sortzen da exekuzioan zehar. Mozketak hainbat arrazoirengatik sortzen dira. Batzuetan hariak funtzionatzen amaitu zuten eta berrabiarazi bitartean eten bat zegoen, beste batzuetan hirugarrenen aplikazioek karga bat sortzen zuten klusterrean.
Irakurtzea eta berehala idaztea da HBaserentzat lan agertoki zailenetako bat. Eskaera txikiak bakarrik egiten badituzu, adibidez 100 byte, 10-50 mila piezako paketeetan konbinatuz, ehunka mila eragiketa lortu ditzakezu segundoko, eta egoera antzekoa da irakurtzeko soilik diren eskaerekin. Aipatzekoa da emaitzak DataStax-ek lortutakoak baino erradikalki hobeak direla, batez ere 50 milako blokeetan egindako eskaerak direla eta.
Stand: 16 DataNode eta 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 hari). HBase bertsioa 1.2.0-cdh5.14.2.
10. Ondorioak
Sistema hau nahiko malgutasunez konfiguratuta dago, baina parametro ugariren eragina oraindik ezezaguna da. Horietako batzuk probatu ziren, baina ez ziren lortutako proba multzoan sartu. Esate baterako, aurretiazko esperimentuek DATA_BLOCK_ENCODING bezalako parametro baten esangura hutsala erakutsi zuten, informazioa kodetzen duena ondoko zelulen balioak erabiliz, ausaz sortutako datuetarako ulergarria dena. Objektu bikoiztu ugari erabiltzen badituzu, irabazia nabarmena izan daiteke. Orokorrean, esan dezakegu HBase-k datu-base aski serio eta ondo pentsatua ematen duela, datu-bloke handiekin eragiketak egitean nahiko emankorra izan daitekeena. Batez ere irakurketa eta idazketa prozesuak denboran bereiztea posible bada.
Zure ustez nahikoa ezagutarazi ez den zerbait baldin badago, zehatzago esateko prest nago. Zure esperientzia partekatzera edo zerbaitekin ados ez bazaude eztabaidatzera gonbidatzen zaitugu.
Iturria: www.habr.com