HBase erabiltzearen teoria eta praktika

Kaixo! Danil Lipovoy naiz, eta Sbertech-eko gure taldeak HBase erabiltzen hasi da datu-biltegi operatibo gisa. Hura aztertzen ari ginela, esperientzia baliotsua metatu dugu, sistematizatu eta deskribatu nahi izan duguna (espero dugu askorentzat baliagarria izatea). Jarraian agertzen diren esperimentu guztiak HBase 1.2.0-cdh5.14.2 eta 2.0.0-cdh6.0.0-beta1 bertsioekin egin ziren.

1. Arkitektura orokorra
2. Datuak HBASE-ra idaztea
3. HBASE-tik datuak irakurtzea
4. Datuen cachea
5. MultiGet/MultiPut datu-prozesamendu sorta
6. Taulak eskualdeetan banatzeko (banaketa) estrategia
7. Akatsen tolerantzia, trinkotasuna eta datuen lokalitatea
8. Ezarpenak eta errendimendua
9. Estres probak
10. Findings

1. Arkitektura orokorra

Erreserbako maisuak nodoko ZooKeeper aktiboaren taupadak entzuten ditu eta maisuaren funtzioak hartzen ditu desagertzen bada.

2. Datuak HBASE-n idaztea

Lehenik eta behin, kasurik sinpleena aztertuko dugu: gako-balio objektu bat taula batean idaztea put(rowkey) erabiliz. Bezeroak lehenik Root Region Server-en (RRS) kokapena zehaztu behar du, eta honek hbase:meta taula gordetzen du. Informazio hau ZooKeeper-etik lortzen du. Ondoren, RRS-ra sartzen da eta hbase:meta taula irakurtzen du, eta bertatik informazioa berreskuratzen du intereseko taulan errenkada-gako jakin baterako datuak gordetzeaz arduratzen den RegionServer (RS) zein den jakiteko. Etorkizunean erabiltzeko, metataula bezeroak cachean gordetzen du, beraz, ondorengo sarbideak azkarragoak dira eta zuzenean RS-ra joaten dira.

Eskaera bat jasotzean, RS-k lehenik WriteAheadLog-en (WAL) idazten du, eta hori beharrezkoa da hutsegite baten kasuan berreskuratzeko. Ondoren, datuak MemStore-n gordetzen ditu, eskualde jakin baterako gako multzo ordenatu bat duen memoria-bufferrean. Taula bat eskualdeetan (partizioetan) bana daiteke, eta bakoitzak gako multzo disjuntu bat du. Horri esker, errendimendu handiagoa lortu ahal izango da eskualdeak zerbitzari desberdinetan jarriz. Hala ere, baieztapen ageriko hau gorabehera, geroago ikusiko dugu honek ez duela kasu guztietan funtzionatzen.

Erregistro bat MemStore-n jarri ondoren, bezeroak erregistroa behar bezala gorde dela adierazten duen erantzun bat jasotzen du. Hala ere, erregistroa bufferrean bakarrik gordetzen da eta diskoan idatziko da denbora-tarte jakin bat igaro ondoren edo bufferra datu berriekin betetzen denean bakarrik.

"Ezabatu" eragiketa egiten denean, datuak ez dira fisikoki ezabatzen. Ezabatuta bezala markatzen dira besterik gabe, eta suntsipena bera funtzio trinko nagusia deitzen denean gertatzen da, eta hori 7. atalean zehatzago deskribatzen da.

HFile formatuko fitxategiak HDFS-n pilatzen dira, eta noizean behin, prozesu trinko txiki bat exekutatzen da, fitxategi txikiak handiagoetan batzen dituena ezer ezabatu gabe. Denborarekin, hau datuak irakurtzean bakarrik agertzen den arazo bihurtzen da (geroago itzuliko gara gai honetara).

