Theorie a Praxis fir HBase ze benotzen

Gudde Mëtteg Mäin Numm ass Danil Lipovoy, eis Team bei Sbertech huet ugefaang HBase als Späichere fir operationell Daten ze benotzen. Am Laf vun der Etude huet d'Erfahrung gesammelt, déi ech wollt systematiséieren an beschreiwen (mir hoffen, datt et fir vill nëtzlech ass). All Experimenter hei drënner goufen mat HBase Versiounen 1.2.0-cdh5.14.2 an 2.0.0-cdh6.0.0-beta1 gesuergt.

1. Allgemeng Architektur
2. Schreiwen Donnéeën ze HBASE
3. Liesen Daten aus HBASE
4. Daten Caching
5. Batchdatenveraarbechtung MultiGet/MultiPut
6. Strategie fir Dëscher a Regiounen opzedeelen (Spaltung)
7. Feeler Toleranz, Verdichtung an Datelokalitéit
8. Astellungen an Leeschtung
9. Stress Test
10. Conclusiounen

1. Allgemeng Architektur

De Backup Master lauschtert op den Häerzschlag vum aktiven um ZooKeeper Node an iwwerhëlt, am Fall vu Verschwannen, d'Funktioune vum Master.

2. Schreiwen Donnéeën ze HBASE

Als éischt, loosst eis den einfachsten Fall kucken - e Schlësselwäertobjet op en Dësch schreiwen mat put(rowkey). De Client muss fir d'éischt erausfannen, wou de Root Region Server (RRS), deen den hbase:meta-Tabelle späichert, läit. Hien kritt dës Informatioun vum ZooKeeper. Duerno kënnt et op RRS an liest d'hbase:meta-Tabelle, aus deem et Informatioun extrahéiert iwwer wéi eng RegionServer (RS) verantwortlech ass fir Daten fir e bestëmmten Zeilkey an der Tabell vun Interesse ze späicheren. Fir zukünfteg Benotzung gëtt d'Meta-Tabelle vum Client cachéiert an dofir gi spéider Uruff méi séier, direkt op RS.

Als nächst, RS, nodeems se eng Ufro kritt hunn, schreift et als éischt op WriteAheadLog (WAL), wat néideg ass fir d'Erhuelung am Fall vun engem Crash. Da späichert d'Donnéeën op MemStore. Dëst ass e Puffer am Gedächtnis deen e zortéierte Set vu Schlësselen fir eng bestëmmte Regioun enthält. En Dësch kann a Regiounen (Partitionen) opgedeelt ginn, déi all eng disjoint Set vu Schlësselen enthält. Dëst erlaabt Iech Regiounen op verschiddene Serveren ze placéieren fir méi héich Leeschtung ze erreechen. Wéi och ëmmer, trotz der Offenheet vun dëser Ausso, wäerte mir spéider gesinn datt dëst net an alle Fäll funktionnéiert.

Nodeems Dir en Entrée an de MemStore gesat huet, gëtt eng Äntwert un de Client zréckginn datt d'Entrée erfollegräich gespäichert gouf. Wéi och ëmmer, a Wierklechkeet gëtt et nëmmen an engem Puffer gespäichert a kënnt op d'Disk nëmmen nodeems eng gewëssen Zäit eriwwer ass oder wann se mat neien Donnéeën gefëllt ass.

Wann Dir d'Operatioun "läschen" ausféiert, ginn d'Donnéeën net kierperlech geläscht. Si ginn einfach als geläscht markéiert, an d'Zerstéierung selwer geschitt am Moment vum Opruff vun der grousser kompakter Funktioun, déi am Paragraf 7 méi detailléiert beschriwwe gëtt.

Dateien am HFile Format ginn an HDFS gesammelt a vun Zäit zu Zäit gëtt de klenge kompakte Prozess lancéiert, deen einfach kleng Dateien a méi grouss fusionéiert ouni eppes ze läschen. Mat der Zäit gëtt dat zu engem Problem, deen nëmme beim Liesen vun Donnéeën erschéngt (mir kommen e bësse méi spéit drop zréck).

