Dobrý deň Volám sa Danil Lipovoy, náš tím v Sbertechu začal používať HBase ako úložisko pre prevádzkové dáta. Počas jeho štúdia sa nahromadili skúsenosti, ktoré som chcel systematizovať a opísať (dúfame, že to bude pre mnohých užitočné). Všetky nižšie uvedené experimenty sa uskutočnili s HBase verziami 1.2.0-cdh5.14.2 a 2.0.0-cdh6.0.0-beta1.
- Všeobecná architektúra
- Zápis údajov do HBASE
- Čítanie údajov z HBASE
- Ukladanie údajov do vyrovnávacej pamäte
- Dávkové spracovanie dát MultiGet/MultiPut
- Stratégia rozdelenia tabuliek na regióny (rozdelenie)
- Odolnosť voči chybám, kompaktnosť a lokalizácia údajov
- Nastavenia a výkon
- Záťažové testovanie
- Závery
1. Všeobecná architektúra
Záložný Master počúva tlkot srdca aktívneho na uzle ZooKeeper a v prípade zmiznutia preberá funkcie mastera.
2. Zapíšte údaje do HBASE
Najprv sa pozrime na najjednoduchší prípad – zápis objektu kľúč – hodnota do tabuľky pomocou put(rowkey). Klient musí najprv zistiť, kde sa nachádza server Root Region Server (RRS), v ktorom je uložená tabuľka hbase:meta. Tieto informácie dostáva od ZooKeeper. Potom pristúpi k RRS a načíta tabuľku hbase:meta, z ktorej extrahuje informácie o tom, ktorý RegionServer (RS) je zodpovedný za uloženie údajov pre daný kľúč riadku v tabuľke záujmu. Pre budúce použitie je meta tabuľka uchovaná klientom, a preto nasledujúce volania idú rýchlejšie, priamo do RS.
Potom RS, keď dostane požiadavku, najprv ju zapíše do WriteAheadLog (WAL), ktorý je potrebný na obnovenie v prípade havárie. Potom údaje uloží do MemStore. Toto je vyrovnávacia pamäť v pamäti, ktorá obsahuje triedenú sadu kľúčov pre danú oblasť. Tabuľku možno rozdeliť na oblasti (partície), z ktorých každá obsahuje nesúvislú sadu kľúčov. To vám umožňuje umiestniť oblasti na rôzne servery, aby ste dosiahli vyšší výkon. Napriek samozrejmosti tohto tvrdenia však neskôr uvidíme, že to nefunguje vo všetkých prípadoch.
Po umiestnení záznamu do MemStore sa klientovi vráti odpoveď, že záznam bol úspešne uložený. V skutočnosti je však uložený len vo vyrovnávacej pamäti a na disk sa dostane až po uplynutí určitého času alebo keď sa naplní novými dátami.
Pri vykonávaní operácie „Vymazať“ sa údaje fyzicky nevymažú. Jednoducho sa označia ako vymazané a k samotnému zničeniu dôjde v momente volania hlavnej kompaktnej funkcie, ktorá je podrobnejšie popísaná v odseku 7.
Súbory vo formáte HFile sa hromadia v HDFS a z času na čas sa spustí menší kompaktný proces, ktorý jednoducho zlúči malé súbory do väčších bez toho, aby sa čokoľvek vymazalo. Časom sa to zmení na problém, ktorý sa objavuje len pri čítaní dát (k tomu sa vrátime trochu neskôr).
Okrem vyššie popísaného procesu načítania existuje oveľa efektívnejší postup, ktorý je azda najsilnejšou stránkou tejto databázy – BulkLoad. Spočíva v tom, že nezávisle tvoríme HFiles a ukladáme ich na disk, čo nám umožňuje perfektne škálovať a dosahovať veľmi slušné rýchlosti. V skutočnosti tu obmedzenie nie je HBase, ale možnosti hardvéru. Nižšie sú uvedené výsledky zavádzania na klastri pozostávajúcom zo 16 serverov RegionServer a 16 serverov NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 vlákien), verzia HBase 1.2.0-cdh5.14.2.
Tu môžete vidieť, že zvýšením počtu oddielov (regiónov) v tabuľke, ako aj spúšťačov Spark, dosiahneme zvýšenie rýchlosti sťahovania. Rýchlosť tiež závisí od hlasitosti záznamu. Veľké bloky dávajú nárast v MB/s, malé bloky v počte vložených záznamov za jednotku času, pričom všetky ostatné veci sú rovnaké.
Môžete tiež začať nakladať do dvoch stolov súčasne a dosiahnuť dvojnásobnú rýchlosť. Nižšie môžete vidieť, že zápis 10 KB blokov do dvoch tabuliek naraz prebieha rýchlosťou približne 600 MB/s v každej (celkovo 1275 MB/s), čo sa zhoduje s rýchlosťou zápisu do jednej tabuľky 623 MB/s (viď. č. 11 vyššie)
No druhý chod so záznamami 50 KB ukazuje, že rýchlosť sťahovania mierne rastie, čo naznačuje, že sa blíži k limitným hodnotám. Zároveň musíte mať na pamäti, že na samotnom HBASE sa prakticky nevytvára žiadna záťaž, všetko, čo sa od nej vyžaduje, je najprv poskytnúť údaje z hbase:meta a po naložení HFiles resetovať údaje BlockCache a uložiť Vyrovnávacia pamäť MemStore na disk, ak nie je prázdna.
3. Čítanie údajov z HBASE
Ak predpokladáme, že klient už má všetky informácie z hbase:meta (pozri bod 2), tak požiadavka smeruje priamo do RS, kde je uložený požadovaný kľúč. Najprv sa vyhľadávanie vykoná v MemCache. Bez ohľadu na to, či tam sú alebo nie sú dáta, vyhľadávanie sa vykonáva aj vo vyrovnávacej pamäti BlockCache a v prípade potreby aj v HFiles. Ak sa v súbore našli údaje, umiestnia sa do BlockCache a pri ďalšej požiadavke sa vrátia rýchlejšie. Vyhľadávanie v HFile je vďaka použitiu Bloom filtra pomerne rýchle, t.j. po prečítaní malého množstva údajov okamžite zistí, či tento súbor obsahuje požadovaný kľúč, a ak nie, prejde na ďalší.
Po prijatí údajov z týchto troch zdrojov RS vygeneruje odpoveď. Najmä môže preniesť niekoľko nájdených verzií objektu naraz, ak klient požadoval verzovanie.
4. Ukladanie údajov do vyrovnávacej pamäte
Vyrovnávacie pamäte MemStore a BlockCache zaberajú až 80 % pridelenej pamäte RS na halde (zvyšok je vyhradený pre úlohy služby RS). Ak je typický režim používania taký, že procesy zapisujú a okamžite čítajú rovnaké dáta, potom má zmysel znížiť BlockCache a zvýšiť MemStore, pretože Keď sa zápis údajov nedostane do vyrovnávacej pamäte na čítanie, BlockCache sa bude používať menej často. Vyrovnávacia pamäť BlockCache pozostáva z dvoch častí: LruBlockCache (vždy na halde) a BucketCache (zvyčajne mimo haldy alebo na SSD). BucketCache by sa mal používať, keď je veľa požiadaviek na čítanie a nezmestia sa do LruBlockCache, čo vedie k aktívnej práci Garbage Collector. Zároveň by ste nemali očakávať radikálne zvýšenie výkonu od používania čítacej vyrovnávacej pamäte, ale k tomu sa vrátime v odseku 8
Pre celú RS je jedna BlockCache a pre každú tabuľku je jeden MemStore (jeden pre každú rodinu stĺpcov).
Ako teoreticky pri zápise dáta neprechádzajú do vyrovnávacej pamäte a skutočne, parametre CACHE_DATA_ON_WRITE pre tabuľku a „Cache DATA on Write“ pre RS sú nastavené na hodnotu false. V praxi však platí, že ak zapíšeme dáta do MemStore, potom ich vyprázdnime na disk (čím ich vymažeme), následne vymažeme výsledný súbor, potom vykonaním get requestu dáta úspešne prijmeme. Navyše, aj keď úplne zakážete BlockCache a naplníte tabuľku novými údajmi, potom resetujete MemStore na disk, vymažete ich a vyžiadate si ich z inej relácie, stále sa odniekiaľ získajú. HBase teda ukladá nielen dáta, ale aj záhadné záhady.
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
Parameter "Cache DATA on Read" je nastavený na hodnotu false. Ak máte nejaké nápady, vitajte v diskusii o nich v komentároch.
5. Dávkové spracovanie dát MultiGet/MultiPut
Spracovanie jednotlivých požiadaviek (Get/Put/Delete) je pomerne nákladná operácia, takže ak je to možné, mali by ste ich spojiť do zoznamu alebo zoznamu, čo vám umožní dosiahnuť výrazné zvýšenie výkonu. To platí najmä pre operáciu zápisu, ale pri čítaní existuje nasledujúca úskalia. Nižšie uvedený graf zobrazuje čas na prečítanie 50 000 záznamov z MemStore. Čítanie prebehlo v jednom vlákne a na vodorovnej osi je znázornený počet kľúčov v požiadavke. Tu vidíte, že pri zvýšení na tisíc kľúčov v jednej požiadavke klesá čas vykonania, t.j. rýchlosť sa zvyšuje. Ak je však štandardne povolený režim MSLAB, po tomto prahu začína radikálny pokles výkonu a čím väčšie je množstvo údajov v zázname, tým dlhší je prevádzkový čas.
Testy boli realizované na virtuálnom stroji, 8 jadrách, verzia HBase 2.0.0-cdh6.0.0-beta1.
Režim MSLAB je navrhnutý tak, aby znížil fragmentáciu haldy, ku ktorej dochádza v dôsledku miešania údajov novej a starej generácie. Ako riešenie, keď je povolený MSLAB, údaje sa umiestňujú do relatívne malých buniek (kúskov) a spracúvajú sa po častiach. V dôsledku toho, keď objem v požadovanom dátovom pakete prekročí pridelenú veľkosť, výkon prudko klesne. Na druhej strane, vypínanie tohto režimu tiež nie je vhodné, pretože vo chvíľach intenzívneho spracovania dát dôjde k zastaveniu kvôli GC. Dobrým riešením je zvýšiť objem bunky v prípade aktívneho zápisu cez put súčasne s čítaním. Stojí za zmienku, že problém nenastane, ak po nahrávaní spustíte príkaz flush, ktorý resetuje MemStore na disk, alebo ak načítate pomocou BulkLoad. Tabuľka nižšie ukazuje, že dopyty z MemStore na väčšie (a rovnaké množstvo) údajov vedú k spomaleniu. Zväčšením veľkosti chunksize však vrátime čas spracovania do normálu.
Okrem zväčšenia veľkosti chunksize pomáha rozdelenie údajov podľa regiónu, t.j. rozdelenie stola. Výsledkom je, že do každej oblasti prichádza menej žiadostí a ak sa zmestia do bunky, odozva zostáva dobrá.
6. Stratégia rozdelenia tabuliek na regióny (rozdelenie)
Keďže HBase je úložisko typu kľúč – hodnota a rozdelenie sa vykonáva podľa kľúča, je mimoriadne dôležité rozdeliť údaje rovnomerne do všetkých oblastí. Napríklad rozdelenie takejto tabuľky na tri časti bude mať za následok rozdelenie údajov do troch oblastí:
Stáva sa, že to vedie k prudkému spomaleniu, ak neskôr načítané údaje vyzerajú napríklad ako dlhé hodnoty, pričom väčšina z nich začína rovnakou číslicou, napríklad:
1000001
1000002
...
1100003
Keďže kľúče sú uložené ako bajtové pole, všetky začnú rovnako a budú patriť do rovnakej oblasti #1, v ktorej je uložený tento rozsah kľúčov. Existuje niekoľko stratégií rozdelenia:
HexStringSplit – Premení kľúč na hexadecimálne zakódovaný reťazec v rozsahu "00000000" => "FFFFFFFF" a na ľavej strane je vyplnený nulami.
UniformSplit – Premení kľúč na bajtové pole s hexadecimálnym kódovaním v rozsahu "00" => "FF" a s výplňou vpravo nulami.
Okrem toho môžete určiť ľubovoľný rozsah alebo sadu kľúčov na rozdelenie a nakonfigurovať automatické rozdelenie. Jedným z najjednoduchších a najefektívnejších prístupov je však UniformSplit a použitie hash zreťazenia, napríklad najvýznamnejšieho páru bajtov zo spustenia kľúča cez funkciu CRC32(rowkey) a samotného rowkey:
hash + rowkey
Potom budú všetky údaje rozdelené rovnomerne medzi regióny. Pri čítaní sa prvé dva bajty jednoducho vyhodia a zostane pôvodný kľúč. RS kontroluje aj množstvo dát a kľúčov v regióne a v prípade prekročenia limitov ho automaticky rozbije na časti.
7. Odolnosť voči poruchám a lokalita údajov
Keďže za každú sadu kľúčov je zodpovedná iba jedna oblasť, riešením problémov spojených s pádmi alebo vyradením RS z prevádzky je uloženie všetkých potrebných údajov do HDFS. Keď RS klesne, master to zistí prostredníctvom neprítomnosti srdcového tepu na uzle ZooKeeper. Potom priradí obsluhovanú oblasť inému RS a keďže sú súbory HFiles uložené v distribuovanom súborovom systéme, nový vlastník ich prečíta a pokračuje v poskytovaní údajov. Keďže však niektoré údaje môžu byť v MemStore a nestihli sa dostať do HFiles, na obnovenie histórie operácií sa používa WAL, ktorý je uložený aj v HDFS. Po aplikovaní zmien je RS schopný reagovať na požiadavky, no tento krok vedie k tomu, že niektoré dáta a procesy, ktoré ich obsluhujú, končia na iných uzloch, t.j. lokalita sa zmenšuje.
Riešením problému je veľké zhutnenie - tento postup presúva súbory do tých uzlov, ktoré sú za ne zodpovedné (kde sa nachádzajú ich oblasti), v dôsledku čoho sa počas tohto postupu prudko zvyšuje zaťaženie siete a diskov. V budúcnosti sa však prístup k údajom výrazne zrýchli. Okrem toho major_compaction vykonáva zlúčenie všetkých HFiles do jedného súboru v rámci regiónu a tiež čistí údaje v závislosti od nastavení tabuľky. Môžete napríklad zadať počet verzií objektu, ktoré sa musia zachovať, alebo dobu životnosti, po ktorej sa objekt fyzicky odstráni.
Tento postup môže mať veľmi pozitívny vplyv na fungovanie HBase. Obrázok nižšie ukazuje, ako sa výkon znížil v dôsledku aktívneho zaznamenávania údajov. Tu môžete vidieť, ako 40 vlákien zapisovalo do jednej tabuľky a 40 vlákien súčasne čítalo dáta. Zápis vlákien generuje stále viac súborov HFiles, ktoré čítajú iné vlákna. V dôsledku toho je potrebné z pamäte odstrániť stále viac údajov a nakoniec začne fungovať GC, čo prakticky paralyzuje všetku prácu. Začatie veľkého zhutňovania viedlo k vyčisteniu výsledného odpadu a obnoveniu produktivity.
Test bol vykonaný na 3 DataNode a 4 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 vlákien). Verzia HBase 1.2.0-cdh5.14.2
Stojí za zmienku, že veľké zhutňovanie sa začalo na „živej“ tabuľke, do ktorej sa aktívne zapisovali a čítali údaje. Na internete sa objavilo vyhlásenie, že to môže viesť k nesprávnej odpovedi pri čítaní údajov. Pre kontrolu sa spustil proces, ktorý vygeneroval nové dáta a zapísal ich do tabuľky. Potom som si hneď prečítal a skontroloval, či sa výsledná hodnota zhoduje s tým, čo bolo zapísané. Kým tento proces prebiehal, veľké zhutňovanie sa spustilo asi 200-krát a nezaznamenala sa ani jedna porucha. Možno sa problém objavuje zriedkavo a iba pri vysokom zaťažení, takže je bezpečnejšie zastaviť proces zápisu a čítania podľa plánu a vykonať čistenie, aby sa predišlo takýmto výpadkom GC.
Veľké zhutnenie tiež neovplyvní stav MemStore, na jeho vyprázdnenie na disk a zhutnenie je potrebné použiť flush (connection.getAdmin().flush(meno tabuľky.valueOf(tblName))).
8. Nastavenia a výkon
Ako už bolo spomenuté, HBase vykazuje najväčší úspech tam, kde nemusí nič robiť, pri spustení BulkLoad. To však platí pre väčšinu systémov a ľudí. Tento nástroj je však vhodnejší na hromadné ukladanie dát vo veľkých blokoch, zatiaľ čo ak proces vyžaduje viacero konkurenčných požiadaviek na čítanie a zápis, použijú sa vyššie popísané príkazy Get a Put. Na určenie optimálnych parametrov boli spustenia vykonané s rôznymi kombináciami parametrov a nastavení tabuľky:
- 10 vlákien bolo spustených súčasne 3 krát za sebou (nazvime to blok vlákien).
- Prevádzkový čas všetkých vlákien v bloku bol spriemerovaný a bol konečným výsledkom činnosti bloku.
- Všetky vlákna pracovali s rovnakou tabuľkou.
- Pred každým začiatkom závitového bloku sa vykonalo veľké zhutnenie.
- Každý blok vykonal iba jednu z nasledujúcich operácií:
— Položiť
— Získajte
-Získať + dať
- Každý blok vykonal 50 000 opakovaní svojej operácie.
- Veľkosť bloku záznamu je 100 bajtov, 1000 10000 bajtov alebo XNUMX XNUMX bajtov (náhodné).
- Bloky boli spustené s rôznym počtom požadovaných kľúčov (buď jeden kľúč alebo 10).
- Bloky boli spustené pri rôznych nastaveniach tabuľky. Zmenené parametre:
— BlockCache = zapnuté alebo vypnuté
— Veľkosť bloku = 65 KB alebo 16 KB
— Priečky = 1, 5 alebo 30
— MSLAB = zapnuté alebo vypnuté
Takže blok vyzerá takto:
a. Režim MSLAB bol zapnutý/vypnutý.
b. Bola vytvorená tabuľka, pre ktorú boli nastavené tieto parametre: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
c. Kompresia bola nastavená na GZ.
d. 10 vlákien bolo spustených súčasne a vykonávalo operácie 1/10 put/get/get+put do tejto tabuľky so záznamami 100/1000/10000 bajtov, pričom sa vykonalo 50 000 dotazov v rade (náhodné kľúče).
e. Bod d sa opakoval trikrát.
f. Prevádzkový čas všetkých vlákien bol spriemerovaný.
Testovali sa všetky možné kombinácie. Dá sa predvídať, že rýchlosť bude klesať so zvyšujúcou sa veľkosťou záznamu alebo že zakázanie ukladania do vyrovnávacej pamäte spôsobí spomalenie. Cieľom však bolo pochopiť mieru a významnosť vplyvu každého parametra, preto boli zozbierané údaje vložené do vstupu lineárnej regresnej funkcie, ktorá umožňuje posúdiť významnosť pomocou t-štatistiky. Nižšie sú uvedené výsledky blokov vykonávajúcich operácie Put. Kompletná sada kombinácií 2*2*3*2*3 = 144 možností + 72 tk. niektoré sa robili dvakrát. Celkovo je teda 216 jázd:
Testovanie sa uskutočnilo na mini-klastri pozostávajúcom z 3 DataNodes a 4 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 vlákien). Verzia HBase 1.2.0-cdh5.14.2.
Najvyššia rýchlosť vkladania 3.7 sekundy bola dosiahnutá pri vypnutom režime MSLAB, na stole s jednou partíciou, s povolenou BlockCache, BlockSize = 16, záznamy 100 bajtov, 10 kusov v balení.
Najnižšia rýchlosť vkladania 82.8 s bola dosiahnutá s povoleným režimom MSLAB, na tabuľke s jedným oddielom, s povolenou BlockCache, BlockSize = 16, záznamy 10000 1 bajtov, XNUMX každý.
Teraz sa pozrime na model. Vidíme dobrú kvalitu modelu založeného na R2, ale je úplne jasné, že extrapolácia je tu kontraindikovaná. Skutočné správanie systému pri zmene parametrov nebude lineárne, tento model je potrebný nie na predpovede, ale na pochopenie toho, čo sa stalo v rámci daných parametrov. Napríklad tu vidíme z kritéria študenta, že parametre BlockSize a BlockCache nie sú dôležité pre operáciu Put (čo je vo všeobecnosti celkom predvídateľné):
Ale skutočnosť, že zvýšenie počtu partícií vedie k zníženiu výkonu, je trochu neočakávaná (pozitívny vplyv zvyšovania počtu partícií sme už videli s BulkLoad), aj keď pochopiteľná. Po prvé, na spracovanie musíte generovať požiadavky do 30 regiónov namiesto jedného a objem údajov nie je taký, aby to prinieslo zisk. Po druhé, celkový prevádzkový čas je určený najpomalším RS a keďže počet DataNodes je menší ako počet RS, niektoré regióny majú nulovú lokalitu. Nuž, pozrime sa na prvých päť:
Teraz poďme vyhodnotiť výsledky vykonávania blokov Get:
Počet partícií stratil na význame, čo sa zrejme vysvetľuje tým, že dáta sa dobre ukladajú do vyrovnávacej pamäte a cache na čítanie je najvýznamnejším (štatisticky) parametrom. Prirodzene, zvýšenie počtu správ v požiadavke je tiež veľmi užitočné pre výkon. Najlepšie skóre:
Nakoniec sa pozrime na model bloku, ktorý najprv vykonal get a potom dal:
Všetky parametre sú tu dôležité. A výsledky lídrov:
9. Záťažové testovanie
No, konečne spustíme viac-menej slušný náklad, no vždy je to zaujímavejšie, keď máte s čím porovnávať. Na webovej stránke DataStax, kľúčového vývojára Cassandry, je NT z množstva úložísk NoSQL vrátane HBase verzie 0.98.6-1. Načítavanie bolo realizované 40 vláknami, veľkosť dát 100 bajtov, SSD disky. Výsledok testovania operácií Read-Modify-Write ukázal nasledujúce výsledky.
Pokiaľ som pochopil, čítanie sa uskutočnilo v blokoch po 100 záznamoch a pre 16 uzlov HBase ukázal test DataStax výkon 10 XNUMX operácií za sekundu.
Našťastie aj náš cluster má 16 nodov, no nie je veľmi “šťastím”, že každý má 64 jadier (vlákien), pričom v teste DataStax sú len 4. Na druhej strane majú SSD disky, kým my HDD alebo viac nová verzia HBase a vyťaženie CPU počas záťaže sa prakticky výrazne nezvýšilo (vizuálne o 5-10 percent). Skúsme však začať používať túto konfiguráciu. Predvolené nastavenia tabuľky, čítanie sa vykonáva v kľúčovom rozsahu od 0 do 50 miliónov náhodne (t. j. v podstate zakaždým nové). Tabuľka obsahuje 50 miliónov záznamov rozdelených do 64 oblastí. Kľúče sú hašované pomocou crc32. Nastavenia tabuľky sú predvolené, MSLAB je povolený. Po spustení 40 vlákien každé vlákno prečíta sadu 100 náhodných kľúčov a okamžite zapíše vygenerovaných 100 bajtov späť do týchto kľúčov.
Stojan: 16 DataNode a 16 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 vlákien). Verzia HBase 1.2.0-cdh5.14.2.
Priemerný výsledok sa blíži k 40 tisícom operácií za sekundu, čo je výrazne lepšie ako v teste DataStax. Na experimentálne účely však môžete podmienky mierne zmeniť. Je dosť nepravdepodobné, že všetky práce sa budú vykonávať výlučne na jednom stole a tiež iba na jedinečných kľúčoch. Predpokladajme, že existuje určitá „horúca“ sada kľúčov, ktorá generuje hlavnú záťaž. Skúsme preto vytvoriť záťaž s väčšími záznamami (10 KB), aj v dávkach po 100, v 4 rôznych tabuľkách a s obmedzením rozsahu požadovaných kľúčov na 50 tis.. Graf nižšie ukazuje spustenie 40 vlákien, každé vlákno číta sadu 100 kľúčov a okamžite na tieto kľúče zapíše náhodne 10 KB späť.
Stojan: 16 DataNode a 16 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 vlákien). Verzia HBase 1.2.0-cdh5.14.2.
Počas zaťaženia bolo niekoľkokrát spustené veľké zhutňovanie, ako je uvedené vyššie, bez tohto postupu bude výkon postupne degradovať, avšak pri vykonávaní vzniká aj dodatočné zaťaženie. Čerpanie je spôsobené rôznymi dôvodmi. Niekedy vlákna skončili s prácou a pri ich reštartovaní nastala pauza, niekedy aplikácie tretích strán spôsobili zaťaženie klastra.
Čítanie a okamžité písanie je pre HBase jedným z najťažších pracovných scenárov. Ak robíte len malé put requesty, napríklad 100 bajtov, skombinujete ich do balíkov po 10-50 tisíc kusov, môžete získať státisíce operácií za sekundu a podobná situácia je aj s požiadavkami len na čítanie. Stojí za zmienku, že výsledky sú radikálne lepšie ako výsledky získané spoločnosťou DataStax, najmä kvôli požiadavkám v blokoch 50 tis.
Stojan: 16 DataNode a 16 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 vlákien). Verzia HBase 1.2.0-cdh5.14.2.
10. Závery
Tento systém je pomerne flexibilne nakonfigurovaný, no vplyv veľkého množstva parametrov zostáva stále neznámy. Niektoré z nich boli testované, ale neboli zahrnuté do výsledného testovacieho súboru. Napríklad predbežné experimenty ukázali nevýznamný význam takého parametra ako DATA_BLOCK_ENCODING, ktorý kóduje informácie pomocou hodnôt zo susedných buniek, čo je pochopiteľné pre náhodne generované údaje. Ak použijete veľké množstvo duplicitných objektov, zisk môže byť značný. Vo všeobecnosti môžeme povedať, že HBase pôsobí dojmom pomerne serióznej a premyslenej databázy, ktorá môže byť pomerne produktívna pri operáciách s veľkými blokmi údajov. Najmä ak je možné časovo oddeliť procesy čítania a zápisu.
Ak je podľa vás niečo, čo nie je dostatočne zverejnené, som pripravený vám to povedať podrobnejšie. Pozývame vás podeliť sa o svoje skúsenosti alebo diskutovať, ak s niečím nesúhlasíte.
Zdroj: hab.com