Goeie middag My naam is Danil Lipovoy, ons span by Sbertech het HBase as 'n berging vir operasionele data begin gebruik. In die loop van die bestudering daarvan het ervaring opgehoop wat ek wou sistematiseer en beskryf (ons hoop dat dit vir baie nuttig sal wees). Alle eksperimente hieronder is uitgevoer met HBase-weergawes 1.2.0-cdh5.14.2 en 2.0.0-cdh6.0.0-beta1.
- Algemene argitektuur
- Skryf data na HBASE
- Lees data van HBASE
- Datakas
- Batch data verwerking MultiGet/MultiPut
- Strategie om tabelle in streke te verdeel (verdeling)
- Foutverdraagsaamheid, kompaktering en datalokaliteit
- Instellings en prestasie
- Strestoetsing
- Bevindinge
1. Algemene argitektuur
Die rugsteunmeester luister na die hartklop van die aktiewe een op die ZooKeeper-knoop en neem, in geval van verdwyning, die funksies van die meester oor.
2. Skryf data na HBASE
Kom ons kyk eers na die eenvoudigste geval - die skryf van 'n sleutel-waarde-objek na 'n tabel met put(roeisleutel). Die kliënt moet eers uitvind waar die Root Region Server (RRS), wat die hbase:meta-tabel stoor, geleë is. Hy ontvang hierdie inligting van ZooKeeper. Waarna dit toegang verkry tot RRS en die hbase:meta-tabel lees, waaruit dit inligting onttrek oor watter RegionServer (RS) verantwoordelik is vir die stoor van data vir 'n gegewe rysleutel in die tabel van belang. Vir toekomstige gebruik word die meta-tabel deur die kliënt gekas en daarom gaan daaropvolgende oproepe vinniger, direk na RS.
Vervolgens skryf RS, nadat hy 'n versoek ontvang het, dit eerstens aan WriteAheadLog (WAL), wat nodig is vir herstel in die geval van 'n ongeluk. Stoor dan die data in MemStore. Dit is 'n buffer in geheue wat 'n gesorteerde stel sleutels vir 'n gegewe streek bevat. 'n Tabel kan in streke (partisies) verdeel word, wat elkeen 'n onsamehangende stel sleutels bevat. Dit laat jou toe om streke op verskillende bedieners te plaas om hoër werkverrigting te behaal. Ten spyte van die vanselfsprekendheid van hierdie stelling, sal ons egter later sien dat dit nie in alle gevalle werk nie.
Nadat 'n inskrywing in die MemStore geplaas is, word 'n antwoord aan die kliënt teruggestuur dat die inskrywing suksesvol gestoor is. In werklikheid word dit egter slegs in 'n buffer gestoor en kom eers na die skyf nadat 'n sekere tydperk verby is of wanneer dit met nuwe data gevul is.
Wanneer die "Delete"-bewerking uitgevoer word, word data nie fisies uitgevee nie. Hulle word eenvoudig as geskrap gemerk, en die vernietiging self vind plaas op die oomblik van die oproep van die groot kompakte funksie, wat in meer besonderhede in paragraaf 7 beskryf word.
Lêers in HFile-formaat word in HDFS opgehoop en van tyd tot tyd word die klein kompakte proses van stapel gestuur, wat eenvoudig klein lêers in groter lêers saamsmelt sonder om iets uit te vee. Met verloop van tyd ontaard dit in 'n probleem wat slegs verskyn wanneer data gelees word (ons kom 'n bietjie later hierop terug).
Benewens die laaiproses hierbo beskryf, is daar 'n baie meer effektiewe prosedure, wat miskien die sterkste kant van hierdie databasis is - BulkLoad. Dit lê in die feit dat ons onafhanklik hFiles vorm en dit op skyf plaas, wat ons in staat stel om perfek te skaal en baie ordentlike snelhede te bereik. Trouens, die beperking hier is nie HBase nie, maar die vermoëns van die hardeware. Hieronder is die opstartresultate op 'n groep wat bestaan uit 16 RegionServers en 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 drade), HBase weergawe 1.2.0-cdh5.14.2.
Hier kan u sien dat deur die aantal partisies (streke) in die tabel te verhoog, sowel as Spark-uitvoerders, ons 'n toename in aflaaispoed kry. Die spoed hang ook af van die opnamevolume. Groot blokke gee 'n toename in MB/sek, klein blokkies in die aantal ingevoegde rekords per tydseenheid, alles anders gelyk.
Jy kan ook begin laai in twee tafels op dieselfde tyd en kry dubbel die spoed. Hieronder kan jy sien dat die skryf van 10 KB blokke na twee tabelle gelyktydig plaasvind teen 'n spoed van ongeveer 600 MB/sek in elk (totaal 1275 MB/sek), wat saamval met die spoed van skryf na een tabel 623 MB/sek (sien nr. 11 hierbo)
Maar die tweede lopie met rekords van 50 KB wys dat die aflaaispoed effens groei, wat daarop dui dat dit die grenswaardes nader. Terselfdertyd moet jy in gedagte hou dat daar feitlik geen las op HBASE self geskep word nie, al wat daarvan vereis word, is om eers data van hbase:meta te gee, en nadat jy HFiles ingevoer het, die BlockCache-data terugstel en die MemStore buffer na skyf, as dit nie leeg is nie.
3. Lees data van HBASE
As ons aanvaar dat die kliënt reeds al die inligting van hbase:meta het (sien punt 2), dan gaan die versoek direk na die RS waar die vereiste sleutel gestoor word. Eerstens word die soektog in MemCache uitgevoer. Ongeag of daar data daar is of nie, die soektog word ook in die BlockCache-buffer uitgevoer en, indien nodig, in HFiles. As data in die lêer gevind is, word dit in BlockCache geplaas en sal vinniger teruggestuur word met die volgende versoek. Soek in HFile is relatief vinnig danksy die gebruik van die Bloom-filter, d.w.s. nadat 'n klein hoeveelheid data gelees is, bepaal dit onmiddellik of hierdie lêer die vereiste sleutel bevat en indien nie, beweeg dan aan na die volgende een.
Nadat data van hierdie drie bronne ontvang is, genereer RS 'n reaksie. Dit kan veral verskeie gevind weergawes van 'n voorwerp op een slag oordra as die kliënt weergawe versoek het.
4. Datakas
Die MemStore- en BlockCache-buffers beslaan tot 80% van die toegewese RS-geheue op die hoop (die res is gereserveer vir RS-dienstake). As die tipiese gebruiksmodus so is dat prosesse dieselfde data skryf en dadelik lees, is dit sinvol om BlockCache te verminder en MemStore te verhoog, want Wanneer die skryf van data nie in die kas kom vir lees nie, sal BlockCache minder gereeld gebruik word. Die BlockCache-buffer bestaan uit twee dele: LruBlockCache (altyd op-hoop) en BucketCache (gewoonlik off-heap of op 'n SSD). BucketCache moet gebruik word wanneer daar baie leesversoeke is en dit pas nie in LruBlockCache nie, wat lei tot aktiewe werk van Garbage Collector. Terselfdertyd moet jy nie 'n radikale verhoging in prestasie van die gebruik van die leeskas verwag nie, maar ons sal hierna terugkeer in paragraaf 8
Daar is een BlockCache vir die hele RS, en daar is een MemStore vir elke tafel (een vir elke Kolomfamilie).
As in teorie, wanneer dit geskryf word, gaan data nie in die kas in nie en inderdaad, sulke parameters CACHE_DATA_ON_WRITE vir die tabel en "Cache DATA on Write" vir RS is op vals gestel. Maar in die praktyk, as ons data na MemStore skryf, spoel dit dan na skyf (dus maak dit skoon), vee dan die resulterende lêer uit, dan sal ons die data suksesvol ontvang deur 'n kry-versoek uit te voer. Boonop, selfs al deaktiveer u BlockCache heeltemal en vul die tabel met nuwe data, stel dan die MemStore terug na skyf, vee dit uit en versoek dit van 'n ander sessie, sal hulle steeds van iewers af herwin word. HBase stoor dus nie net data nie, maar ook geheimsinnige raaisels.
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
Die "Cache DATA on Read" parameter is op vals gestel. As jy enige idees het, is welkom om dit in die kommentaar te bespreek.
5. Batch data verwerking MultiGet/MultiPut
Die verwerking van enkele versoeke (Kry/Sit/Delete) is nogal 'n duur operasie, so indien moontlik, moet jy dit kombineer in 'n Lys of Lys, wat jou toelaat om 'n aansienlike prestasie-hupstoot te kry. Dit is veral waar vir die skryfbewerking, maar by lees is daar die volgende slaggat. Die grafiek hieronder toon die tyd om 50 000 rekords van MemStore te lees. Die lesing is in een draad uitgevoer en die horisontale as wys die aantal sleutels in die versoek. Hier kan jy sien dat wanneer die verhoging van 'n duisend sleutels in een versoek, die uitvoering tyd daal, d.w.s. spoed toeneem. Met MSLAB-modus egter by verstek geaktiveer, begin na hierdie drempel 'n radikale daling in werkverrigting, en hoe groter die hoeveelheid data in die rekord, hoe langer is die bedryfstyd.
Toetse is uitgevoer op 'n virtuele masjien, 8 cores, weergawe HBase 2.0.0-cdh6.0.0-beta1.
Die MSLAB-modus is ontwerp om hoopfragmentasie te verminder, wat plaasvind as gevolg van die vermenging van nuwe en ou generasie data. As 'n oplossing, wanneer MSLAB geaktiveer is, word die data in relatief klein selle (stukke) geplaas en in stukke verwerk. As gevolg hiervan, wanneer die volume in die aangevraagde datapakket die toegekende grootte oorskry, daal prestasie skerp. Aan die ander kant is dit ook nie raadsaam om hierdie modus af te skakel nie, aangesien dit sal lei tot stilstand as gevolg van GC tydens oomblikke van intensiewe dataverwerking. 'n Goeie oplossing is om die selvolume te verhoog in die geval van aktiewe skryfwerk via sit op dieselfde tyd as lees. Dit is opmerklik dat die probleem nie voorkom as jy, na opname, die spoelopdrag uitvoer, wat die MemStore na skyf terugstel nie, of as jy laai met BulkLoad. Die tabel hieronder toon dat navrae vanaf die MemStore vir groter (en dieselfde hoeveelheid) data verlangsamings tot gevolg het. Deur egter die stukkies te vergroot, herstel ons die verwerkingstyd na normaal.
Benewens die verhoging van die stukke, help dit om die data volgens streek te verdeel, d.w.s. tafelverdeling. Dit lei daartoe dat minder versoeke na elke streek kom en as dit in 'n sel pas, bly die reaksie goed.
6. Strategie vir die verdeling van tabelle in streke (verdeling)
Aangesien HBase 'n sleutelwaardeberging is en partisionering per sleutel uitgevoer word, is dit uiters belangrik om die data eweredig oor alle streke te verdeel. As so 'n tabel byvoorbeeld in drie dele verdeel word, sal die data in drie streke verdeel word:
Dit gebeur dat dit tot 'n skerp verlangsaming lei as die data wat later gelaai word soos byvoorbeeld lang waardes lyk, waarvan die meeste met dieselfde syfer begin, byvoorbeeld:
1000001
1000002
...
1100003
Aangesien die sleutels as 'n byte-skikking gestoor word, sal hulle almal dieselfde begin en behoort aan dieselfde streek #1 wat hierdie reeks sleutels stoor. Daar is verskeie partisiestrategieë:
HexStringSplit – Verander die sleutel in 'n heksadesimale geënkodeerde string in die reeks "00000000" => "FFFFFFFF" en opvulling aan die linkerkant met nulle.
UniformSplit – Verander die sleutel in 'n grepe-skikking met heksadesimale enkodering in die reeks "00" => "FF" en opvulling aan die regterkant met nulle.
Daarbenewens kan jy enige reeks of stel sleutels vir splitsing spesifiseer en outo-verdeling instel. Een van die eenvoudigste en doeltreffendste benaderings is egter UniformSplit en die gebruik van hash-aaneenskakeling, byvoorbeeld die mees beduidende paar grepe vanaf die loop van die sleutel deur die CRC32(roeisleutel) funksie en die rysleutel self:
hash + roeisleutel
Dan sal alle data eweredig oor streke versprei word. By lees word die eerste twee grepe eenvoudig weggegooi en die oorspronklike sleutel bly. RS beheer ook die hoeveelheid data en sleutels in die streek en, indien die perke oorskry word, breek dit outomaties in dele op.
7. Fouttoleransie en data-lokaliteit
Aangesien slegs een streek vir elke stel sleutels verantwoordelik is, is die oplossing vir probleme wat verband hou met RS-ongelukke of ontmanteling om alle nodige data in HDFS te stoor. Wanneer RS val, bespeur die meester dit deur die afwesigheid van 'n hartklop op die ZooKeeper-knoop. Dan ken dit die bediende streek toe aan 'n ander RS en aangesien die hFiles in 'n verspreide lêerstelsel gestoor word, lees die nuwe eienaar dit en gaan voort om die data te bedien. Aangesien sommige van die data egter in die MemStore kan wees en nie tyd gehad het om by HFiles in te gaan nie, word WAL, wat ook in HDFS gestoor word, gebruik om die geskiedenis van bedrywighede te herstel. Nadat die veranderinge toegepas is, is RS in staat om op versoeke te reageer, maar die skuif lei daartoe dat sommige van die data en die prosesse wat hulle bedien op verskillende nodusse beland, m.a.w. ligging neem af.
Die oplossing vir die probleem is groot verdigting - hierdie prosedure skuif lêers na die nodusse wat daarvoor verantwoordelik is (waar hul streke geleë is), waardeur tydens hierdie prosedure die las op die netwerk en skywe skerp toeneem. In die toekoms word toegang tot data egter merkbaar versnel. Daarbenewens voer major_compaction saam van alle HFiles in een lêer binne 'n streek, en maak ook data skoon, afhangende van die tabelinstellings. Byvoorbeeld, jy kan die aantal weergawes van 'n voorwerp spesifiseer wat behou moet word of die leeftyd waarna die voorwerp fisies uitgevee word.
Hierdie prosedure kan 'n baie positiewe uitwerking op die werking van HBase hê. Die prent hieronder wys hoe werkverrigting verswak as gevolg van aktiewe data-opname. Hier kan jy sien hoe 40 drade na een tabel geskryf het en 40 drade gelyktydig data lees. Skryfdrade genereer meer en meer HFiles, wat deur ander drade gelees word. Gevolglik moet meer en meer data uit die geheue verwyder word en uiteindelik begin die GC werk, wat feitlik alle werk lamlê. Die bekendstelling van groot verdigting het gelei tot die skoonmaak van die gevolglike puin en herstel van produktiwiteit.
Die toets is uitgevoer op 3 DataNodes en 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 drade). HBase weergawe 1.2.0-cdh5.14.2
Dit is opmerklik dat groot verdigting op 'n "lewendige" tabel van stapel gestuur is, waarin data aktief geskryf en gelees is. Daar was 'n stelling aanlyn dat dit kan lei tot 'n verkeerde reaksie wanneer data gelees word. Om na te gaan, is 'n proses van stapel gestuur wat nuwe data gegenereer en dit na 'n tabel geskryf het. Daarna het ek dadelik gelees en gekyk of die gevolglike waarde saamval met wat neergeskryf is. Terwyl hierdie proses aan die gang was, is groot verdigting ongeveer 200 keer uitgevoer en nie 'n enkele mislukking is aangeteken nie. Miskien verskyn die probleem selde en slegs tydens hoë vrag, dus is dit veiliger om die skryf- en leesprosesse te stop soos beplan en skoonmaak uit te voer om sulke GC-onttrekkings te voorkom.
Groot verdigting beïnvloed ook nie die toestand van die MemStore nie; om dit na skyf te spoel en dit te kompakteer, moet jy flush (connection.getAdmin().flush(TableName.valueOf(tblName))) gebruik.
8. Instellings en prestasie
Soos reeds genoem, toon HBase sy grootste sukses waar dit niks hoef te doen nie, wanneer BulkLoad uitgevoer word. Dit geld egter vir die meeste stelsels en mense. Hierdie instrument is egter meer geskik vir die stoor van data in grootmaat in groot blokke, terwyl as die proses veelvuldige kompeterende lees- en skryfversoeke vereis, die Get en Put-opdragte hierbo beskryf word gebruik. Om die optimale parameters te bepaal, is bekendstellings uitgevoer met verskeie kombinasies van tabelparameters en instellings:
- 10 drade is gelyktydig 3 keer in 'n ry geloods (kom ons noem dit 'n blok drade).
- Die gebruikstyd van alle drade in 'n blok is gemiddeld en was die finale resultaat van die blok se werking.
- Alle drade het met dieselfde tabel gewerk.
- Voor elke aanvang van die draadblok is 'n groot verdigting uitgevoer.
- Elke blok het slegs een van die volgende bewerkings uitgevoer:
—Sit
— Kry
—Kry+Sit
- Elke blok het 50 000 herhalings van sy operasie uitgevoer.
- Die blokgrootte van 'n rekord is 100 grepe, 1000 grepe of 10000 grepe (willekeurig).
- Blokke is geloods met verskillende nommers versoekte sleutels (óf een sleutel óf 10).
- Die blokke is onder verskillende tafelinstellings uitgevoer. Parameters verander:
— BlockCache = aangeskakel of afgeskakel
— Blokgrootte = 65 KB of 16 KB
— Partisies = 1, 5 of 30
— MSLAB = aangeskakel of gedeaktiveer
Die blok lyk dus so:
a. MSLAB-modus is aan/af geskakel.
b. 'n Tabel is geskep waarvoor die volgende parameters gestel is: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
c. Kompressie is op GZ gestel.
d. 10 drade is gelyktydig geloods met 1/10 sit/kry/kry+sit-bewerkings in hierdie tabel met rekords van 100/1000/10000 grepe, wat 50 000 navrae in 'n ry uitvoer (ewekansige sleutels).
e. Punt d is drie keer herhaal.
f. Die werkstyd van alle drade is gemiddeld.
Alle moontlike kombinasies is getoets. Dit is voorspelbaar dat spoed sal daal namate die rekordgrootte toeneem, of dat die deaktivering van caching verlangsaming sal veroorsaak. Die doel was egter om die graad en betekenisvolheid van die invloed van elke parameter te verstaan, dus is die versamelde data in die invoer van 'n lineêre regressiefunksie ingevoer, wat dit moontlik maak om die betekenisvolheid met behulp van t-statistieke te assesseer. Hieronder is die resultate van die blokke wat Put-bewerkings uitvoer. Volledige stel kombinasies 2*2*3*2*3 = 144 opsies + 72 tk. sommige is twee keer gedoen. Daarom is daar altesaam 216 lopies:
Toetsing is uitgevoer op 'n mini-kluster bestaande uit 3 DataNodes en 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 drade). HBase weergawe 1.2.0-cdh5.14.2.
Die hoogste invoegspoed van 3.7 sekondes is verkry met MSLAB-modus afgeskakel, op 'n tafel met een partisie, met BlockCache geaktiveer, BlockSize = 16, rekords van 100 grepe, 10 stukke per pak.
Die laagste invoegspoed van 82.8 sek. is verkry met MSLAB-modus geaktiveer, op 'n tabel met een partisie, met BlockCache geaktiveer, BlockSize = 16, rekords van 10000 1 grepe, XNUMX elk.
Kom ons kyk nou na die model. Ons sien die goeie gehalte van die model gebaseer op R2, maar dit is absoluut duidelik dat ekstrapolasie hier teenaangedui is. Die werklike gedrag van die stelsel wanneer parameters verander sal nie lineêr wees nie; hierdie model is nie nodig vir voorspellings nie, maar om te verstaan wat binne die gegewe parameters gebeur het. Hier sien ons byvoorbeeld uit die Student se maatstaf dat die BlockSize- en BlockCache-parameters nie saak maak vir die Put-operasie nie (wat oor die algemeen redelik voorspelbaar is):
Maar die feit dat die verhoging van die aantal partisies tot 'n afname in werkverrigting lei, is ietwat onverwags (ons het reeds die positiewe impak gesien van die verhoging van die aantal partisies met BulkLoad), hoewel verstaanbaar. Eerstens, vir verwerking, moet jy versoeke genereer na 30 streke in plaas van een, en die volume data is nie sodanig dat dit 'n wins sal oplewer nie. Tweedens word die totale bedryfstyd bepaal deur die stadigste RS, en aangesien die aantal DataNodes minder is as die aantal RS'e, het sommige streke 'n nul-lokaliteit. Wel, kom ons kyk na die top vyf:
Kom ons evalueer nou die resultate van die uitvoering van Get-blokke:
Die aantal partisies het betekenis verloor, wat waarskynlik verklaar word deur die feit dat die data goed gekas is en die leeskas die belangrikste (statisties) parameter is. Natuurlik is die verhoging van die aantal boodskappe in 'n versoek ook baie nuttig vir prestasie. Top tellings:
Wel, ten slotte, kom ons kyk na die model van die blok wat die eerste keer get en dan geplaas het:
Alle parameters is hier betekenisvol. En die resultate van die leiers:
9. Lastoetsing
Wel, uiteindelik sal ons 'n min of meer ordentlike vrag begin, maar dit is altyd interessanter as jy iets het om mee te vergelyk. Op die webwerf van DataStax, die sleutelontwikkelaar van Cassandra, is daar NT van 'n aantal NoSQL-bergings, insluitend HBase weergawe 0.98.6-1. Laai is uitgevoer deur 40 drade, datagrootte 100 grepe, SSD-skywe. Die resultaat van die toets van die Lees-Verander-Skryf-bewerkings het die volgende resultate getoon.
Sover ek verstaan, is lees in blokke van 100 rekords uitgevoer en vir 16 HBase-nodusse het die DataStax-toets 'n prestasie van 10 duisend bewerkings per sekonde getoon.
Dit is gelukkig dat ons cluster ook 16 nodusse het, maar dit is nie baie “gelukkig” dat elkeen 64 kerns (drade) het nie, terwyl daar in die DataStax-toets net 4 is. Aan die ander kant het hulle SSD-aandrywers, terwyl ons HDD's het. of meer het die nuwe weergawe van HBase en SVE-gebruik tydens vrag feitlik nie aansienlik toegeneem nie (visueel met 5-10 persent). Kom ons probeer egter om hierdie konfigurasie te begin gebruik. Standaardtabelinstellings, lees word in die sleutelreeks van 0 tot 50 miljoen lukraak uitgevoer (dit wil sê, in wese elke keer nuut). Die tabel bevat 50 miljoen rekords, verdeel in 64 partisies. Die sleutels word gehash met crc32. Tabelinstellings is verstek, MSLAB is geaktiveer. Met die bekendstelling van 40 drade, lees elke draad 'n stel van 100 ewekansige sleutels en skryf dadelik die gegenereerde 100 grepe terug na hierdie sleutels.
Stand: 16 DataNode en 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 drade). HBase weergawe 1.2.0-cdh5.14.2.
Die gemiddelde resultaat is nader aan 40 duisend bewerkings per sekonde, wat aansienlik beter is as in die DataStax-toets. Vir eksperimentele doeleindes kan jy egter die toestande effens verander. Dit is redelik onwaarskynlik dat alle werk uitsluitlik op een tafel uitgevoer sal word, en ook slegs op unieke sleutels. Kom ons neem aan dat daar 'n sekere "warm" stel sleutels is wat die hooflading genereer. Daarom, kom ons probeer om 'n vrag met groter rekords (10 KB), ook in groepe van 100, in 4 verskillende tabelle te skep en die reeks versoekte sleutels te beperk tot 50 duisend. Die grafiek hieronder toon die bekendstelling van 40 drade, elke draad lees 'n stel van 100 sleutels en skryf dadelik lukraak 10 KB op hierdie sleutels terug.
Stand: 16 DataNode en 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 drade). HBase weergawe 1.2.0-cdh5.14.2.
Tydens die las is groot verdigting verskeie kere van stapel gestuur, soos hierbo getoon, sonder hierdie prosedure sal werkverrigting geleidelik verswak, maar bykomende las ontstaan ook tydens uitvoering. Onttrekkings word deur verskeie redes veroorsaak. Soms het die drade klaar gewerk en daar was 'n pouse terwyl hulle herbegin is, soms het derdeparty-toepassings 'n las op die groepie geskep.
Lees en dadelik skryf is een van die moeilikste werkscenario's vir HBase. As jy net klein plaasversoeke maak, byvoorbeeld 100 grepe, en dit in pakke van 10-50 duisend stukke kombineer, kan jy honderde duisende bewerkings per sekonde kry, en die situasie is soortgelyk met leesalleen-versoeke. Dit is opmerklik dat die resultate radikaal beter is as dié wat deur DataStax verkry is, veral as gevolg van versoeke in blokke van 50 duisend.
Stand: 16 DataNode en 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 drade). HBase weergawe 1.2.0-cdh5.14.2.
10. Gevolgtrekkings
Hierdie stelsel is redelik buigsaam opgestel, maar die invloed van 'n groot aantal parameters is steeds onbekend. Sommige van hulle is getoets, maar is nie by die gevolglike toetsstel ingesluit nie. Voorlopige eksperimente het byvoorbeeld onbeduidende betekenis van so 'n parameter soos DATA_BLOCK_ENCODING getoon, wat inligting kodeer deur waardes van naburige selle te gebruik, wat verstaanbaar is vir willekeurig gegenereerde data. As jy 'n groot aantal duplikaatvoorwerpe gebruik, kan die wins aansienlik wees. Oor die algemeen kan ons sê dat HBase die indruk wek van 'n redelik ernstige en weldeurdagte databasis, wat redelik produktief kan wees wanneer bedrywighede met groot blokke data uitgevoer word. Veral as dit moontlik is om die lees- en skryfprosesse betyds te skei.
As daar iets na jou mening is wat nie genoeg bekend gemaak word nie, is ek gereed om jou in meer besonderhede te vertel. Ons nooi jou uit om jou ervaring te deel of te bespreek as jy nie met iets saamstem nie.
Bron: will.com