Zousätzlech zu der Luede Prozess uewen beschriwwen, gëtt et eng vill méi efficace Prozedur, déi vläicht déi stäerkste Säit vun dëser Datebank ass - BulkLoad. Et läit an der Tatsaach, datt mir onofhängeg HFiles bilden an se op Disk setzen, wat eis erlaabt perfekt ze skaléieren a ganz uerdentlech Geschwindegkeeten z'erreechen. Tatsächlech ass d'Begrenzung hei net HBase, awer d'Fäegkeeten vun der Hardware. Drënner sinn d'Boot Resultater op engem Cluster besteet aus 16 RegionServers an 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 thread), HBase Versioun 1.2.0-cdh5.14.2.

Hei kënnt Dir gesinn datt duerch d'Erhéijung vun der Zuel vun de Partitionen (Regiounen) an der Tabell, souwéi Spark Exekutoren, mir eng Erhéijung vun der Downloadgeschwindegkeet kréien. Och hänkt d'Geschwindegkeet vum Opnamvolumen of. Grouss Blocks ginn eng Erhéijung vun MB / sec, kleng Blocken an der Unzuel vun agebaute Rekorder pro Zäitunitéit, all aner Saache sinn gläich.

Dir kënnt och an zwee Dëscher gläichzäiteg lued ufänken an duebel Vitesse kréien. Hei ënnen gesitt Dir datt d'Schreiwen vun 10 KB Blocken op zwou Dëscher gläichzäiteg mat enger Geschwindegkeet vun ongeféier 600 MB / sec an all geschitt (total 1275 MB / sec), wat gläichzäiteg mat der Schreifgeschwindegkeet op een Dësch 623 MB / sec (kuckt) Nummer 11 uewen)

Awer déi zweet Laf mat Opzeechnungen vun 50 KB weist datt d'Downloadgeschwindegkeet liicht wiisst, wat beweist datt et un d'Limitwäerter kënnt. Zur selwechter Zäit musst Dir am Kapp behalen datt et praktesch keng Belaaschtung op HBASE selwer erstallt gëtt, alles wat erfuerderlech ass fir d'éischt Daten aus hbase:meta ze ginn, an nodeems Dir HFiles ausgefouert hutt, d'BlockCache Daten zrécksetzen a späicheren MemStore Puffer op Disk, wann et net eidel ass.

3. Liesen Daten aus HBASE

Wa mir dovun ausgoen, datt de Client schonn all d'Informatiounen aus hbase:meta huet (kuckt Punkt 2), da geet d'Demande direkt un d'RS wou de néideg Schlëssel gespäichert ass. Als éischt gëtt d'Sich am MemCache gemaach. Egal ob et Daten do ass oder net, d'Sich gëtt och am BlockCache Puffer duerchgefouert an, wann néideg, an HFiles. Wann Daten an der Datei fonnt goufen, gëtt se an BlockCache plazéiert a ginn op der nächster Ufro méi séier zréck. Sichen an HFile ass relativ séier dank der Notzung vum Bloom Filter, d.h. eng kleng Quantitéit un Daten gelies huet, bestëmmt direkt ob dës Datei den erfuerderleche Schlëssel enthält a wann net, geet et dann op deen nächsten.

Nodeems Dir Daten aus dësen dräi Quellen kritt hutt, generéiert RS eng Äntwert. Besonnesch kann et e puer fonnt Versioune vun engem Objet gläichzäiteg transferéieren wann de Client d'Versionéierung gefrot huet.

4. Data Caching

