Goeiemiddei Myn namme is Danil Lipovoy, ús team by Sbertech begon HBase te brûken as opslach foar operasjonele gegevens. Yn 'e rin fan' e stúdzje is ûnderfining sammele dy't ik systematisearje woe en beskriuwe (wy hoopje dat it nuttich sil wêze foar in protte). Alle eksperiminten hjirûnder waarden útfierd mei HBase ferzjes 1.2.0-cdh5.14.2 en 2.0.0-cdh6.0.0-beta1.
- Algemiene arsjitektuer
- It skriuwen fan gegevens nei HBASE
- Lêzen fan gegevens út HBASE
- Data caching
- Batch gegevens ferwurkjen MultiGet / MultiPut
- Strategy foar it splitsen fan tabellen yn regio's (splitsen)
- Fouttolerânsje, kompaktearring en gegevenslokaasje
- Ynstellings en prestaasjes
- Stress Testing
- befinings
1. Algemiene arsjitektuer
De reservekopy Master harket nei de hertslach fan 'e aktive op' e ZooKeeper-knooppunt en nimt, yn gefal fan ferdwining, de funksjes fan 'e master oer.
2. Skriuw gegevens oan HBASE
Litte wy earst nei it ienfâldichste gefal sjen - it skriuwen fan in kaai-wearde-objekt nei in tabel mei put(rowkey). De kliïnt moat earst útfine wêr't de Root Region Server (RRS), dy't de hbase:meta-tabel bewarret, sit. Dy ynformaasje krijt er fan ZooKeeper. Wêrnei't it tagong ta RRS en lêst de hbase: meta tabel, dêr't it extract ynformaasje oer hokker RegionServer (RS) is ferantwurdlik foar it bewarjen fan gegevens foar in opjûne rigel yn 'e tabel fan belang. Foar takomstich gebrûk wurdt de meta-tabel bewarre troch de kliïnt en dêrom geane folgjende oproppen flugger, direkt nei RS.
Dêrnei skriuwt RS, nei't er in fersyk krige, it earst nei WriteAheadLog (WAL), wat nedich is foar herstel yn gefal fan in crash. Dan bewarje de gegevens yn MemStore. Dit is in buffer yn it ûnthâld dat befettet in sortearre set fan kaaien foar in opjûne regio. In tabel kin ferdield wurde yn regio's (partysjes), dy't elk in disjoint set fan kaaien befettet. Hjirmei kinne jo regio's op ferskate servers pleatse om hegere prestaasjes te berikken. Lykwols, nettsjinsteande de fanselssprekkend fan dizze útspraak, sille wy letter sjen dat dit net yn alle gefallen wurket.
Nei it pleatsen fan in yngong yn 'e MemStore, wurdt in antwurd weromjûn oan' e kliïnt dat de yngong mei sukses bewarre is. Lykwols, yn werklikheid, it wurdt opslein allinnich yn in buffer en komt nei de skiif pas nei in bepaalde perioade fan tiid is foarby of as it is fol mei nije gegevens.
By it útfieren fan de operaasje "Wiskje" wurde gegevens net fysyk wiske. Se wurde gewoan markearre as wiske, en de ferneatiging sels fynt plak op it momint fan it oproppen fan de grutte kompakte funksje, dy't yn mear detail beskreaun wurdt yn paragraaf 7.
Bestannen yn HFile-formaat wurde sammele yn HDFS en fan tiid ta tiid wurdt it lytse kompakte proses lansearre, dat gewoan lytse bestannen fusearret yn gruttere sûnder neat te wiskjen. Yn 'e rin fan' e tiid feroaret dit yn in probleem dat allinich ferskynt by it lêzen fan gegevens (wy komme hjir wat letter op werom).
Neist it hjirboppe beskreaune ladenproses is d'r in folle effektiver proseduere, wat miskien de sterkste kant fan dizze databank is - BulkLoad. It leit yn it feit dat wy selsstannich foarmje HFiles en sette se op skiif, dat lit ús te skaaljen perfekt en berikke hiel fatsoenlike snelheden. Yn feite is de beheining hjir net HBase, mar de mooglikheden fan 'e hardware. Hjirûnder binne de opstartresultaten op in kluster besteande út 16 RegionServers en 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 triedden), HBase ferzje 1.2.0-cdh5.14.2.
Hjir kinne jo sjen dat troch it fergrutsjen fan it oantal partysjes (regio's) yn 'e tabel, lykas ek Spark-útfierders, wy in ferheging fan downloadsnelheid krije. Ek hinget de snelheid ôf fan it opnamevolume. Grutte blokken jouwe in tanimming fan MB / sek, lytse blokken yn it oantal ynfoege records per ienheid fan tiid, alle oare dingen binne gelyk.
Jo kinne ek begjinne te laden yn twa tabellen tagelyk en fa dûbele de snelheid. Hjirûnder kinne jo sjen dat it skriuwen fan 10 KB-blokken nei twa tabellen tagelyk bart mei in snelheid fan sawat 600 MB / sek yn elk (totaal 1275 MB / sek), wat oerienkomt mei de snelheid fan skriuwen nei ien tabel 623 MB / sek (sjoch nr. 11 boppe)
Mar de twadde run mei records fan 50 KB lit sjen dat de downloadsnelheid wat groeit, wat oanjout dat it de limytwearden benaderet. Tagelyk moatte jo der rekken mei hâlde dat d'r praktysk gjin lading is makke op HBASE sels, alles wat derfan nedich is is om earst gegevens fan hbase:meta te jaan, en nei it linen fan HFiles, de BlockCache-gegevens weromsette en de gegevens opslaan MemStore buffer nei skiif, as it is net leech.
3. Lêzen fan gegevens út HBASE
As wy oannimme dat de kliïnt al de ynformaasje hat fan hbase:meta (sjoch punt 2), dan giet it fersyk direkt nei de RS dêr't de fereaske kaai is opslein. Earst wurdt it sykjen útfierd yn MemCache. Nettsjinsteande oft der gegevens binne of net, it sykjen wurdt ek útfierd yn de BlockCache-buffer en, as it nedich is, yn HFiles. As gegevens waarden fûn yn it bestân, wurdt it pleatst yn BlockCache en sil rapper weromjûn wurde op it folgjende fersyk. It sykjen yn HFile is relatyf fluch troch it brûken fan it Bloom-filter, d.w.s. nei it lêzen fan in lytse hoemannichte gegevens, bepaalt it fuortendaliks oft dit bestân de fereaske kaai befettet en sa net, giet it dan troch nei de folgjende.
Nei ûntfangst fan gegevens út dizze trije boarnen, genereart RS in antwurd. Benammen kin it ferskate fûne ferzjes fan in objekt tagelyk oerdrage as de kliïnt ferzjeferzje frege.
4. Data caching
De MemStore- en BlockCache-buffers besette oant 80% fan it tawiisde op-heap RS-ûnthâld (de rest is reservearre foar RS-tsjinsttaken). As de typyske gebrûksmodus sa is dat prosessen deselde gegevens skriuwe en daliks lêze, dan makket it sin om BlockCache te ferminderjen en MemStore te ferheegjen, om't As it skriuwen fan gegevens net yn 'e cache komt foar it lêzen, sil BlockCache minder faak brûkt wurde. De BlockCache-buffer bestiet út twa dielen: LruBlockCache (altyd op-heap) en BucketCache (meastentiids off-heap of op in SSD). BucketCache moat brûkt wurde as d'r in protte lêsfersiken binne en se passe net yn LruBlockCache, wat liedt ta aktyf wurk fan Garbage Collector. Tagelyk moatte jo gjin radikale ferheging fan prestaasjes ferwachtsje fan it brûken fan de lêscache, mar wy sille hjirop weromkomme yn paragraaf 8
D'r is ien BlockCache foar de hiele RS, en d'r is ien MemStore foar elke tafel (ien foar elke Column Family).
Hoe yn teory, by it skriuwen, giet gegevens net yn 'e cache en yndie, sokke parameters CACHE_DATA_ON_WRITE foar de tafel en "Cache DATA on Write" foar RS binne ynsteld op falsk. Yn 'e praktyk, as wy gegevens lykwols skriuwe nei MemStore, spielje se dan nei skiif (dus wiskje it), wiskje dan it resultearjende bestân, dan sille wy troch in get-fersyk út te fieren de gegevens mei súkses ûntfange. Boppedat, sels as jo BlockCache folslein útskeakelje en de tabel mei nije gegevens folje, set dan de MemStore op skiif werom, wiskje se en freegje se fan in oare sesje, se sille noch earne wurde ophelle. Dat HBase bewarret net allinich gegevens, mar ek mysterieuze mystearjes.
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
De parameter "Cache DATA on Read" is ynsteld op falsk. As jo ideeën hawwe, wolkom om it te besprekken yn 'e kommentaren.
5. Batch gegevens ferwurkjen MultiGet / MultiPut
It ferwurkjen fan inkele oanfragen (Get/Put/Delete) is nochal in djoere operaasje, dus as it mooglik is, moatte jo se kombinearje yn in List of List, wêrtroch jo in signifikante prestaasjesympuls kinne krije. Dit is benammen wier foar de skriuwoperaasje, mar by it lêzen is d'r de folgjende kûle. De grafyk hjirûnder toant de tiid om 50 records te lêzen fan MemStore. De lêzing waard útfierd yn ien tried en de horizontale as toant it oantal kaaien yn it fersyk. Hjir kinne jo sjen dat by it ferheegjen nei tûzen kaaien yn ien fersyk, de útfieringstiid sakket, d.w.s. snelheid nimt ta. Lykwols, mei MSLAB modus ynskeakele standert, nei dizze drompel begjint in radikale drop yn prestaasjes, en hoe grutter de hoemannichte gegevens yn it rekord, hoe langer de wurktiid.
Tests waarden útfierd op in firtuele masine, 8 kearnen, ferzje HBase 2.0.0-cdh6.0.0-beta1.
De MSLAB-modus is ûntworpen om heapfragmentaasje te ferminderjen, dy't bart troch it mingen fan nije en âlde generaasjegegevens. As oplossing, as MSLAB ynskeakele is, wurde de gegevens yn relatyf lytse sellen (brokken) pleatst en yn brokken ferwurke. As gefolch, as it folume yn it frege gegevenspakket de tawiisde grutte grutter is, sakket de prestaasjes skerp. Oan 'e oare kant is it útskeakeljen fan dizze modus ek net oan te rieden, om't it sil liede ta haltes fanwegen GC yn mominten fan yntinsive gegevensferwurking. In goede oplossing is it fergrutsjen fan de sel folume yn it gefal fan aktyf skriuwen fia sette tagelyk mei lêzen. It is de muoite wurdich op te merken dat it probleem net foarkomt as jo, nei it opnimmen, it flush-kommando útfiere, dat de MemStore weromsette nei skiif, of as jo lade mei BulkLoad. De tabel hjirûnder lit sjen dat fragen fan 'e MemStore foar gruttere (en itselde bedrach) gegevens resultearje yn fertragingen. Troch it fergrutsjen fan de brokken meitsje wy de ferwurkingstiid lykwols werom nei normaal.
Neist it fergrutsjen fan de brokken, helpt it splitsen fan de gegevens troch regio, d.w.s. tafel splitting. Dêrtroch komme minder oanfragen nei elke regio en as se yn in sel passe, bliuwt it antwurd goed.
6. Strategy foar it splitsen fan tabellen yn regio's (splitsen)
Sûnt HBase is in kaai-wearde opslach en partitioning wurdt útfierd troch kaai, is it ekstreem wichtich om te ferdielen de gegevens lykmjittich oer alle regio. Bygelyks, it partitionearjen fan sa'n tabel yn trije dielen sil resultearje yn 'e gegevens wurde ferdield yn trije regio's:
It bart dat dit liedt ta in skerpe fertraging as de gegevens dy't letter laden lykje op, bygelyks, lange wearden, de measten begjinne mei itselde sifer, bygelyks:
1000001
1000002
...
1100003
Sûnt de kaaien wurde opslein as in byte array, se sille allegearre begjinne itselde en hearre ta deselde regio # 1 opslach fan dit berik fan kaaien. D'r binne ferskate partitioneringsstrategyen:
HexStringSplit - Feroaret de kaai yn in heksadesimale kodearre tekenrige yn it berik "00000000" => "FFFFFFFF" en opfolling oan de linkerkant mei nullen.
UniformSplit - Feroaret de kaai yn in byte-array mei heksadesimale kodearring yn it berik "00" => "FF" en opfolling oan 'e rjochter mei nullen.
Dêrneist kinne jo elk berik of set fan toetsen oantsjutte foar splitsing en automatyske splitting konfigurearje. Ien fan 'e ienfâldichste en meast effektive oanpak is lykwols UniformSplit en it gebrûk fan hash-konkatenaasje, bygelyks it meast wichtige pear bytes fan it útfieren fan de kaai troch de CRC32 (riekkey) funksje en de rigeltoets sels:
hash + rigel
Dan wurde alle gegevens lykwichtich ferdield oer regio's. By it lêzen wurde de earste twa bytes gewoanwei ferwidere en bliuwt de orizjinele kaai. RS kontrolearret ek de hoemannichte gegevens en kaaien yn 'e regio en, as de grinzen wurde oerskreden, brekt it automatysk yn dielen.
7. Feiltolerânsje en gegevenslokaasje
Om't mar ien regio ferantwurdlik is foar elke set fan kaaien, is de oplossing foar problemen ferbûn mei RS-crashes of ûntbining om alle nedige gegevens yn HDFS op te slaan. As RS falt, detektearret de master dit troch it ûntbrekken fan in hertslach op it ZooKeeper-knooppunt. Dan jout it de betsjinne regio ta oan in oare RS en om't de HFiles wurde opslein yn in ferspraat bestânsysteem, lêst de nije eigner se en bliuwt de gegevens tsjinje. Om't guon fan 'e gegevens lykwols yn' e MemStore kinne wêze en gjin tiid hawwe om yn HFiles te kommen, wurdt WAL, dy't ek yn HDFS opslein is, brûkt om de skiednis fan operaasjes te herstellen. Neidat de wizigingen binne tapast, is RS yn steat om te reagearjen op oanfragen, mar de beweging liedt ta it feit dat guon fan 'e gegevens en de prosessen dy't har tsjinje, einigje op ferskate knopen, d.w.s. lokaasje nimt ôf.
De oplossing foar it probleem is in grutte kompaktering - dizze proseduere ferpleatst bestannen nei dy knopen dy't ferantwurdlik binne foar har (wêr't har regio's lizze), wêrtroch't tidens dizze proseduere de lading op it netwurk en de skiven sterk ferheget. Yn 'e takomst wurdt tagong ta gegevens lykwols merkber fersneld. Derneist fiert major_compaction gearfoegjen fan alle HFiles yn ien triem binnen in regio, en makket ek gegevens op ôfhinklik fan de tabelynstellingen. Jo kinne bygelyks it oantal ferzjes fan in objekt opjaan dat moat wurde bewarre of it libben wêrnei't it objekt fysyk wiske wurdt.
Dizze proseduere kin in tige posityf effekt hawwe op 'e prestaasjes fan HBase. De ôfbylding hjirûnder lit sjen hoe't prestaasjes fermindere as gefolch fan aktive gegevensopname. Hjir kinne jo sjen hoe't 40 threads skreaunen nei ien tabel en 40 threads tagelyk gegevens lêze. Skriuwen fan diskusjes generearje hieltyd mear HFiles, dy't wurde lêzen troch oare diskusjes. Dêrtroch moatte hieltyd mear gegevens út it ûnthâld fuortsmiten wurde en úteinlik begjint de GC te wurkjen, wat praktysk alle wurk ferlamme. De lansearring fan grutte ferdichting late ta it opromjen fan 'e resultearjende pún en restauraasje fan produktiviteit.
De test waard útfierd op 3 DataNodes en 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 triedden). HBase ferzje 1.2.0-cdh5.14.2
It is de muoite wurdich op te merken dat grutte kompaktearring waard lansearre op in "live" tabel, dêr't gegevens aktyf waarden skreaun en lêzen. Der stie in ferklearring online dat dit liede koe ta in ferkearde reaksje by it lêzen fan gegevens. Om te kontrolearjen, waard in proses lansearre dat nije gegevens generearre en it nei in tabel skreau. Dernei haw ik daliks lêzen en kontrolearre oft de resultearjende wearde oerienkomt mei wat opskreaun is. Wylst dit proses rûn, waard grutte kompaktearring sawat 200 kear útfierd en waard net ien mislearring opnommen. Miskien ferskynt it probleem komselden en allinich by hege lading, dus it is feiliger om de skriuw- en lêsprosessen te stopjen lykas pland en skjinmeitsjen út te fieren om sokke GC-ûntlûken te foarkommen.
Ek hat grutte kompaktearring gjin ynfloed op de steat fan 'e MemStore; om it nei skiif te spoelen en te kompaktearjen, moatte jo flush brûke (connection.getAdmin().flush(TableName.valueOf(tblName))).
8. Ynstellings en prestaasjes
Lykas al neamd, lit HBase syn grutste súkses sjen wêr't it neat hoecht te dwaan, by it útfieren fan BulkLoad. Dit jildt lykwols foar de measte systemen en minsken. Dit ark is lykwols mear geskikt foar it opslaan fan gegevens yn bulk yn grutte blokken, wylst as it proses meardere konkurrearjende lês- en skriuwfersiken fereasket, wurde de hjirboppe beskreaune kommando's Get en Put brûkt. Om de optimale parameters te bepalen, waarden lansearringen útfierd mei ferskate kombinaasjes fan tabelparameters en ynstellings:
- 10 threads waarden tagelyk lansearre 3 kear op in rige (litte wy neame dit in blok fan triedden).
- De wurktiid fan alle triedden yn in blok waard gemiddeld en wie it einresultaat fan de operaasje fan it blok.
- Alle triedden wurken mei deselde tabel.
- Foar elke start fan it triedblok waard in grutte kompaktearring útfierd.
- Elk blok hat mar ien fan 'e folgjende operaasjes útfierd:
-Sette
-Krije
- Get+Put
- Elk blok hat 50 iteraasjes fan har operaasje útfierd.
- De blokgrutte fan in record is 100 bytes, 1000 bytes of 10000 bytes (willekeurich).
- Blokken waarden lansearre mei ferskate oantallen oanfrege kaaien (of ien kaai as 10).
- De blokken waarden útfierd ûnder ferskate tabel ynstellings. Parameters feroare:
- BlockCache = yn- of útskeakele
- Blokgrutte = 65 KB of 16 KB
- Partitionen = 1, 5 of 30
- MSLAB = ynskeakele of útskeakele
Dus it blok sjocht der sa út:
in. MSLAB-modus waard yn-/útskeakele.
b. Der is in tabel makke wêrfoar de folgjende parameters ynsteld binne: BlockCache = wier/gjin, BlockSize = 65/16 Kb, Partition = 1/5/30.
c. Kompresje waard ynsteld op GZ.
d. 10 threads waarden tagelyk lansearre mei 1/10 put/get/get+put operaasjes yn dizze tabel mei records fan 100/1000/10000 bytes, it útfieren fan 50 queries op in rige (willekeurige kaaien).
e. Punt d waard trije kear werhelle.
f. De wurktiid fan alle triedden waard gemiddeld.
Alle mooglike kombinaasjes waarden hifke. It is foarsisber dat de snelheid sil sakje as de rekordgrutte ferheget, of dat it útskeakeljen fan caching fertraging feroarsaakje sil. It doel wie lykwols om de mjitte en betsjutting fan 'e ynfloed fan elke parameter te begripen, sadat de sammele gegevens yn' e ynfier fan in lineêre regressionfunksje fiede, wêrtroch it mooglik is om de betsjutting te beoardieljen mei t-statistiken. Hjirûnder binne de resultaten fan 'e blokken dy't Put-operaasjes útfiere. Folsleine set fan kombinaasjes 2 * 2 * 3 * 2 * 3 = 144 opsjes + 72 tk. guon waarden twa kear dien. Dêrom binne d'r yn totaal 216 runs:
Testen waard útfierd op in mini-kluster besteande út 3 DataNodes en 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 triedden). HBase ferzje 1.2.0-cdh5.14.2.
De heechste ynfoegje snelheid fan 3.7 sekonden waard krigen mei MSLAB modus útskeakele, op in tafel mei ien partition, mei BlockCache ynskeakele, BlockSize = 16, records fan 100 bytes, 10 stikken per pak.
De leechste ynfoegje snelheid fan 82.8 sek waard krigen mei MSLAB modus ynskeakele, op in tafel mei ien partition, mei BlockCache ynskeakele, BlockSize = 16, records fan 10000 bytes, 1 elk.
Litte wy no nei it model sjen. Wy sjogge de goede kwaliteit fan it model basearre op R2, mar it is perfoarst dúdlik dat ekstrapolaasje hjir contraindicated is. It eigentlike gedrach fan it systeem as parameters feroarje sil net lineêr wêze; dit model is net nedich foar foarsizzingen, mar om te begripen wat der bard is binnen de opjûne parameters. Bygelyks, hjir sjogge wy út it kritearium fan 'e Student dat foar de Put-operaasje de parameters BlockSize en BlockCache net saak meitsje (wat oer it algemien frij foarsisber is):
Mar it feit dat it fergrutsjen fan it oantal partysjes liedt ta in fermindering fan prestaasjes is wat ûnferwachts (wy hawwe de positive ynfloed al sjoen fan it fergrutsjen fan it oantal partysjes mei BulkLoad), hoewol begryplik. As earste, foar ferwurking, moatte jo oanfragen generearje nei 30 regio's ynstee fan ien, en it folume fan gegevens is net sa dat dit in winst sil opleverje. Twads, de totale operaasje tiid wurdt bepaald troch de stadichste RS, en sûnt it oantal DataNodes is minder as it oantal RS, guon regio hawwe nul locality. No, lit ús nei de top fiif sjen:
Litte wy no de resultaten evaluearje fan it útfieren fan Get-blokken:
It oantal partysjes hat betsjutting ferlern, wat wierskynlik ferklearre wurdt troch it feit dat de gegevens goed yn 'e cache binne en de lêscache de wichtichste (statistysk) parameter is. Fansels is it fergrutsjen fan it oantal berjochten yn in fersyk ek heul nuttich foar prestaasjes. Topscores:
No, as lêste, litte wy sjen nei it model fan it blok dat earst útfierde get en dan sette:
Alle parameters binne wichtich hjir. En de resultaten fan de lieders:
9. Load testen
No, úteinlik sille wy in min of mear fatsoenlike lading lansearje, mar it is altyd ynteressanter as jo wat hawwe om mei te fergelykjen. Op 'e webside fan DataStax, de kaaiûntwikkelder fan Cassandra, is d'r NT fan in oantal NoSQL opslach, ynklusyf HBase ferzje 0.98.6-1. It laden waard útfierd troch 40 threads, gegevensgrutte 100 bytes, SSD-skiven. It resultaat fan it testen fan de Read-Modify-Write operaasjes liet de folgjende resultaten sjen.
Sa fier as ik begryp, waard lêzen útfierd yn blokken fan 100 records en foar 16 HBase-knooppunten, de DataStax-test toande in prestaasjes fan 10 tûzen operaasjes per sekonde.
It is lokkich dat ús kluster ek 16 knopen hat, mar it is net heul "lokkich" dat elk 64 kearnen (threads) hat, wylst yn 'e DataStax-test mar 4 binne. Oan 'e oare kant hawwe se SSD-skiven, wylst wy HDD's hawwe. of mear de nije ferzje fan HBase en CPU benutten by load praktysk net tanommen signifikant (visueel mei 5-10 prosint). Litte wy lykwols besykje dizze konfiguraasje te brûken. Standert tabel ynstellings, lêzen wurdt útfierd yn de kaai berik fan 0 oan 50 miljoen willekeurich (dat wol sizze, yn wêzen nij eltse kear). De tabel befettet 50 miljoen records, ferdield yn 64 partysjes. De kaaien wurde hashed mei crc32. Tabelynstellingen binne standert, MSLAB is ynskeakele. Troch 40 triedden te starten, lêst elke tried in set fan 100 willekeurige kaaien en skriuwt fuortendaliks de generearre 100 bytes werom nei dizze kaaien.
Stand: 16 DataNode en 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 triedden). HBase ferzje 1.2.0-cdh5.14.2.
It gemiddelde resultaat is tichter by 40 tûzen operaasjes per sekonde, wat signifikant better is as yn 'e DataStax-test. Foar eksperimintele doelen kinne jo de betingsten lykwols in bytsje feroarje. It is ûnwierskynlik dat alle wurk sil wurde útfierd allinnich op ien tafel, en ek allinnich op unike kaaien. Litte wy oannimme dat d'r in bepaalde "hot" set fan toetsen is dy't de haadlading genereart. Litte wy dêrom besykje in lading te meitsjen mei gruttere records (10 KB), ek yn batches fan 100, yn 4 ferskillende tabellen en beheine it berik fan frege kaaien ta 50 tûzen. in set fan 40 kaaien en fuortendaliks skriuwt willekeurich 100 KB op dizze kaaien werom.
Stand: 16 DataNode en 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 triedden). HBase ferzje 1.2.0-cdh5.14.2.
Tidens de lading waard grutte ferpakking ferskate kearen lansearre, lykas hjirboppe toand, sûnder dizze proseduere sil de prestaasjes stadichoan degradearje, lykwols, ekstra lading ûntstiet ek by de útfiering. Drawdowns wurde feroarsake troch ferskate redenen. Soms binne de diskusjes klear mei wurkjen en wie d'r in pauze wylst se opnij waarden starte, soms makken applikaasjes fan tredden in lading op it kluster.
Lêzen en fuortendaliks skriuwen is ien fan 'e lestichste wurksenario's foar HBase. As jo allinich lytse oanfragen meitsje, bygelyks 100 bytes, en se kombinearje yn pakketten fan 10-50 tûzen stikken, kinne jo hûnderttûzenen operaasjes per sekonde krije, en de situaasje is fergelykber mei allinich-lêsfersiken. It is de muoite wurdich op te merken dat de resultaten radikaal better binne as dy krigen troch DataStax, meastentiids troch oanfragen yn blokken fan 50 tûzen.
Stand: 16 DataNode en 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 triedden). HBase ferzje 1.2.0-cdh5.14.2.
10. Konklúzjes
Dit systeem is frij fleksibel ynsteld, mar de ynfloed fan in grut oantal parameters bliuwt noch ûnbekend. Guon fan harren waarden hifke, mar waarden net opnommen yn 'e resultearjende testset. Bygelyks, foarriedige eksperiminten lieten ûnbelangrike betsjutting sjen fan sa'n parameter as DATA_BLOCK_ENCODING, dy't ynformaasje kodearret mei wearden fan oanbuorjende sellen, wat begryplik is foar willekeurich generearre gegevens. As jo in grut oantal dûbele objekten brûke, kin de winst signifikant wêze. Yn it algemien kinne wy sizze dat HBase de yndruk jout fan in frij serieuze en goed trochtochte databank, dy't frij produktyf kin wêze by it útfieren fan operaasjes mei grutte blokken gegevens. Benammen as it mooglik is om de lês- en skriuwprosessen yn 'e tiid te skieden.
As d'r wat yn jo miening is dat net genôch iepenbiere is, bin ik ree om jo yn mear detail te fertellen. Wy noegje jo út om jo ûnderfining te dielen of te besprekken as jo it net mei iens binne.
Boarne: www.habr.com