Goian deskribatutako kargatze-prozesuaz gain, prozedura askoz eraginkorrago bat dago, agian datu-base honen ezaugarririk indartsuena dena: BulkLoad. HFileak eskuz sortzea eta diskoan kargatzea dakar, eskalagarritasun bikaina eta abiadura nahiko errespetagarriak lortuz. Funtsean, hemengo muga ez da HBase, hardwarearen gaitasunak baizik. Jarraian, 16 RegionServer eta 16 YARN NodeManager (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 hari) dituen kluster batean lortutako kargatze-emaitzak ageri dira, HBase 1.2.0-cdh5.14.2 bertsioa.

Hemen ikusten dugu taulako partizio (eskualde) kopurua handitzeak, baita Spark exekutatzaileak ere, kargatzeko abiadura handitzen duela. Abiadura idazketa-bolumenaren araberakoa ere bada. Bloke handiek MB/seg-ko igoera ematen dute, eta bloke txikiek, berriz, denbora-unitateko txertatutako erregistro kopuruaren igoera, gainerako guztia berdin mantenduz.

Bi taula aldi berean kargatu ditzakezu abiadura bikoizteko. Jarraian, ikus dezakezu 10 KB-ko blokeak bi tauletan aldi berean idazteak 600 MB/seg inguruko abiadura duela bakoitzean (guztira 1275 MB/seg), hau da, taula bakar batean 623 MB/seg-tan idaztearen berdina (ikus goiko 11. puntua).

Bigarren exekuzioak 50 KB erregistroekin erakusten du kargatzeko abiadura apur bat baino ez dela handitzen, eta horrek adierazten du balio maximoak hurbiltzen ari direla. Garrantzitsua da kontuan izatea HBASE bera ia ez dagoela kargarik hemen. Egin behar duen guztia lehenik datuak hbase:meta-tik berreskuratzea da, eta gero, HFiles-en babeskopia egin ondoren, BlockCache datuak hustu eta MemStore bufferra diskoan gordetzea hutsik ez badago.

3. HBASE-tik datuak irakurtzea

hbase:meta-ko informazio guztia bezeroarentzat eskuragarri dagoela suposatuz (ikus 2. puntua), eskaera zuzenean RS-ra doa, non beharrezko gakoa gordeta dagoen. Bilaketa lehenik MemCache-n egiten da. Datuak bertan dauden ala ez kontuan hartu gabe, bilaketa BlockCache bufferrean ere egiten da eta, beharrezkoa bada, HFiles-en. Datuak fitxategi batean aurkitzen badira, BlockCache-n jartzen dira eta hurrengo eskaeran azkarrago itzuliko dira. HFile-n bilatzea nahiko azkarra da Bloom iragazki bat erabiltzeari esker; datu kopuru txiki bat irakurri ondoren, berehala zehazten du fitxategiak beharrezko gakoa duen ala ez, eta hala ez bada, hurrengo fitxategira pasatzen da.

Hiru iturri hauetatik datuak jaso ondoren, RS-k erantzun bat sortzen du. Zehazki, objektu baten hainbat bertsio aldi berean transmititu ditzake bezeroak bertsioa eskatu badu.

4. Datuen cachea

MemStore eta BlockCache bufferrek RS-n esleitutako heap memoriaren % 80 arte hartzen dute (gainerakoa RS zerbitzu-zereginetarako gordeta dago). Erabilera-modu tipikoa prozesuek datu berdinak idazten eta berehala irakurtzen badituzte, zentzuzkoa da BlockCache murriztea eta MemStore handitzea, datuak idazterakoan irakurketa-cachea ez baita ukitzen eta BlockCache gutxiagotan erabiliko baita. BlockCache bufferrak bi zati ditu: LruBlockCache (beti heap-ean) eta BucketCache (normalean heap-etik kanpo edo SSD-an). BucketCache erabili behar da irakurketa-eskaera asko daudenean eta LruBlockCache-n sartzen ez direnean, eta horrek Zabor-biltzailearen jarduera aktiboa eragiten du. Hala ere, ez zenuke errendimenduaren hobekuntza nabarmenik espero behar irakurketa-cachea erabiltzeagatik, baina 8. urratsean itzuliko gara honetara.

RS osoarentzako BlockCache bat dago, eta taula bakoitzak bere MemStore propioa du (zutabe-familia bakoitzeko bat).