D'MemStore a BlockCache Puffer besetzen bis zu 80% vum zougewisenen On-Heap RS Memory (de Rescht ass reservéiert fir RS Service Aufgaben). Wann den typesche Benotzungsmodus esou ass datt d'Prozesser déiselwecht Donnéeën schreiwen an direkt liesen, da mécht et Sënn fir BlockCache ze reduzéieren an MemStore ze erhéijen, well Wann Schreiwen Daten net an de Cache kommen fir ze liesen, BlockCache gëtt manner dacks benotzt. De BlockCache Puffer besteet aus zwee Deeler: LruBlockCache (ëmmer on-Heap) an BucketCache (normalerweis Off-Heap oder op enger SSD). BucketCache soll benotzt ginn wann et vill Lieserfuerderunge sinn a se passen net an LruBlockCache, wat zu enger aktiver Aarbecht vum Garbage Collector féiert. Zur selwechter Zäit sollt Dir net eng radikal Erhéijung vun der Leeschtung erwaarden andeems Dir de Liescache benotzt, awer mir kommen op dëst am Paragraph 8 zréck.

Et gëtt ee BlockCache fir de ganze RS, an et gëtt ee MemStore fir all Dësch (ee fir all Column Family).

wéi beschriwwen an der Theorie, wann Dir schreift, ginn d'Donnéeën net an de Cache an tatsächlech sinn esou Parameteren CACHE_DATA_ON_WRITE fir den Dësch an "Cache DATA op Schreiwen" fir RS op falsch gesat. Wéi och ëmmer, an der Praxis, wa mir Donnéeën op MemStore schreiwen, spülen se dann op d'Disk (also läscht se), läscht dann déi resultéierend Datei, da kréie mir d'Daten erfollegräich andeems Dir eng Ufro ausféiert. Ausserdeem, och wann Dir BlockCache komplett deaktivéiert an den Dësch mat neien Donnéeën fëllt, da setzt de MemStore op Disk zréck, läscht se an freet se vun enger anerer Sessioun, se ginn ëmmer nach iergendwou zréckgezunn. Also HBase späichert net nëmmen Daten, awer och mysteriéis Mystère.

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" ass op falsch gesat. Wann Dir Iddien hutt, wëllkomm et an de Kommentaren ze diskutéieren.

5. Batch Daten Veraarbechtung MultiGet / MultiPut

D'Veraarbechtung vun eenzel Ufroe (Get/Put/Delete) ass eng zimlech deier Operatioun, also wa méiglech, sollt Dir se an eng Lëscht oder Lëscht kombinéieren, wat Iech erlaabt e wesentleche Leeschtungsboost ze kréien. Dëst ass besonnesch wouer fir d'Schreifoperatioun, awer beim Liesen gëtt et de folgende Fall. D'Grafik hei ënnen weist d'Zäit fir 50 records aus MemStore ze liesen. D'Liesung gouf an engem Fuedem gemaach an déi horizontal Achs weist d'Zuel vun de Schlësselen an der Ufro. Hei kënnt Dir gesinn datt wann Dir op eng Tausend Schlësselen an enger Ufro eropgeet, d'Ausféierungszäit fällt, d.h. Vitesse vergréissert. Wéi och ëmmer, mam MSLAB Modus als Standard aktivéiert, fänkt no dësem Schwell e radikale Réckgang vun der Leeschtung un, an wat méi grouss ass d'Quantitéit vun Daten am Rekord, wat méi laang d'Betribszäit ass.

Tester goufen op enger virtueller Maschinn gemaach, 8 Kären, Versioun HBase 2.0.0-cdh6.0.0-beta1.

De MSLAB Modus ass entwéckelt fir Heap Fragmentatioun ze reduzéieren, wat geschitt wéinst der Mëschung vun neien an alen Generatiounsdaten. Als Léisung, wann MSLAB aktivéiert ass, ginn d'Donnéeën a relativ kleng Zellen (Stécker) plazéiert an a Stécker veraarbecht. Als Resultat, wann de Volume am ugefrote Datepaket déi zougewisen Gréisst iwwerschreift, fällt d'Performance staark erof. Op der anerer Säit ass et och net unzeroden dëse Modus auszeschalten, well et zu Stoppë féiert wéinst GC wärend Momenter vun intensiver Dateveraarbechtung. Eng gutt Léisung ass d'Zellvolumen ze erhéijen am Fall vun aktive Schreiwen iwwer Put zur selwechter Zäit wéi d'Liesen. Et ass derwäert ze notéieren datt de Problem net geschitt wann Dir no der Opnam de Spullkommando leeft, deen de MemStore op Disk zrécksetzt, oder wann Dir mat BulkLoad lued. D'Tabell hei drënner weist datt Ufroe vum MemStore fir méi grouss (a selwecht Betrag) Daten zu Verlängerungen resultéieren. Wéi och ëmmer, andeems d'Stécker eropgeet, gi mir d'Veraarbechtungszäit op normal zréck.

