Theorie en praktijk van het gebruik van HBase

Goedemiddag Mijn naam is Danil Lipovoy, ons team bij Sbertech is HBase gaan gebruiken als opslag voor operationele gegevens. Tijdens het bestuderen ervan is er ervaring opgedaan die ik wilde systematiseren en beschrijven (we hopen dat het voor velen nuttig zal zijn). Alle onderstaande experimenten zijn uitgevoerd met HBase-versies 1.2.0-cdh5.14.2 en 2.0.0-cdh6.0.0-beta1.

1. Algemene architectuur
2. Gegevens schrijven naar HBASE
3. Gegevens uit HBASE lezen
4. Gegevenscaching
5. Batchgegevensverwerking MultiGet/MultiPut
6. Strategie voor het splitsen van tabellen in regio's (splitsen)
7. Fouttolerantie, compactificatie en datalocatie
8. Instellingen en prestaties
9. Stress testen
10. Bevindingen

1. Algemene architectuur

De back-up Master luistert naar de hartslag van de actieve op het ZooKeeper-knooppunt en neemt, in geval van verdwijning, de functies van de master over.

2. Schrijf gegevens naar HBASE

Laten we eerst eens kijken naar het eenvoudigste geval: een sleutelwaardeobject naar een tabel schrijven met behulp van put(rowkey). De client moet eerst uitzoeken waar de Root Region Server (RRS), die de hbase:meta-tabel opslaat, zich bevindt. Deze informatie ontvangt hij van ZooKeeper. Waarna het toegang krijgt tot RRS en de hbase:meta-tabel leest, waaruit het informatie haalt over welke RegionServer (RS) verantwoordelijk is voor het opslaan van gegevens voor een bepaalde rijsleutel in de betreffende tabel. Voor toekomstig gebruik wordt de metatabel door de client in de cache opgeslagen, waardoor daaropvolgende oproepen sneller gaan, rechtstreeks naar RS.

Vervolgens schrijft RS, nadat het een verzoek heeft ontvangen, dit eerst naar WriteAheadLog (WAL), wat nodig is voor herstel in geval van een crash. Slaat vervolgens de gegevens op in MemStore. Dit is een buffer in het geheugen die een gesorteerde set sleutels voor een bepaalde regio bevat. Een tabel kan worden onderverdeeld in regio's (partities), die elk een onsamenhangende set sleutels bevatten. Hierdoor kunt u regio's op verschillende servers plaatsen om hogere prestaties te bereiken. Ondanks de voor de hand liggende verklaring zullen we later zien dat dit niet in alle gevallen werkt.

Na het plaatsen van een item in de MemStore wordt een reactie teruggestuurd naar de klant dat het item succesvol is opgeslagen. In werkelijkheid wordt het echter alleen in een buffer opgeslagen en komt het pas op de schijf terecht nadat een bepaalde tijd is verstreken of wanneer deze is gevuld met nieuwe gegevens.

Wanneer u de handeling “Verwijderen” uitvoert, worden de gegevens niet fysiek verwijderd. Ze worden eenvoudigweg gemarkeerd als verwijderd, en de vernietiging zelf vindt plaats op het moment dat de belangrijkste compacte functie wordt aangeroepen, die in paragraaf 7 gedetailleerder wordt beschreven.

Bestanden in het HFile-formaat worden verzameld in HDFS en van tijd tot tijd wordt het kleine compacte proces gestart, dat eenvoudigweg kleine bestanden samenvoegt tot grotere zonder iets te verwijderen. Na verloop van tijd verandert dit in een probleem dat alleen optreedt bij het lezen van gegevens (we komen hier later op terug).

Naast het hierboven beschreven laadproces is er een veel effectievere procedure, die misschien wel de sterkste kant van deze database is: BulkLoad. Het ligt in het feit dat we onafhankelijk HFiles vormen en op schijf zetten, waardoor we perfect kunnen schalen en zeer behoorlijke snelheden kunnen bereiken. In feite is de beperking hier niet HBase, maar de mogelijkheden van de hardware. Hieronder staan ​​de opstartresultaten op een cluster bestaande uit 16 RegionServers en 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads), HBase versie 1.2.0-cdh5.14.2.