Bezala deskribatu Teorian, cachean idatzitako datuak ez dira idazten, eta, hain zuzen ere, CACHE_DATA_ON_WRITE taularen parametroa eta "Cache DATA on Write" RS parametroa faltsu gisa ezarrita daude. Hala ere, praktikan, datuak MemStore-n idazten badituzu, gero diskoan gordetzen badituzu (horrela garbituz), eta gero emaitza den fitxategia ezabatzen baduzu, datuak arrakastaz berreskuratuko dituzu GET eskaera bat exekutatuz. Gainera, BlockCache erabat desgaitu eta taula datu berriekin betetzen baduzu ere, gero MemStore diskoan gordetzen baduzu, ezabatu eta beste saio batetik kontsultatzen baduzu ere, datuak nonbaitetik berreskuratuko dira oraindik. Beraz, HBase-k ez ditu datuak bakarrik gordetzen, baita misterio misteriotsuak ere.

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 false gisa ezarrita dago. Ideiarik baduzu, mesedez, eztabaidatu iruzkinetan.

5. Datuen multzoen prozesamendua MultiGet/MultiPut

Eskaera bakarrak prozesatzea (Get/Put/Delete) nahiko garestia da, beraz, ahal den guztietan zerrenda edo zerrenda batean konbinatzeak errendimendua nabarmen hobetu dezake. Hori bereziki egia da idazketa eragiketetan, baina irakurketak arazo bat dakar. Beheko grafikoak MemStore-tik 50.000 erregistro irakurtzeko behar den denbora erakusten du. Irakurketa hari bakarrean egin zen, eta ardatz horizontalak eskaerako gako kopurua erakusten du. Argi dago eskaera bakarreko gako kopurua milara handitzen den heinean, exekuzio denbora gutxitzen dela, eta horrek esan nahi du errendimendua handitzen dela. Hala ere, MSLAB modua lehenespenez gaituta dagoenean, errendimendua nabarmen jaisten hasten da atalase horretatik gora, erregistroko datu bolumena zenbat eta handiagoa izan, orduan eta luzeagoa izango da exekuzio denbora.

Probak makina birtual batean egin ziren, 8 nukleo dituena, HBase 2.0.0-cdh6.0.0-beta1 bertsioan.

MSLAB modua belaunaldi berri eta zaharretako datuak nahastean sortzen den heap zatikatzea murrizteko diseinatuta dago. Arazo hau konpontzeko, MSLAB gaituta dagoenean, datuak zati txiki samarretan jartzen dira eta zatika prozesatzen dira. Ondorioz, eskatutako datu-pakete baten tamaina esleitutako tamaina gainditzen duenean, errendimendua nabarmen jaisten da. Hala ere, modu hau desgaitzea ere ez da desiragarria, GC geldialdiak eragingo baititu datu-sarbide intentsiboko aldietan. Irtenbide ona da zatiaren tamaina handitzea idazketa aktiboen kasuan, irakurketekin batera put bidez. Kontuan izan behar da arazo hau ez dela gertatzen idazketa baten ondoren flush komando bat exekutatzen bada, MemStore diskoan garbitzen duena, edo kargatzea BulkLoad erabiliz egiten bada. Beheko taulan erakusten da MemStore-tik datu handiago (eta berdin-berdinak) egiteko eskaerek moteltzea eragiten dutela. Hala ere, zatiaren tamaina handitzeak prozesatzeko denbora normaltasunera itzultzen du.

Zati-tamaina handitzeaz gain, datuak eskualdeka banatzea, hau da, taula zatitzea, lagungarria da. Horrek esan nahi du eskaera gutxiago bidaltzen direla eskualde bakoitzera, eta gelaxka baten barruan sartzen badira, erantzuna ona izaten jarraitzen du.

6. Taulak eskualdeetan banatzeko estrategia (isuria)

HBase gako-balio biltegi bat denez eta partizioak gakoen arabera egiten direnez, ezinbestekoa da datuak eskualde guztietan berdin banatzea. Adibidez, taula hori hiru zatitan partitzeak datuak hiru eskualdetan banatuko lituzke:

Batzuetan, moteltze handia eragin dezake geroago kargatzen diren datuak, adibidez, balio luzeak badira, gehienetan zenbaki berarekin hasten direnak, adibidez:

1000001
1000002
...
1100003

Giltzak byte-array gisa gordetzen direnez, guztiak modu berean hasiko dira eta 1. eskualde berekoak izango dira, eta eskualde horrek giltza-tarte hau gordetzen du. Hainbat partizio-estrategia daude:

HexStringSplit – Gako bat kate bihurtzen du "00000000" => "FFFFFFFF" tarteko kodeketa hamaseitarrarekin eta ezkerrean zeroekin beteta.

UniformSplit – Gako bat byte-array bihurtzen du "00" => "FF" tarteko kodeketa hamaseitarrarekin eta eskuinean zeroekin beteta.

Gainera, zatitzeko edozein gako-tarte edo multzo zehaztu dezakezu eta zatiketa automatikoa konfigura dezakezu. Hala ere, hurbilketa sinple eta eraginkorrenetako bat UniformSplit da eta hash kateatzearen erabilera, adibidez, gakoa CRC32(errenkada) funtzioaren bidez exekutatzean lortutako byte bikote esanguratsuena eta errenkada-gakoa bera:

hash + errenkada-gakoa

Orduan, datu guztiak eskualdeetan uniformeki banatuko dira. Irakurtzerakoan, lehen bi byteak baztertu besterik ez dira egiten, jatorrizko gakoa utziz. RS-k eskualde bateko datu eta gako kopurua ere kontrolatzen du eta automatikoki zatitan banatzen du mugak gainditzen badira.

7. Akatsen tolerantzia eta datuen lokalitatea

Eskualde bakarra arduratzen denez gako multzo bakoitzerako, RS huts egitearekin edo desegitearekin lotutako arazoen konponbidea beharrezko datu guztiak HDFSn gordetzea da. RS bat huts egiten duenean, maisuak hau detektatzen du ZooKeeper nodoan bihotz-taupadarik ez dagoelako. Ondoren, zerbitzatzen duen eskualdea beste RS bati esleitzen dio. HFiles fitxategi-sistema banatu batean gordetzen direnez, maisu berriak irakurtzen ditu eta datuak zerbitzatzen jarraitzen du. Hala ere, datu batzuk MemStore-n egon daitezkeenez eta oraindik ez direnez HFiles-era transferitu, WAL, HDFSn gordeta ere, erabiltzen da eragiketa-historia leheneratzeko. Aldaketak aplikatu ondoren, RS-ak eskaerei erantzuteko gai da, baina mugimenduak datu batzuk eta zerbitzatzen dituzten prozesuak nodo desberdinetan kokatzea eragiten du, tokikotasuna murriztuz.

Irtenbidea trinkotze handia da. Prozedura honek fitxategiak haien ardura duten nodoetara eramaten ditu (beren eskualdeak dauden tokira), eta horrek sarearen eta diskoaren karga nabarmen handitzen du prozesu honetan. Hala ere, datuetarako sarbidea askoz azkarragoa da geroago. Gainera, major_compaction-ek HFile guztiak eskualde bateko fitxategi bakarrean konbinatzen ditu eta datuak garbitzen ditu taularen ezarpenen arabera. Adibidez, gorde beharreko objektuen bertsio kopurua edo objektua fisikoki ezabatzeko iraupena zehaztu dezakezu.

Prozedura honek eragin oso positiboa izan dezake HBase-ren errendimenduan. Beheko irudiak datu idazketa astunen ondorioz errendimendua nola hondatu den erakusten du. 40 hari taula bakar batean idazten eta 40 hari datuak aldi berean irakurtzen erakusten ditu. Idazketa hariek gero eta HFile gehiago sortzen dituzte, eta gero beste hari batzuek irakurtzen dituzte. Ondorioz, gero eta datu gehiago kendu behar dira memoriatik, eta azkenean, GC-k aktibatzen da, lan guztia ia paralizatuz. Trinkotze handia exekutatzeak atzerapen hori garbitu eta errendimendua berreskuratu zuen.