Zousätzlech fir d'Stécker ze vergréisseren, hëlleft d'Daten opzedeelen no Regioun, d.h. Dësch opzedeelen. Dëst resultéiert datt manner Ufroen an all Regioun kommen a wa se an eng Zell passen, bleift d'Äntwert gutt.

6. Strategie fir Dëscher a Regiounen opzedeelen (Spaltung)

Zënter HBase ass e Schlësselwäertlagerung an d'Partitionéierung gëtt duerch Schlëssel duerchgefouert, ass et extrem wichteg d'Donnéeën gläichméisseg iwwer all Regiounen ze deelen. Zum Beispill, d'Partitionéierung vun esou engem Dësch an dräi Deeler féiert dozou datt d'Donnéeën an dräi Regiounen opgedeelt ginn:

Et geschitt datt dëst zu enger schaarfer Verlängerung féiert, wann d'Donnéeën, déi spéider gelueden sinn, ausgesinn wéi zum Beispill laang Wäerter, déi meescht vun hinnen mat der selwechter Ziffer ufänken, zum Beispill:

1000001
1000002
...
1100003

Zënter datt d'Schlësselen als Byte-Array gespäichert sinn, fänken se all d'selwecht un a gehéieren zu der selwechter Regioun #1 déi dës Gamme vu Schlësselen späichert. Et gi verschidde Partitionsstrategien:

HexStringSplit - Verwandelt de Schlëssel an eng hexadezimal kodéiert String am Beräich "00000000" => "FFFFFFFF" a Polsterung op der lénker Säit mat Nullen.

UniformSplit - Verwandelt de Schlëssel an eng Byte-Array mat hexadezimaler Kodéierung am Beräich "00" => "FF" a Polsterung op der rietser Säit mat Nullen.

Zousätzlech kënnt Dir all Gamme oder Set vu Schlësselen fir Spaltung spezifizéieren an automatesch Spaltung konfiguréieren. Wéi och ëmmer, eng vun den einfachsten an effektivsten Approche ass UniformSplit an d'Benotzung vun Hashkoncatenatioun, zum Beispill dat bedeitendst Pair vu Bytes vum Schlëssel duerch d'CRC32(rowkey) Funktioun an de Rowkey selwer:

hash + rowkey

Da ginn all Daten gläichméisseg iwwer Regiounen verdeelt. Beim Liesen ginn déi éischt zwee Bytes einfach verworf an den urspréngleche Schlëssel bleift. RS kontrolléiert och d'Quantitéit vun Daten a Schlësselen an der Regioun an, wann d'Limiten iwwerschratt sinn, brécht se automatesch an Deeler.

7. Feeler Toleranz an daten Uertschaft

Well nëmmen eng Regioun fir all Set vu Schlësselen verantwortlech ass, ass d'Léisung fir Probleemer verbonne mat RS Crashen oder Decommissioning all néideg Donnéeën an HDFS ze späicheren. Wann RS fällt, erkennt de Meeschter dëst duerch d'Feele vun engem Häerzschlag um ZooKeeper Node. Da gëtt et déi servéiert Regioun op eng aner RS ​​​​an, well d'HFiles an engem verdeelte Dateiesystem gespäichert sinn, liest den neie Besëtzer se a servéiert weider d'Donnéeën. Wéi och ëmmer, well e puer vun den Donnéeën am MemStore sinn a keng Zäit haten fir an HFiles ze kommen, gëtt WAL, déi och an HDFS gespäichert ass, benotzt fir d'Geschicht vun den Operatiounen ze restauréieren. Nodeems d'Ännerunge applizéiert ginn, ass RS fäeg op Ufroen z'äntwerten, awer d'Beweegung féiert zu der Tatsaach datt e puer vun den Donnéeën an de Prozesser, déi se servéieren, op verschidden Noden ophalen, d.h. Uertschaft geet erof.