Hier kunt u zien dat door het vergroten van het aantal partities (regio's) in de tabel, evenals Spark-uitvoerders, we een toename van de downloadsnelheid krijgen. Bovendien is de snelheid afhankelijk van het opnamevolume. Grote blokken geven een toename in MB/sec, kleine blokken in het aantal ingevoegde records per tijdseenheid, als alle overige zaken gelijk blijven.

U kunt ook tegelijkertijd in twee tabellen laden en de snelheid verdubbelen. Hieronder kunt u zien dat het schrijven van blokken van 10 KB naar twee tabellen tegelijk plaatsvindt met een snelheid van ongeveer 600 MB/sec in elke tabel (totaal 1275 MB/sec), wat samenvalt met de snelheid van het schrijven naar één tabel van 623 MB/sec (zie nr. 11 hierboven)

Maar uit de tweede run met records van 50 KB blijkt dat de downloadsnelheid licht groeit, wat aangeeft dat deze de grenswaarden nadert. Tegelijkertijd moet u er rekening mee houden dat er vrijwel geen belasting wordt gecreëerd op HBASE zelf. Het enige dat daarvoor nodig is, is eerst gegevens van hbase:meta opgeven en na het invoegen van HFiles de BlockCache-gegevens opnieuw instellen en de gegevens opslaan MemStore-buffer naar schijf, als deze niet leeg is.

3. Gegevens uit HBASE lezen

Als we ervan uitgaan dat de client al over alle informatie uit hbase:meta beschikt (zie punt 2), dan gaat het verzoek rechtstreeks naar de RS waar de benodigde sleutel is opgeslagen. Eerst wordt de zoekopdracht uitgevoerd in MemCache. Ongeacht of er gegevens aanwezig zijn of niet, de zoekopdracht wordt ook uitgevoerd in de BlockCache-buffer en indien nodig in HFiles. Als er gegevens in het bestand zijn gevonden, worden deze in BlockCache geplaatst en bij het volgende verzoek sneller geretourneerd. Zoeken in HFile gaat relatief snel dankzij het gebruik van het Bloom-filter, d.w.z. na het lezen van een kleine hoeveelheid gegevens bepaalt het onmiddellijk of dit bestand de vereiste sleutel bevat en zo niet, dan gaat het door naar de volgende.

Nadat RS gegevens uit deze drie bronnen heeft ontvangen, genereert zij een reactie. Het kan met name meerdere gevonden versies van een object in één keer overbrengen als de klant om versiebeheer vraagt.

4. Gegevenscaching

De MemStore- en BlockCache-buffers bezetten maximaal 80% van het toegewezen RS-geheugen op de heap (de rest is gereserveerd voor RS-servicetaken). Als de typische gebruiksmodus zodanig is dat processen dezelfde gegevens schrijven en onmiddellijk lezen, dan is het zinvol om BlockCache te verminderen en MemStore te vergroten, omdat Wanneer het schrijven van gegevens niet in de cache terechtkomt om te lezen, zal BlockCache minder vaak worden gebruikt. De BlockCache-buffer bestaat uit twee delen: LruBlockCache (altijd op de heap) en BucketCache (meestal off-heap of op een SSD). BucketCache moet worden gebruikt als er veel leesverzoeken zijn en deze niet in LruBlockCache passen, wat leidt tot actief werk van Garbage Collector. Tegelijkertijd mag je geen radicale prestatieverbetering verwachten van het gebruik van de leescache, maar we komen hier in paragraaf 8 op terug.

Er is één BlockCache voor de gehele RS, en er is één MemStore voor elke tabel (één voor elke kolomfamilie).

Als beschreven in theorie gaan gegevens bij het schrijven niet naar de cache en inderdaad zijn dergelijke parameters CACHE_DATA_ON_WRITE voor de tabel en "Cache DATA on Write" voor RS ingesteld op false. Als we in de praktijk echter gegevens naar MemStore schrijven, deze vervolgens naar de schijf spoelen (waardoor ze worden gewist) en vervolgens het resulterende bestand verwijderen, zullen we de gegevens met succes ontvangen door een get-verzoek uit te voeren. Bovendien, zelfs als u BlockCache volledig uitschakelt en de tabel met nieuwe gegevens vult, vervolgens de MemStore opnieuw op schijf zet, ze verwijdert en ze opvraagt ​​bij een andere sessie, zullen ze nog steeds ergens vandaan worden opgehaald. HBase slaat dus niet alleen gegevens op, maar ook mysterieuze mysteries.

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 ingesteld op false. Als u ideeën heeft, kunt u deze in de reacties bespreken.

5. Batchgegevensverwerking MultiGet/MultiPut

Het verwerken van afzonderlijke verzoeken (Get/Put/Delete) is een behoorlijk dure operatie, dus indien mogelijk moet u ze combineren in een lijst of lijst, waardoor u een aanzienlijke prestatieverbetering kunt krijgen. Dit geldt vooral voor de schrijfbewerking, maar bij het lezen is er de volgende valkuil. De onderstaande grafiek toont de tijd die nodig is om 50 records uit MemStore te lezen. Het lezen is in één thread uitgevoerd en de horizontale as toont het aantal sleutels in het verzoek. Hier kunt u zien dat bij het verhogen naar duizend sleutels in één verzoek de uitvoeringstijd afneemt, d.w.z. snelheid toeneemt. Als de MSLAB-modus echter standaard is ingeschakeld, begint na deze drempel een radicale prestatiedaling, en hoe groter de hoeveelheid gegevens in het record, hoe langer de gebruikstijd.

Er zijn tests uitgevoerd op een virtuele machine, 8 cores, versie HBase 2.0.0-cdh6.0.0-beta1.

De MSLAB-modus is ontworpen om heap-fragmentatie te verminderen, die optreedt als gevolg van het mixen van gegevens van de nieuwe en oude generatie. Als tijdelijke oplossing worden de gegevens, wanneer MSLAB is ingeschakeld, in relatief kleine cellen (chunks) geplaatst en in chunks verwerkt. Als gevolg hiervan nemen de prestaties sterk af wanneer het volume in het gevraagde datapakket de toegewezen grootte overschrijdt. Aan de andere kant is het uitschakelen van deze modus ook niet aan te raden, omdat dit zal leiden tot stops vanwege GC tijdens momenten van intensieve gegevensverwerking. Een goede oplossing is om bij actief schrijven via put tegelijkertijd met lezen het celvolume te vergroten. Het is vermeldenswaard dat het probleem niet optreedt als u na het opnemen de opdracht flush uitvoert, waardoor de MemStore naar schijf wordt gereset, of als u laadt met BulkLoad. Uit de onderstaande tabel blijkt dat zoekopdrachten vanuit de MemStore naar grotere (en dezelfde hoeveelheid) gegevens tot vertragingen leiden. Door de chunkgrootte te vergroten, wordt de verwerkingstijd echter weer normaal.

Naast het vergroten van de chunkgrootte helpt het splitsen van de gegevens per regio, d.w.z. tafel splitsen. Hierdoor komen er minder aanvragen per regio binnen en als ze in een cel passen, blijft de respons goed.

6. Strategie voor het opsplitsen van tabellen in regio's (splitsen)

Omdat HBase een sleutel/waarde-opslag is en de partitionering per sleutel wordt uitgevoerd, is het uiterst belangrijk om de gegevens gelijkmatig over alle regio's te verdelen. Als u een dergelijke tabel bijvoorbeeld in drie delen verdeelt, worden de gegevens in drie regio's verdeeld:

Het komt voor dat dit tot een scherpe vertraging leidt als de later geladen gegevens er bijvoorbeeld uitzien als lange waarden, waarvan de meeste met hetzelfde cijfer beginnen, bijvoorbeeld:

1000001
1000002
...
1100003

Omdat de sleutels worden opgeslagen als een byte-array, beginnen ze allemaal hetzelfde en behoren ze tot dezelfde regio #1 waarin dit bereik van sleutels wordt opgeslagen. Er zijn verschillende partitiestrategieën:

HexStringSplit – Verandert de sleutel in een hexadecimaal gecodeerde tekenreeks in het bereik "00000000" => "FFFFFFFF" en opvulling aan de linkerkant met nullen.

UniformSplit – Verandert de sleutel in een byte-array met hexadecimale codering in het bereik "00" => "FF" en opvulling aan de rechterkant met nullen.

Bovendien kunt u elk bereik of elke set sleutels voor het splitsen opgeven en automatisch splitsen configureren. Een van de eenvoudigste en meest effectieve benaderingen is echter UniformSplit en het gebruik van hash-aaneenschakeling, bijvoorbeeld het belangrijkste paar bytes van het doorlopen van de sleutel door de CRC32(rowkey)-functie en de rowkey zelf:

hekje + rijtoets

Dan worden alle gegevens gelijkmatig over de regio’s verdeeld. Bij het lezen worden de eerste twee bytes eenvoudig weggegooid en blijft de originele sleutel behouden. RS controleert ook de hoeveelheid gegevens en sleutels in de regio en verdeelt deze automatisch in delen als de limieten worden overschreden.

7. Fouttolerantie en datalocatie

Omdat slechts één regio verantwoordelijk is voor elke set sleutels, is de oplossing voor problemen die verband houden met RS-crashes of buitenbedrijfstelling het opslaan van alle benodigde gegevens in HDFS. Wanneer RS ​​valt, merkt de master dit door het ontbreken van een hartslag op het ZooKeeper-knooppunt. Vervolgens wijst het de bediende regio toe aan een andere RS en aangezien de HFiles zijn opgeslagen in een gedistribueerd bestandssysteem, leest de nieuwe eigenaar ze en gaat door met het serveren van de gegevens. Omdat sommige gegevens zich echter mogelijk in de MemStore bevinden en geen tijd hebben gehad om in HFiles te komen, wordt WAL, dat ook in HDFS is opgeslagen, gebruikt om de geschiedenis van bewerkingen te herstellen. Nadat de wijzigingen zijn toegepast, kan RS op verzoeken reageren, maar deze stap leidt ertoe dat sommige gegevens en de processen die deze bedienen op verschillende knooppunten terechtkomen, d.w.z. plaats neemt af.

De oplossing voor het probleem is grote compactie - deze procedure verplaatst bestanden naar de knooppunten die daarvoor verantwoordelijk zijn (waar hun regio's zich bevinden), waardoor tijdens deze procedure de belasting van het netwerk en de schijven sterk toeneemt. In de toekomst wordt de toegang tot gegevens echter merkbaar versneld. Bovendien voert major_compaction het samenvoegen van alle HFiles uit tot één bestand binnen een regio, en ruimt ook gegevens op, afhankelijk van de tabelinstellingen. U kunt bijvoorbeeld het aantal versies van een object opgeven dat moet worden bewaard of de levensduur waarna het object fysiek wordt verwijderd.

Deze procedure kan een zeer positief effect hebben op de werking van HBase. De onderstaande afbeelding laat zien hoe de prestaties verslechterden als gevolg van actieve gegevensregistratie. Hier kunt u zien hoe 40 threads naar één tabel schreven en 40 threads tegelijkertijd gegevens lezen. Schrijfthreads genereren steeds meer HFiles, die door andere threads worden gelezen. Als gevolg hiervan moeten steeds meer gegevens uit het geheugen worden verwijderd en uiteindelijk begint de GC te werken, wat vrijwel al het werk lamlegt. De start van een grote verdichting leidde tot het opruimen van het resulterende puin en het herstel van de productiviteit.

De test werd uitgevoerd op 3 DataNodes en 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads). HBase-versie 1.2.0-cdh5.14.2

Het is vermeldenswaard dat grote verdichting werd gelanceerd op een “live” tafel, waarin gegevens actief werden geschreven en gelezen. Online stond een verklaring dat dit tot een onjuiste reactie kon leiden bij het lezen van gegevens. Ter controle werd een proces gelanceerd dat nieuwe gegevens genereerde en naar een tabel schreef. Waarna ik meteen heb gelezen en gecontroleerd of de resulterende waarde overeenkwam met wat er was opgeschreven. Terwijl dit proces liep, werd er zo'n 200 keer een grote verdichting uitgevoerd, waarbij geen enkele fout werd geregistreerd. Misschien komt het probleem zelden voor en alleen tijdens hoge belasting, dus is het veiliger om de schrijf- en leesprocessen zoals gepland te stoppen en een opschoning uit te voeren om dergelijke GC-drawdowns te voorkomen.

Bovendien heeft grote compressie geen invloed op de status van de MemStore; om deze naar schijf leeg te maken en te comprimeren, moet u flush (connection.getAdmin().flush(TableName.valueOf(tblName))) gebruiken.

8. Instellingen en prestaties

Zoals reeds vermeld toont HBase zijn grootste succes daar waar het niets hoeft te doen bij het uitvoeren van BulkLoad. Dit geldt echter voor de meeste systemen en mensen. Deze tool is echter geschikter voor het bulksgewijs opslaan van gegevens in grote blokken, terwijl als het proces meerdere concurrerende lees- en schrijfverzoeken vereist, de hierboven beschreven Get- en Put-opdrachten worden gebruikt. Om de optimale parameters te bepalen, werden lanceringen uitgevoerd met verschillende combinaties van tabelparameters en instellingen:

• Er zijn 10 keer achter elkaar 3 threads tegelijkertijd gelanceerd (laten we dit een blok met threads noemen).
• De bedrijfstijd van alle threads in een blok werd gemiddeld en was het eindresultaat van de werking van het blok.
• Alle threads werkten met dezelfde tabel.
• Vóór elke start van het draadblok werd een grote verdichting uitgevoerd.
• Elk blok voerde slechts één van de volgende bewerkingen uit:

-Neerzetten
-Krijgen
—Krijg+Plaats

• Elk blok voerde 50 iteraties van zijn werking uit.
• De blokgrootte van een record is 100 bytes, 1000 bytes of 10000 bytes (willekeurig).
• Blokken werden gelanceerd met verschillende aantallen aangevraagde sleutels (één sleutel of 10).
• De blokken werden uitgevoerd onder verschillende tafelinstellingen. Parameters gewijzigd:

— BlockCache = in- of uitgeschakeld
— Blokgrootte = 65 KB of 16 KB
— Partities = 1, 5 of 30
— MSLAB = ingeschakeld of uitgeschakeld

Het blok ziet er dus als volgt uit:

A. MSLAB-modus is in-/uitgeschakeld.
B. Er is een tabel gemaakt waarvoor de volgende parameters zijn ingesteld: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
C. De compressie stond ingesteld op GZ.
D. Er werden tegelijkertijd 10 threads gelanceerd die 1/10 put/get/get+put-bewerkingen in deze tabel uitvoerden met records van 100/1000/10000 bytes, waarbij 50 queries achter elkaar werden uitgevoerd (willekeurige sleutels).
e. Punt d werd driemaal herhaald.
F. De bedrijfstijd van alle draden werd gemiddeld.

Alle mogelijke combinaties werden getest. Het is voorspelbaar dat de snelheid zal afnemen naarmate de recordgrootte toeneemt, of dat het uitschakelen van caching vertraging zal veroorzaken. Het doel was echter om de mate en het belang van de invloed van elke parameter te begrijpen, dus werden de verzamelde gegevens ingevoerd in de invoer van een lineaire regressiefunctie, die het mogelijk maakt om de significantie te beoordelen met behulp van t-statistieken. Hieronder staan ​​de resultaten van de blokken die Put-bewerkingen uitvoeren. Volledige set combinaties 2*2*3*2*3 = 144 opties + 72 tk. sommige werden twee keer gedaan. Er zijn dus in totaal 216 runs:

Er werd getest op een minicluster bestaande uit 3 DataNodes en 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads). HBase-versie 1.2.0-cdh5.14.2.