Proba 3 DataNode eta 4 RS-tan egin zen (Xeon E5-2680 v4 CPU @ 2.40GHz * 64 hari). HBase bertsioa 1.2.0-cdh5.14.2

Aipatzekoa da trinkotze handia taula aktibo batean exekutatu zela, datuak aktiboki idatziz eta irakurriz. Linean salaketak zeuden horrek datuak irakurtzean erantzun okerrak ekar zitzakeela. Hori egiaztatzeko, datu berriak sortu eta taulan idatzi zituen prozesu bat abiarazi zen. Ondoren, berehala irakurri eta emaitza den balioa idatzitako balioarekin bat zetorrela egiaztatu zuen. Prozesu honetan zehar, trinkotze handia 200 aldiz exekutatu zen gutxi gorabehera, eta ez zen hutsegite bakar bat ere erregistratu. Baliteke arazoa gutxitan eta karga handiko aldietan bakarrik gertatzea, beraz, seguruagoa da idazketak eta irakurketak aldizka gelditzea eta garbiketa egitea GC beherakada horiek saihesteko.

Era berean, trinkotze handiak ez du MemStore-ren egoeran eragiten; diskoan hustu eta trinkotzeko, flush (connection.getAdmin().flush(TableName.valueOf(tblName))) erabili behar duzu.

8. Ezarpenak eta errendimendua

Aurretik aipatu bezala, HBase-k arrakasta handiagoa du ezer egin behar ez duenean, hau da, BulkLoad exekutatzean. Hala ere, hau sistema eta pertsona gehienentzat aplikatzen da. Hala ere, tresna hau egokiagoa da bloke handietan datuak masiboki kargatzeko, prozesuak aldi berean irakurtzeko eta idazteko hainbat eskaera behar baditu, goian deskribatutako Get eta Put komandoak erabiltzen dira. Parametro optimoak zehazteko, taularen parametroen eta ezarpenen konbinazio desberdinekin probak egin genituen:

• 10 hari hasi ziren aldi berean 3 aldiz jarraian (dei diezaiogun hari-bloke honi).
• Bloke bateko hari guztien exekuzio-denboraren batez bestekoa kalkulatzen zen eta blokearen eragiketaren azken emaitza zen.
• Hari guztiek taula berarekin lan egin zuten.
• Hari-blokearen exekuzio bakoitzaren aurretik, trinkotze handia egin zen.
• Bloke bakoitzak honako eragiketa hauetako bat bakarrik egin zuen:

— Jarri
— Lortu
— Lortu+Jarri

• Bloke bakoitzak bere eragiketaren 50.000 errepikapen egin zituen.
• Bloke bateko erregistroaren tamaina 100 byte, 1000 byte edo 10000 byte (ausazkoa) da.
• Blokeak eskatutako gako kopuru desberdinekin abiarazi ziren (gako bat edo 10).
• Blokeak taula-ezarpen desberdinekin exekutatu ziren. Parametro hauek aldatu ziren:

— BlockCache = gaituta edo desgaituta
— Blokearen tamaina = 65 KB edo 16 KB
— Partizioak = 1, 5 edo 30
— MSLAB = piztuta edo itzalita

Beraz, blokea honelakoa da:

a. MSLAB modua piztu/itzali da.
b. Parametro hauek ezarrita dituen taula bat sortu da: BlockCache = true/none, BlockSize = 65/16 Kb, Partitions = 1/5/30.
c. GZ konpresioa ezarri zen.
d. 10 hari abiarazi ziren aldi berean, 100/1000/10000 byteko erregistroekin taula honetan 1/10 put/get/get+put eragiketa eginez, 50.000 eskaera jarraian exekutatuz (ausazko gakoak).
e. d puntua hiru aldiz errepikatu zen.
f. Hari guztien exekuzio-denboraren batez bestekoa kalkulatu da.