D'Léisung fir de Problem ass eng grouss Verdichtung - dës Prozedur bewegt Dateien op déi Wirbelen déi fir si verantwortlech sinn (wou hir Regiounen lokaliséiert sinn), als Resultat vun deem während dëser Prozedur d'Laascht op d'Netzwierk an d'Disken staark eropgeet. Wéi och ëmmer, an Zukunft gëtt den Zougang zu Daten merkbar beschleunegt. Zousätzlech mécht major_compaction d'Fusioun vun all HFiles an eng Datei bannent enger Regioun, a botzt och Daten ofhängeg vun den Dëschastellungen. Zum Beispill kënnt Dir d'Zuel vun de Versioune vun engem Objet uginn, dee muss behale ginn oder d'Liewensdauer no där den Objet kierperlech geläscht gëtt.

Dës Prozedur kann e ganz positiven Effekt op d'Operatioun vun HBase hunn. D'Bild hei drënner weist wéi d'Performance ofgebaut gouf als Resultat vun der aktiver Datenopnam. Hei kënnt Dir gesinn wéi 40 Threads an eng Tabell geschriwwen hunn an 40 Threads gläichzäiteg Daten liesen. Schreiwen Threads generéieren ëmmer méi HFiles, déi vun anere Threads gelies ginn. Als Resultat musse méi a méi Daten aus der Erënnerung geläscht ginn a schliisslech fänkt de GC un ze schaffen, wat praktesch all Aarbecht paralyséiert. D'Start vun der grousser Verdichtung huet zu der Entloossung vun de resultéierende Schutt an d'Restauratioun vun der Produktivitéit gefouert.

Den Test gouf op 3 DataNodes a 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 Threads) gemaach. HBase Versioun 1.2.0-cdh5.14.2

Et ass derwäert ze bemierken datt grouss Verdichtung op engem "Live" Dësch lancéiert gouf, an deem d'Donnéeën aktiv geschriwwe a gelies goufen. Et gouf eng Ausso online datt dëst zu enger falscher Äntwert beim Liesen vun Donnéeën kéint féieren. Fir z'iwwerpréiwen, gouf e Prozess gestart, deen nei Donnéeën generéiert an op en Dësch geschriwwen huet. Duerno hunn ech direkt gelies a gepréift, ob den entsteeten Wäert zesummegefall ass mat deem wat opgeschriwwen ass. Wärend dëse Prozess leeft, gouf grouss Verdichtung ongeféier 200 Mol gelaf an keen eenzegen Ausfall gouf opgeholl. Vläicht erschéngt de Problem selten an nëmme während der héijer Belaaschtung, sou datt et méi sécher ass d'Schreif- a Liesprozesser ze stoppen wéi geplangt an d'Botzen auszeféieren fir sou GC-Entloossungen ze vermeiden.

Och gréisser Verdichtung beaflosst net den Zoustand vum MemStore; fir se op Disk ze spülen an ze kompaktéieren, musst Dir Spull benotzen (connection.getAdmin().flush(TableName.valueOf(tblName))).

8. Astellungen an Leeschtung

Wéi schonn erwähnt, weist HBase säi gréisste Succès wou et näischt brauch ze maachen, wann Dir BulkLoad ausféiert. Wéi och ëmmer, dëst gëllt fir déi meescht Systemer a Leit. Wéi och ëmmer, dëst Tool ass méi gëeegent fir Daten a Bulk a grousse Blocken ze späicheren, wärend wann de Prozess multiple kompetitiv Lies- a Schreifufroe erfuerdert, ginn d'Kritt a Put Kommandoen uewen beschriwwen benotzt. Fir déi optimal Parameteren ze bestëmmen, goufen lancéiert mat verschiddene Kombinatioune vun Dëschparameter an Astellungen duerchgefouert:

• 10 Threads goufen gläichzäiteg 3 Mol hannereneen lancéiert (loosst eis dat e Block vun Threads nennen).
• D'Operatiounszäit vun all thread an engem Block gouf duerchschnëttlech a war d'Finale Resultat vun der Operatioun vum Block.
• All Threads hunn mam selwechten Dësch geschafft.
• Virun all Start vum Fuedemblock gouf eng grouss Verdichtung gemaach.
• All Block huet nëmmen eng vun de folgenden Operatiounen gemaach:

— Setzt
— Gett
- Get+Put

• All Block huet 50 Iteratiounen vu senger Operatioun gemaach.
• D'Blockgréisst vun engem Rekord ass 100 Bytes, 1000 Bytes oder 10000 Bytes (zoufälleg).
• Blocks goufen mat verschiddenen Zuelen vun ugefrote Schlësselen lancéiert (entweder ee Schlëssel oder 10).
• D'Blöcke goufen ënner verschiddenen Dësch Astellunge lafen. Parameter geännert:

- BlockCache = aktivéiert oder ausgeschalt
- BlockGréisst = 65 KB oder 16 KB
- Partitionen = 1, 5 oder 30
- MSLAB = aktivéiert oder behënnert

Also de Block gesäit esou aus:

a. MSLAB Modus war op / aus.
b. En Dësch gouf erstallt, fir deen déi folgend Parameter gesat goufen: BlockCache = wouer/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
c. Kompressioun gouf op GZ gesat.
d. 10 Threads goufen gläichzäiteg lancéiert fir 1/10 Put / Get / Get + Put Operatiounen an dës Tabell mat Opzeechnunge vun 100/1000/10000 Bytes ze maachen, 50 Ufroen an enger Zeil auszeféieren (zoufälleg Schlësselen).
e. Punkt d gouf dräimol widderholl.
f. D'Operatiounszäit vun all thread gouf duerchschnëttlech.

All méiglech Kombinatioune goufen getest. Et ass prévisibel datt d'Geschwindegkeet erofgeet wéi d'Rekordgréisst eropgeet, oder datt d'Caching auszeschalten verlangsamt gëtt. Allerdéngs war d'Zil de Grad an d'Bedeitung vum Afloss vun all Parameter ze verstoen, sou datt déi gesammelten Donnéeën an den Input vun enger linearer Regressiounsfunktioun gefüttert goufen, wat et méiglech mécht d'Bedeitung mat T-Statistiken ze bewäerten. Drënner sinn d'Resultater vun de Blocken déi Put-Operatiounen ausféieren. Voll Formatioun vun Kombinatioune 2 * 2 * 3 * 2 * 3 = 144 Optiounen + 72 tk. puer goufen zweemol gemaach. Dofir sinn et am Ganzen 216 Runen:

Testen gouf op engem Mini-Cluster ausgefouert, besteet aus 3 DataNodes a 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 Threads). HBase Versioun 1.2.0-cdh5.14.2.

Déi héchste Insertiounsgeschwindegkeet vun 3.7 Sekonnen gouf mam MSLAB Modus ausgeschalt, op engem Dësch mat enger Partition, mat BlockCache aktivéiert, BlockSize = 16, records vun 100 Bytes, 10 Stécker pro Pack.
Déi ënnescht Insertiounsgeschwindegkeet vun 82.8 Sekonnen gouf mam MSLAB Modus aktivéiert kritt, op engem Dësch mat enger Partition, mat BlockCache aktivéiert, BlockSize = 16, records vun 10000 Bytes, 1 all.