De hoogste invoegsnelheid van 3.7 seconden werd verkregen met de MSLAB-modus uitgeschakeld, op een tafel met één partitie, met BlockCache ingeschakeld, BlockSize = 16, records van 100 bytes, 10 stuks per pakket.
De laagste invoegsnelheid van 82.8 sec werd verkregen met de MSLAB-modus ingeschakeld, op een tafel met één partitie, met BlockCache ingeschakeld, BlockSize = 16, records van 10000 bytes, elk 1.

Laten we nu naar het model kijken. We zien de goede kwaliteit van het model gebaseerd op R2, maar het is absoluut duidelijk dat extrapolatie hier gecontra-indiceerd is. Het daadwerkelijke gedrag van het systeem wanneer parameters veranderen zal niet lineair zijn; dit model is niet nodig voor voorspellingen, maar om te begrijpen wat er binnen de gegeven parameters is gebeurd. Hier zien we bijvoorbeeld uit het Student-criterium dat de parameters BlockSize en BlockCache er niet toe doen voor de Put-bewerking (die over het algemeen vrij voorspelbaar is):

Maar het feit dat het vergroten van het aantal partities leidt tot een afname van de prestaties is enigszins onverwacht (we hebben de positieve impact van het vergroten van het aantal partities met BulkLoad al gezien), hoewel begrijpelijk. Ten eerste moet je voor de verwerking verzoeken genereren naar 30 regio's in plaats van één, en de hoeveelheid data is niet zodanig dat dit winst oplevert. Ten tweede wordt de totale bedrijfstijd bepaald door de langzaamste RS, en aangezien het aantal DataNodes kleiner is dan het aantal RS's, hebben sommige regio's een nullocatie. Laten we eens kijken naar de top vijf:

Laten we nu de resultaten van het uitvoeren van Get-blokken evalueren:

Het aantal partities heeft aan betekenis ingeboet, wat waarschijnlijk wordt verklaard door het feit dat de gegevens goed in de cache worden opgeslagen en dat de leescache de belangrijkste (statistisch gezien) parameter is. Uiteraard is het verhogen van het aantal berichten in een verzoek ook erg nuttig voor de prestaties. Topscores:

Laten we tot slot eens kijken naar het model van het blok dat eerst get en vervolgens put uitvoerde:

Alle parameters zijn hier significant. En de resultaten van de leiders:

9. Belastingtesten

Nou ja, eindelijk lanceren we een min of meer fatsoenlijke lading, maar het is altijd interessanter als je iets hebt om mee te vergelijken. Op de website van DataStax, de belangrijkste ontwikkelaar van Cassandra, staat dat wel bevindingen NT van een aantal NoSQL-opslagruimten, waaronder HBase-versie 0.98.6-1. Het laden werd uitgevoerd door 40 threads, gegevensgrootte 100 bytes, SSD-schijven. Het resultaat van het testen van de lees-wijzig-schrijf-bewerkingen liet de volgende resultaten zien.

Voor zover ik het begrijp, werd het lezen uitgevoerd in blokken van 100 records en voor 16 HBase-knooppunten toonde de DataStax-test een prestatie van 10 bewerkingen per seconde.