Konbinazio posible guztiak probatu ziren. Aurreikus zitekeen erregistroaren tamaina handitzeak errendimendua murriztuko zuela, edo cachea desgaitzeak moteltzeak ekarriko zituela. Hala ere, helburua parametro bakoitzaren eraginaren maila eta garrantzia ulertzea zen, beraz, bildutako datuak erregresio linealaren funtzio batean sartu ziren, eta horrek t-estatistikak erabiliz fidagarritasuna ebaluatzea ahalbidetzen du. Put eragiketak exekutatzen dituzten blokeen emaitzak behean erakusten dira. Konbinazio multzo osoa 2 * 2 * 3 * 2 * 3 = 144 aldaera + 72 da, batzuk bi aldiz exekutatu baitziren. Beraz, guztira 216 exekuzio:

Probak hiru DataNode eta lau RSz (Xeon E5-2680 v4 CPUak 2.40 GHz * 64 hari) osatutako mini-kluster batean egin ziren. HBase 1.2.0-cdh5.14.2 bertsioa.

Txertatze-abiadura handiena, 3.7 segundokoa, MSLAB modua desgaituta lortu zen, partizio bakarra zuen taula batean, BlockCache gaituta, BlockSize = 16, 100 byteko erregistroekin 10eko multzo batean.
Txertatze-abiadura baxuena, 82.8 segundokoa, MSLAB modua gaituta lortu zen, partizio bakarra zuen taula batean, BlockCache gaituta, BlockSize = 16, 10000 byteko erregistroekin, bana bakoitzeko.

Orain, eredua azter dezagun. Ereduaren kalitate ona ikusten dugu R2-ri dagokionez, baina argi dago hemen estrapolazioa kontraindikatuta dagoela. Sistemaren benetako portaera ez da lineala izango parametroak aldatzen diren heinean; eredu hau ez da beharrezkoa iragarpenetarako, baizik eta parametro horien barruan gertatu dena ulertzeko. Adibidez, hemen Student-en t-testaren bidez ikusten dugu BlockSize eta BlockCache parametroak ez direla garrantzitsuak Put eragiketarako (orokorrean nahiko aurreikusgarria dena):

Partizio kopurua handitzeak errendimendua gutxitzea dakar, baina ez da ustekabekoa (BulkLoad-ekin partizio kopurua handitzeak izan duen eragin positiboa ikusi dugu dagoeneko), nahiz eta ulergarria izan. Lehenik eta behin, prozesatzeak 30 eskualdetara kontsultak sortzea eskatzen du baten ordez, eta datu-bolumena ez da nahikoa errendimendua hobetzeko. Bigarrenik, exekuzio-denbora orokorra RS motelenak zehazten du, eta DataNode kopurua RS kopurua baino txikiagoa denez, eskualde batzuek zero lokalitatea dute. Ikus ditzagun bost nagusiak:

Orain ebaluatu ditzagun Get blokeak exekutatzearen emaitzak:

Partizio kopurua gutxiago esanguratsua bihurtu da, ziurrenik datuak ondo cachean gordeta daudelako eta irakurketa cachea delako parametrorik garrantzitsuena (estatistikoki). Jakina, kontsulta bakoitzeko mezu kopurua handitzea ere oso onuragarria da errendimenduarentzat. Emaitza onenak:

Beno, azkenik, lehenik get eta gero put egin dituen blokearen eredua azter dezagun:

Parametro guztiak dira garrantzitsuak hemen. Eta liderren emaitzak:

9. Karga-probak

Azkenik, lan-karga nahiko duin bat exekuta dezagun, baina beti da interesgarriagoa alderatzeko zerbait duzunean. DataStaxen webguneak, Cassandraren garatzaile nagusiak, honako hau du: Aurkikuntza NT hainbat NoSQL biltegiratze sistematarako, HBase 0.98.6-1 bertsioa barne. Kargatzea 40 hari erabiliz egin zen, 100 byteko datu-tamainarekin, SSD unitateak erabiliz. Irakurri-Aldatu-Idatzi proben emaitzek honako hau erakutsi zuten.

Ulertzen dudanez, irakurketa 100 erregistroko blokeetan egin zen, eta 16 HBase nodoetarako, DataStax probak segundoko 10 mila eragiketako errendimendua erakutsi zuen.