Loosst eis elo de Modell kucken. Mir gesinn déi gutt Qualitéit vum Modell baséiert op R2, awer et ass absolut kloer datt Extrapolatioun hei kontraindizéiert ass. Dat aktuellt Verhalen vum System wann d'Parameteren änneren wäert net linear sinn; dëse Modell ass net gebraucht fir Prognosen, mee fir ze verstoen wat an de bestëmmte Parameter geschitt ass. Zum Beispill, hei gesi mir vum Student Critère datt fir d'Put Operatioun d'BlockSize a BlockCache Parameteren egal sinn (wat allgemeng zimlech prévisibel ass):

Awer d'Tatsaach datt d'Erhéijung vun der Unzuel vun de Partitionen zu enger Ofsenkung vun der Leeschtung féiert ass e bëssen onerwaart (mir hu scho de positiven Impakt vun der Erhéijung vun der Unzuel vun de Partitionen mat BulkLoad gesinn), obwuel verständlech. Als éischt, fir d'Veraarbechtung musst Dir Ufroen op 30 Regiounen generéieren anstatt eng, an de Volume vun den Donnéeën ass net sou datt dëst e Gewënn gëtt. Zweetens gëtt d'total Operatiounszäit vum luesste RS bestëmmt, a well d'Zuel vun den DataNodes manner ass wéi d'Zuel vun den RSen, hunn e puer Regiounen null Lokalitéit. Gutt, loosst eis déi Top fënnef kucken:

Loosst eis elo d'Resultater vun der Ausféierung vu Get Blocks evaluéieren:

D'Zuel vun de Partitionen huet Bedeitung verluer, wat wahrscheinlech duerch d'Tatsaach erkläert gëtt datt d'Donnéeën gutt cache sinn an de Liescache de bedeitendsten (statistesch) Parameter ass. Natierlech ass d'Erhéijung vun der Unzuel vun de Messagen an enger Ufro och ganz nëtzlech fir d'Leeschtung. Top Scores:

Gutt, schlussendlech, loosst eis de Modell vum Block kucken, deen als éischt get an dann gesat huet:

All Parameteren sinn hei bedeitend. An d'Resultater vun de Leader:

9. Luede Testen

Gutt, endlech lancéiere mir eng méi oder manner uerdentlech Laascht, awer et ass ëmmer méi interessant wann Dir eppes hutt mat ze vergläichen. Op der Websäit vun DataStax, de Schlësselentwéckler vu Cassandra, gëtt et d'Resultater NT vun enger Zuel vun NoSQL Stockage, dorënner HBase Versioun 0.98.6-1. D'Luede gouf duerch 40 Threads duerchgefouert, Datengréisst 100 Bytes, SSD Disks. D'Resultat vum Test vun de Read-Modify-Write Operatiounen huet déi folgend Resultater gewisen.

Sou wäit wéi ech verstinn, gouf d'Liesen a Blocken vun 100 Opzeechnunge gemaach a fir 16 HBase Noden, huet den DataStax Test eng Leeschtung vun 10 Tausend Operatiounen pro Sekonn gewisen.

Et ass glécklech datt eise Cluster och 16 Noden huet, awer et ass net ganz "glécklech" datt jidderee 64 Cores (Threads) huet, während am DataStax Test nëmmen 4. Op der anerer Säit hunn se SSD Drive, wärend mir HDDs hunn oder méi déi nei Versioun vun HBase an CPU Notzung während Laascht praktesch net bedeitend eropgaang (visuell ëm 5-10 Prozent). Loosst eis awer probéieren dës Konfiguratioun ze benotzen. Standard Dësch Astellunge, liesen ass am Schlëssel Beräich vun 0 bis 50 Millioune zoufälleg ausgefouert (dh wesentlech all Kéier nei). Den Dësch enthält 50 Millioune Rekorder, opgedeelt op 64 Partitionen. D'Schlëssel gi gehat mat crc32. Dësch Astellunge sinn Standard, MSLAB ass aktivéiert. Lancéiere 40 Threads, all Thread liest e Set vun 100 zoufälleg Schlësselen a schreift direkt déi generéiert 100 Bytes zréck op dës Schlësselen.