Het is een geluk dat ons cluster ook 16 knooppunten heeft, maar het is niet erg "gelukkig" dat elk 64 kernen (threads) heeft, terwijl er in de DataStax-test slechts 4 zijn. Aan de andere kant hebben ze SSD-schijven, terwijl wij HDD's hebben of meer de nieuwe versie van HBase en het CPU-gebruik tijdens belasting namen praktisch niet significant toe (visueel met 5-10 procent). Laten we echter proberen deze configuratie te gaan gebruiken. Standaard tabelinstellingen, het lezen wordt willekeurig uitgevoerd in het sleutelbereik van 0 tot 50 miljoen (d.w.z. in wezen elke keer nieuw). De tabel bevat 50 miljoen records, verdeeld in 64 partities. De sleutels worden gehasht met behulp van crc32. Tabelinstellingen zijn standaard, MSLAB is ingeschakeld. Door 40 threads te lanceren, leest elke thread een set van 100 willekeurige sleutels en schrijft de gegenereerde 100 bytes onmiddellijk terug naar deze sleutels.

Standaard: 16 DataNode en 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads). HBase-versie 1.2.0-cdh5.14.2.

Het gemiddelde resultaat ligt dichter bij 40 bewerkingen per seconde, wat aanzienlijk beter is dan in de DataStax-test. Voor experimentele doeleinden kunt u de voorwaarden echter enigszins wijzigen. Het is vrij onwaarschijnlijk dat al het werk uitsluitend op één tafel zal worden uitgevoerd, en ook alleen op unieke sleutels. Laten we aannemen dat er een bepaalde “hot” set sleutels is die de hoofdbelasting genereert. Laten we daarom proberen een belasting te creëren met grotere records (10 KB), ook in batches van 100, in 4 verschillende tabellen en het bereik van de gevraagde sleutels te beperken tot 50 duizend. De onderstaande grafiek toont de lancering van 40 threads, elke thread leest een set van 100 sleutels en schrijft direct willekeurig 10 KB op deze sleutels terug.