Zorionez, gure klusterrak ere 16 nodo ditu, baina ez hainbeste bakoitzak 64 nukleo (hari) dituelako, DataStax probak 4 bakarrik dituen bitartean. Bestalde, SSD unitateak dituzte, guk HDDak eta HBase bertsio berriago bat ditugun bitartean, beraz, kargapean CPUaren erabilera ia ez da handitu (nabarmen % 5-10). Hala ere, konfigurazio hau exekutatzen saiatuko gara. Taularen ezarpenak lehenetsiak dira: irakurketak ausaz egiten dira 0tik 50 milioira bitarteko gakoetan (hau da, funtsean, berri bat aldi bakoitzean). Taulak 50 milioi erregistro ditu, 64 partiziotan banatuta. Giltzak crc32 erabiliz hash egiten dira. Taularen ezarpenak lehenetsiak dira, eta MSLAB gaituta dago. 40 hari abiarazten ditugu, hari bakoitzak 100 ausazko gako multzo bat irakurtzen du eta berehala gako horietarako sortutako 100 byte idazten ditu.

Euskarria: 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.000 eragiketara hurbiltzen da, eta hori DataStax proban baino nabarmen hobea da. Hala ere, helburu esperimentaletarako, baldintzak apur bat alda daitezke. Oso zaila da lan guztia taula bakar batekin eta gako bakarrekin soilik egitea. Demagun kargaren zatirik handiena sortzen duen gako multzo "bero" bat dagoela. Beraz, karga erregistro handiagoekin (10 KB) sortzen saiatuko gara, 100eko multzoetan ere, lau taula ezberdinetan, eskatutako gakoen tartea 50.000ra mugatuz. Beheko grafikoak 40 hari exekutatzen erakusten ditu, hari bakoitzak 100 gakoko multzo bat irakurtzen eta berehala ausazko 10 KB idazten ditu gako horietara.

Euskarria: 16 DataNode eta 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 hari). HBase bertsioa 1.2.0-cdh5.14.2.

Kargatzean, trinkotze handia hainbat aldiz egin zen. Goian erakusten den bezala, prozedura hori gabe, errendimendua pixkanaka okerrera egingo luke. Hala ere, karga gehigarria ere gertatzen zen exekuzioan zehar. Jaitsierak hainbat faktoreren ondorioz gertatzen ziren. Batzuetan hariak amaitzen ziren, berrabiarazten ziren bitartean pausa bat eraginez, eta batzuetan hirugarrenen aplikazioek karga sortzen zuten klusterrean.

Irakurtzeko eta idazteko eragiketak dira HBase-rentzat lan-kargarik zorrotzenetako bat. 100 byteko kontsulta txikiak soilik erabiliz, esaterako, bakoitza 10-50 zatitan multzokatuta, ehunka mila eragiketa lor daitezke segundoko. Gauza bera gertatzen da irakurtzeko soilik diren kontsultekin. Aipatzekoa da emaitzak DataStax-ekin lortutakoak baino askoz hobeak direla, batez ere 50 byteko kontsulta-tamaina dela eta.

Euskarria: 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 malgua da konfigurazioan, baina parametro kopuru handi baten eragina ezezaguna da oraindik. Horietako batzuk probatu ziren, baina ez ziren azken proba multzoan sartu. Adibidez, aurretiazko esperimentuek DATA_BLOCK_ENCODING parametroarentzat garrantzi gutxi erakutsi zuten, zeinak informazioa ondoko gelaxketan dauden balioak erabiliz kodetzen duen, eta hori ulergarria da ausaz sortutako datuetarako. Objektu errepikakor kopuru handia erabiltzean, irabaziak nabarmenak izan daitezke. Oro har, HBase datu-base nahiko sendoa eta ondo diseinatua dela dirudi, eta nahiko produktiboa izan daiteke datu-bloke handiak maneiatzerakoan, batez ere irakurketak eta idazketak tartekatu badaitezke.

Behar adina azaldu ez dudan zerbaiten berri ematen baduzu, pozik azalduko dizut. Zure esperientziak partekatzera edo desadostasunak eztabaidatzera gonbidatzen zaitugu.

Iturria: www.habr.com