Stand: 16 DataNode an 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 thread). HBase Versioun 1.2.0-cdh5.14.2.

D'Duerchschnëttsresultat ass méi no bei 40 Tausend Operatiounen pro Sekonn, wat wesentlech besser ass wéi am DataStax Test. Wéi och ëmmer, fir experimentell Zwecker kënnt Dir d'Konditioune liicht änneren. Et ass ganz onwahrscheinlech datt all Aarbecht exklusiv op engem Dësch duerchgefouert gëtt, an och nëmmen op eenzegaartege Schlësselen. Loosst eis unhuelen datt et e gewëssen "waarm" Set vu Schlësselen ass, déi d'Haaptlaascht generéiert. Dofir, loosst eis probéieren eng Laascht mat méi groussen Opzeechnungen (10 KB) ze kreéieren, och a Chargen vun 100, a 4 verschiddenen Dëscher a limitéieren d'Band vun ugefrote Schlësselen op 50 Tausend. eng Formatioun vun 40 Schlësselen an direkt schreift zoufälleg 100 KB op dës Schlësselen zréck.

Stand: 16 DataNode an 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 thread). HBase Versioun 1.2.0-cdh5.14.2.

Wärend der Belaaschtung gouf e puer Mol eng grouss Verdichtung lancéiert, wéi hei uewen gewisen, ouni dës Prozedur gëtt d'Leeschtung graduell ofgeschnidden, awer zousätzlech Belaaschtung entsteet och während der Ausféierung. D'Drawdowns ginn aus verschiddene Grënn verursaacht. Heiansdo hunn d'Threads fäerdeg geschafft an et gouf eng Paus wärend se nei gestart goufen, heiansdo Drëtt-Partei Uwendungen hunn eng Laascht op de Cluster erstallt.

Liesen an direkt Schreiwen ass ee vun de schwieregste Aarbechtsszenarie fir HBase. Wann Dir nëmme kleng Ufroe maacht, zum Beispill 100 Bytes, kombinéiert se a Päck vun 10-50 Tausend Stécker, kënnt Dir Honnerte vun Dausende vun Operatiounen pro Sekonn kréien, an d'Situatioun ass ähnlech mat nëmmen-liesen Ufroen. Et ass derwäert ze notéieren datt d'Resultater radikal besser sinn wéi déi vun DataStax kritt, virun allem wéinst Ufroen a Blocken vu 50 Tausend.

Stand: 16 DataNode an 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 thread). HBase Versioun 1.2.0-cdh5.14.2.

10. Conclusiounen

Dëse System ass relativ flexibel konfiguréiert, mä den Afloss vun enger grousser Zuel vu Parameteren bleift nach onbekannt. E puer vun hinnen goufen getest, awer goufen net an de resultéierende Testset abegraff. Zum Beispill, virleefeg Experimenter weisen onwichteg Bedeitung vun esou engem Parameter wéi DATA_BLOCK_ENCODING, deen Informatioun codéiert mat Wäerter aus Nopeschzellen, wat verständlech ass fir zoufälleg generéiert Donnéeën. Wann Dir eng grouss Zuel vun duplizéiert Objete benotzt, kann de Gewënn bedeitend sinn. Am Allgemengen kënne mir soen datt HBase den Androck vun enger zimlech sérieuxer a gutt iwwerluechter Datebank gëtt, déi zimmlech produktiv ka sinn wann Dir Operatiounen mat grousse Blocken vun Daten ausféiert. Besonnesch wann et méiglech ass d'Lies- a Schreifprozesser an der Zäit ze trennen.

Wann et eppes an Ärer Meenung ass, wat net genuch verroden ass, sinn ech bereet Iech méi am Detail ze soen. Mir invitéieren Iech Är Erfahrung ze deelen oder ze diskutéieren wann Dir mat eppes net averstane sidd.

Source: will.com