Standaard: 16 DataNode en 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads). HBase-versie 1.2.0-cdh5.14.2.

Tijdens de belasting werd verschillende keren een grote verdichting uitgevoerd, zoals hierboven weergegeven. Zonder deze procedure zullen de prestaties geleidelijk afnemen, maar er ontstaat ook extra belasting tijdens de uitvoering. Drawdowns worden veroorzaakt door verschillende redenen. Soms werkten de threads niet meer en was er een pauze terwijl ze opnieuw werden opgestart, soms zorgden applicaties van derden voor een belasting van het cluster.

Lezen en meteen schrijven is een van de moeilijkste werkscenario’s voor HBase. Als u alleen kleine put-verzoeken doet, bijvoorbeeld 100 bytes, en deze combineert in pakketten van 10-50 stuks, kunt u honderdduizenden bewerkingen per seconde uitvoeren, en de situatie is vergelijkbaar met alleen-lezen-verzoeken. Het is vermeldenswaard dat de resultaten radicaal beter zijn dan die verkregen door DataStax, vooral vanwege verzoeken in blokken van 50 duizend.

Standaard: 16 DataNode en 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads). HBase-versie 1.2.0-cdh5.14.2.

10. Conclusies

Dit systeem is behoorlijk flexibel geconfigureerd, maar de invloed van een groot aantal parameters is nog onbekend. Sommigen van hen werden getest, maar waren niet opgenomen in de resulterende testset. Voorlopige experimenten toonden bijvoorbeeld een onbeduidende betekenis aan van een parameter als DATA_BLOCK_ENCODING, die informatie codeert met behulp van waarden uit aangrenzende cellen, wat begrijpelijk is voor willekeurig gegenereerde gegevens. Als u een groot aantal dubbele objecten gebruikt, kan de winst aanzienlijk zijn. Over het algemeen kunnen we zeggen dat HBase de indruk wekt van een redelijk serieuze en goed doordachte database, die behoorlijk productief kan zijn bij het uitvoeren van bewerkingen met grote gegevensblokken. Vooral als het mogelijk is om de lees- en schrijfprocessen in de tijd te scheiden.

Als er iets naar uw mening niet voldoende bekend is gemaakt, ben ik bereid u dit in meer detail te vertellen. Wij nodigen u uit om uw ervaringen te delen of te bespreken als u het ergens niet mee eens bent.

Bron: www.habr.com