A HBase használatának elmélete és gyakorlata

Jó napot Danil Lipovoy vagyok, a Sbertech csapata elkezdte használni a HBase-t működési adatok tárolására. Tanulmányozása során felhalmozódott a tapasztalat, amit szerettem volna rendszerezni, leírni (reméljük, sokaknak hasznos lesz). Az összes alábbi kísérletet a HBase 1.2.0-cdh5.14.2 és 2.0.0-cdh6.0.0-beta1 verziójával végeztük.

1. Általános építészet
2. Adatok írása a HBASE-ba
3. Adatok olvasása a HBASE-ból
4. Adatgyorsítótár
5. Kötegelt adatfeldolgozás MultiGet/MultiPut
6. Stratégia a táblázatok régiókra való felosztására (felosztás)
7. Hibatűrés, tömörítés és adatlokalitás
8. Beállítások és teljesítmény
9. Stressz tesztelés
10. Álláspontja

1. Általános architektúra

A tartalék Master figyeli az aktív szívverését a ZooKeeper csomóponton, és eltűnés esetén átveszi a master funkcióit.

2. Írjon adatokat a HBASE-ba

Először nézzük meg a legegyszerűbb esetet - kulcsérték objektum írását egy táblába a put(rowkey) segítségével. A kliensnek először meg kell találnia, hogy hol található a hbase:meta táblát tároló Root Region Server (RRS). Ezt az információt a ZooKeepertől kapja. Ezt követően hozzáfér az RRS-hez, és beolvassa a hbase:meta táblát, amelyből információt nyer ki arról, hogy melyik RegionServer (RS) felelős az adott sorkulcs adatainak tárolásáért az érdekes táblában. A jövőbeni felhasználás érdekében a metatáblát a kliens gyorsítótárazza, ezért a következő hívások gyorsabban mennek közvetlenül az RS-re.

Ezután az RS, miután megkapta a kérést, mindenekelőtt a WriteAheadLog-ba (WAL) írja, amely szükséges a helyreállításhoz egy összeomlás esetén. Ezután elmenti az adatokat a MemStore-ba. Ez egy puffer a memóriában, amely egy adott régióhoz tartozó kulcsok rendezett készletét tartalmazza. Egy tábla régiókra (partíciókra) osztható, amelyek mindegyike diszjunkt kulcskészletet tartalmaz. Ez lehetővé teszi, hogy régiókat helyezzen el különböző szervereken a nagyobb teljesítmény elérése érdekében. Ennek az állításnak a nyilvánvalósága ellenére azonban később látni fogjuk, hogy ez nem minden esetben működik.

Miután elhelyezett egy bejegyzést a MemStore-ban, a rendszer visszaküldi a kliensnek azt a választ, hogy a bejegyzést sikeresen elmentették. A valóságban azonban csak egy pufferben tárolódik, és csak bizonyos idő elteltével, vagy új adatokkal való feltöltésekor kerül a lemezre.

A „Törlés” művelet végrehajtásakor az adatok fizikailag nem törlődnek. Egyszerűen töröltként jelölik meg őket, és maga a megsemmisítés a fő kompakt függvény meghívásának pillanatában következik be, amelyet részletesebben a 7. bekezdés ismertet.

A HFile formátumú fájlok HDFS-ben halmozódnak fel, és időről időre elindul a kisebb kompakt folyamat, amely egyszerűen egyesíti a kis fájlokat nagyobbakká anélkül, hogy bármit is törölne. Idővel ez olyan problémává válik, ami csak az adatok beolvasásakor jelenik meg (erre kicsit később visszatérünk).

A fent leírt betöltési folyamaton kívül van egy sokkal hatékonyabb eljárás is, ami talán ennek az adatbázisnak a legerősebb oldala - a BulkLoad. Ez abban rejlik, hogy önállóan alakítjuk ki a HFiles-t, és lemezre helyezzük őket, ami lehetővé teszi a tökéletes méretezést és nagyon tisztességes sebesség elérését. Valójában itt nem a HBase a korlát, hanem a hardver képességei. Az alábbiakban a 16 RegionServerből és 16 NodeManager YARN-ből (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 szál) álló fürt rendszerindítási eredményei láthatók, HBase 1.2.0-cdh5.14.2 verzió.

Itt látható, hogy a táblában lévő partíciók (régiók) számának, valamint a Spark végrehajtóinak növelésével a letöltési sebesség növekedését kapjuk. A sebesség a felvételi hangerőtől is függ. A nagy blokkok növelik az MB/sec-ot, a kis blokkok pedig az időegységenként beszúrt rekordok számát, minden más tényező változatlansága mellett.

Egyszerre két asztalba is elkezdhet betölteni, és dupla sebességet érhet el. Alább látható, hogy a 10 KB-os blokkok egyszerre két táblába írása kb. 600 MB/sec sebességgel megy végbe mindegyikben (összesen 1275 MB/sec), ami egybeesik az egy tábla írási sebességével 623 MB/sec (lásd 11. sz. fent)

De a második futtatás 50 KB rekordokkal azt mutatja, hogy a letöltési sebesség enyhén nő, ami azt jelzi, hogy közeledik a határértékekhez. Ugyanakkor szem előtt kell tartani, hogy magán a HBASE-n gyakorlatilag nem keletkezik terhelés, mindössze annyi kell hozzá, hogy először adatokat adjon meg a hbase:meta-ból, majd a HFiles beillesztése után állítsa vissza a BlockCache adatokat és mentse el a MemStore puffer a lemezre, ha nem üres.

3. Adatok beolvasása a HBASE-ból

Ha feltételezzük, hogy a kliens már rendelkezik minden információval a hbase:meta-ból (lásd a 2. pontot), akkor a kérés közvetlenül az RS-hez megy, ahol a szükséges kulcsot tárolják. Először a keresést a MemCache-ben hajtják végre. Függetlenül attól, hogy vannak-e ott adatok vagy sem, a keresés a BlockCache pufferben és szükség esetén a HFiles-ben is megtörténik. Ha adatot talált a fájlban, akkor azokat a BlockCache-be helyezi, és a következő kéréskor gyorsabban visszaküldi. A HFile-ben viszonylag gyors a keresés a Bloom szűrő használatának köszönhetően, pl. kis mennyiségű adat beolvasása után azonnal megállapítja, hogy ez a fájl tartalmazza-e a szükséges kulcsot, és ha nem, akkor továbblép a következőre.

Miután megkapta az adatokat ebből a három forrásból, az RS választ generál. Konkrétan egy objektum több talált verzióját is képes egyszerre átvinni, ha az ügyfél verziószámítást kért.

4. Adatgyorsítótár

A MemStore és BlockCache pufferek a lefoglalt on-heap RS-memória 80%-át foglalják el (a többi RS-szolgáltatási feladatok számára van fenntartva). Ha a tipikus használati mód olyan, hogy a folyamatok ugyanazokat az adatokat írják és azonnal olvassák, akkor érdemes csökkenteni a BlockCache-t és növelni a MemStore-t, mert Ha az írási adatok nem kerülnek a gyorsítótárba olvasás céljából, a BlockCache ritkábban kerül felhasználásra. A BlockCache puffer két részből áll: LruBlockCache (mindig halomban van) és BucketCache (általában halmon kívüli vagy SSD-n). A BucketCache-t akkor kell használni, ha sok az olvasási kérés, és azok nem férnek bele az LruBlockCache-be, ami a Garbage Collector aktív munkájához vezet. Ugyanakkor az olvasási gyorsítótár használatától nem kell számítani radikális teljesítménynövekedésre, de erre a 8. bekezdésben visszatérünk.

Egy BlockCache van a teljes RS-hez, és minden asztalhoz egy MemStore (egy minden oszlopcsaládhoz).

Mint leírta elméletileg írás közben az adatok nem kerülnek a gyorsítótárba, és valóban, a CACHE_DATA_ON_WRITE paraméterek a táblához és a „Cache DATA on Write” RS esetén hamisra vannak állítva. A gyakorlatban azonban, ha adatokat írunk a MemStore-ba, majd kihúzzuk a lemezre (így törljük), majd töröljük a keletkezett fájlt, akkor egy get kérés végrehajtásával sikeresen megkapjuk az adatokat. Sőt, még akkor is, ha teljesen letiltja a BlockCache-t, és feltölti a táblát új adatokkal, majd visszaállítja a MemStore-t lemezre, törli őket és lekéri őket egy másik munkamenetből, akkor is lekérik őket valahonnan. A HBase tehát nem csak adatokat tárol, hanem rejtélyes rejtélyeket is.

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

A "Cache DATA on Read" paraméter értéke hamis. Ha van ötletetek, szívesen megvitatjátok kommentben.

5. Batch adatfeldolgozás MultiGet/MultiPut

Az egyedi kérések feldolgozása (Get/Put/Delete) meglehetősen költséges művelet, ezért ha lehetséges, érdemes Listává vagy Listává kombinálni, amivel jelentős teljesítménynövekedés érhető el. Ez különösen igaz az írási műveletre, de olvasáskor a következő buktató van. Az alábbi grafikon azt mutatja, hogy mennyi idő telt el 50 000 rekord kiolvasásához a MemStore-ból. Az olvasás egy szálban történt, és a vízszintes tengely a kérésben lévő kulcsok számát mutatja. Itt látható, hogy egy kérésben ezer kulcsra növelve a végrehajtási idő lecsökken, pl. sebesség nő. Ha azonban az MSLAB mód alapértelmezés szerint engedélyezve van, e küszöbérték után radikális teljesítménycsökkenés kezdődik, és minél nagyobb az adatmennyiség a rekordban, annál hosszabb a működési idő.

A teszteket egy virtuális gépen, 8 maggal, HBase 2.0.0-cdh6.0.0-beta1 verzióval végeztük.

Az MSLAB módot úgy tervezték, hogy csökkentse a halom töredezettségét, amely az új és a régi generációk adatainak keveredése miatt következik be. Megkerülő megoldásként, ha az MSLAB engedélyezve van, az adatok viszonylag kis cellákba (darabokba) kerülnek, és darabokban dolgozzák fel őket. Ennek eredményeként, ha a kért adatcsomag mennyisége meghaladja a lefoglalt méretet, a teljesítmény meredeken csökken. Másrészt ennek az üzemmódnak a kikapcsolása sem tanácsos, mert az intenzív adatfeldolgozás pillanataiban a GC miatti leállásokhoz vezet. Jó megoldás a cella térfogatának növelése aktív írás esetén az olvasással egyidejűleg. Érdemes megjegyezni, hogy a probléma nem jelentkezik, ha a rögzítés után lefuttatja a flush parancsot, amely visszaállítja a MemStore-t lemezre, vagy ha a BulkLoad használatával tölt be. Az alábbi táblázat azt mutatja, hogy a MemStore-ból nagyobb (és azonos mennyiségű) adatokra irányuló lekérdezések lassulást eredményeznek. A darabok méretének növelésével azonban visszaállítjuk a feldolgozási időt a normál értékre.

A darabméret növelése mellett az adatok régiónkénti felosztása segít, pl. asztalosztás. Ez azt eredményezi, hogy az egyes régiókba kevesebb kérés érkezik, és ha elférnek egy cellában, a válasz jó marad.

6. Stratégia a táblázatok régiókra való felosztására (felosztás)

Mivel a HBase egy kulcsérték tároló, és a particionálás kulcson keresztül történik, rendkívül fontos, hogy az adatokat egyenletesen osszuk fel az összes régió között. Például, ha egy ilyen táblát három részre osztunk fel, az adatok három régióra oszlanak:

Előfordulhat, hogy ez éles lassuláshoz vezet, ha a később betöltött adatok például hosszú értékeknek tűnnek, amelyek többsége ugyanazzal a számjellel kezdődik, például:

1000001
1000002
...
1100003

Mivel a kulcsok bájttömbként vannak tárolva, mindegyik ugyanúgy kezdődik, és ugyanabba az 1. régióba tartozik, ahol ezt a kulcstartományt tárolják. Számos particionálási stratégia létezik:

HexStringSplit – A kulcsot hexadecimális kódolású karakterláncsá alakítja a "00000000" => "FFFFFFFF" tartományban, és a bal oldalon nullákkal tölti ki.

UniformSplit – A kulcsot egy bájttömbbé alakítja hexadecimális kódolással a "00" => "FF" tartományban, a jobb oldalon pedig nullákkal van kitöltve.

Ezenkívül megadhat bármilyen tartományt vagy kulcskészletet a felosztáshoz, és konfigurálhatja az automatikus felosztást. Az egyik legegyszerűbb és leghatékonyabb megközelítés azonban az UniformSplit és a hash-összefűzés használata, például a kulcsnak a CRC32(rowkey) függvényen keresztül történő futtatásából származó legjelentősebb bájtpár és maga a sorkulcs:

hash + sorkulcs

Ezután minden adat egyenletesen oszlik el a régiók között. Olvasáskor az első két bájt egyszerűen eldobásra kerül, és az eredeti kulcs megmarad. Az RS a régióban lévő adatok és kulcsok mennyiségét is szabályozza, és a határértékek túllépése esetén automatikusan részekre bontja.

7. Hibatűrés és adatlokalitás

Mivel minden kulcskészletért csak egy régió felelős, az RS-összeomlással vagy leszereléssel kapcsolatos problémák megoldása az összes szükséges adat HDFS-ben való tárolása. Amikor az RS esik, a mester ezt a szívverés hiányán keresztül érzékeli a ZooKeeper csomóponton. Ezután hozzárendeli a kiszolgált régiót egy másik RS-hez, és mivel a HFiles egy elosztott fájlrendszerben tárolódik, az új tulajdonos beolvassa őket, és tovább szolgálja az adatokat. Mivel azonban az adatok egy része a MemStore-ban lehet, és nem volt ideje bejutni a HFiles-be, a szintén HDFS-ben tárolt WAL-t használják a műveletek előzményeinek visszaállítására. A változtatások alkalmazása után az RS képes válaszolni a kérésekre, de a lépés oda vezet, hogy az adatok és az azokat kiszolgáló folyamatok egy része más-más csomópontra, pl. a helység csökken.

A probléma megoldása a nagy tömörítés - ez az eljárás áthelyezi a fájlokat azokra a csomópontokra, amelyek felelősek értük (ahol a régiók találhatók), aminek következtében az eljárás során a hálózat és a lemezek terhelése meredeken megnő. A jövőben azonban az adatokhoz való hozzáférés észrevehetően felgyorsul. Ezenkívül a major_compaction végrehajtja az összes HFile-t egy fájlba egyesíti egy régión belül, és a táblázatbeállításoktól függően megtisztítja az adatokat. Megadhatja például, hogy egy objektum hány verzióját kell megőrizni, vagy azt az élettartamot, amely után az objektumot fizikailag törölni kell.

Ez az eljárás nagyon pozitív hatással lehet a HBase működésére. Az alábbi képen látható, hogyan romlott a teljesítmény az aktív adatrögzítés következtében. Itt láthatja, hogyan írt 40 szál egy táblába és 40 szál olvas egyszerre adatokat. Az írási szálak egyre több HFile-t generálnak, amelyeket más szálak olvasnak. Emiatt egyre több adatot kell eltávolítani a memóriából, és végül a GC működésbe lép, ami gyakorlatilag minden munkát megbénít. A nagyobb tömörítés megkezdése a keletkező törmelék eltávolításához és a termelékenység helyreállításához vezetett.

A tesztet 3 DataNode-on és 4 RS-en (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 szál) végezték. HBase verzió 1.2.0-cdh5.14.2

Érdemes megjegyezni, hogy a nagyobb tömörítés egy „élő” táblán indult, amelybe az adatokat aktívan írták és olvasták. Volt egy kijelentés az interneten, hogy ez helytelen válaszadáshoz vezethet az adatok olvasásakor. Az ellenőrzéshez elindítottunk egy folyamatot, amely új adatokat generált és egy táblába írta. Ezt követően azonnal elolvastam és ellenőriztem, hogy a kapott érték egybeesik-e a leírtakkal. Amíg ez a folyamat futott, a nagyobb tömörítést körülbelül 200 alkalommal végezték el, és egyetlen hibát sem jegyeztek fel. Talán ritkán és csak nagy terhelésnél jelentkezik a probléma, ezért biztonságosabb az írási és olvasási folyamatokat a tervek szerint leállítani, és tisztítást végezni az ilyen GC-leállások elkerülése érdekében.

Ezenkívül a nagyobb tömörítés nem befolyásolja a MemStore állapotát; a lemezre ürítéséhez és tömörítéséhez a flush (connection.getAdmin().flush(TableName.valueOf(tblName))) parancsot kell használnia.

8. Beállítások és teljesítmény

Mint már említettük, a HBase a BulkLoad végrehajtása során a legnagyobb sikerét ott mutatja meg, ahol nem kell semmit tennie. Ez azonban a legtöbb rendszerre és emberre vonatkozik. Ez az eszköz azonban alkalmasabb az adatok tömeges, nagy blokkokban történő tárolására, míg ha a folyamat több versengő olvasási és írási kérést igényel, akkor a fent leírt Get és Put parancsokat használják. Az optimális paraméterek meghatározásához indításokat hajtottak végre a táblázatparaméterek és beállítások különféle kombinációival:

• Egyszerre 10 szál indult el egymás után háromszor (nevezzük ezt szálblokknak).
• A blokkban lévő összes szál működési idejét átlagolták, és ez a blokk működésének végeredménye.
• Minden szál ugyanazzal a táblázattal működött.
• A menetblokk minden megkezdése előtt egy nagyobb tömörítést végeztek.
• Minden blokk csak egyet hajtott végre a következő műveletek közül:

– Tedd
-Kap
-Get+Put

• Minden blokk 50 000 iterációt hajtott végre a működéséből.
• Egy rekord blokkmérete 100 bájt, 1000 bájt vagy 10000 XNUMX bájt (véletlenszerű).
• A blokkokat különböző számú kért kulccsal indították el (egy kulccsal vagy 10-zel).
• A blokkok különböző asztali beállítások mellett futottak. Paraméterek megváltoztak:

— BlockCache = be- vagy kikapcsolva
— BlockSize = 65 KB vagy 16 KB
— Partíciók = 1, 5 vagy 30
— MSLAB = engedélyezve vagy letiltva

Tehát a blokk így néz ki:

a. Az MSLAB mód be/ki volt kapcsolva.
b. Létrejött egy tábla, amelyhez a következő paramétereket állítottuk be: BlockCache = igaz/nincs, BlockSize = 65/16 Kb, Partíció = 1/5/30.
c. A tömörítést GZ-re állítottuk.
d. Egyszerre 10 szálat indítottak el, amelyek 1/10 put/get/get+put műveletet végeztek ebbe a táblába 100/1000/10000 bájtos rekordokkal, és 50 000 lekérdezést hajtottak végre egymás után (véletlen kulcsok).
e. A d pontot háromszor megismételtük.
f. Az összes szál működési idejét átlagoltuk.

Minden lehetséges kombinációt teszteltünk. Előre látható, hogy a sebesség csökkenni fog a rekord méretének növekedésével, vagy a gyorsítótár letiltása lassulást okoz. A cél azonban az volt, hogy megértsük az egyes paraméterek befolyásának mértékét és jelentőségét, ezért az összegyűjtött adatokat egy lineáris regressziós függvény bemenetébe tápláltuk be, amely lehetővé teszi a szignifikancia t-statisztika segítségével történő felmérését. Az alábbiakban a Put műveleteket végrehajtó blokkok eredményei láthatók. Teljes kombinációs készlet 2*2*3*2*3 = 144 opció + 72 tk. néhányat kétszer csináltak meg. Így összesen 216 futam van:

A tesztelést egy 3 DataNode-ból és 4 RS-ből (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 szál) álló mini klaszteren végezték. HBase verzió 1.2.0-cdh5.14.2.

A legnagyobb, 3.7 másodperces beillesztési sebességet kikapcsolt MSLAB mód mellett érte el, egy partíciós asztalon, a BlockCache bekapcsolásával, BlockSize = 16, 100 bájtos rekordok, 10 darab csomagonként.
A legalacsonyabb, 82.8 mp-es beillesztési sebességet az MSLAB mód engedélyezésével érte el, egy partíciós táblán, a BlockCache engedélyezésével, BlockSize = 16, 10000 1 bájtos rekordok, egyenként.

Most pedig nézzük a modellt. Az R2-n alapuló modell jó minőségét látjuk, de teljesen egyértelmű, hogy az extrapoláció itt ellenjavallt. A rendszer tényleges viselkedése a paraméterek változásakor nem lesz lineáris, erre a modellre nem az előrejelzésekhez van szükség, hanem ahhoz, hogy megértsük, mi történt az adott paramétereken belül. Például itt azt látjuk a Student-kritériumból, hogy a BlockSize és BlockCache paraméterek nem számítanak a Put műveletnél (ami általában meglehetősen kiszámítható):

De az a tény, hogy a partíciók számának növelése a teljesítmény csökkenéséhez vezet, némileg váratlan (a BulkLoaddal már láttuk a partíciók számának növelésének pozitív hatását), bár érthető. Először is, a feldolgozáshoz egy helyett 30 régióhoz kell kérést generálni, és az adatmennyiség nem akkora, hogy ez nyereséget hozzon. Másodszor, a teljes működési időt a leglassabb RS határozza meg, és mivel a DataNode-ok száma kevesebb, mint az RS-ek száma, néhány régió nulla lokalitású. Nos, nézzük az első ötöt:

Most értékeljük a Get blokkok végrehajtásának eredményeit:

A partíciók száma veszített jelentőségéből, ami valószínűleg azzal magyarázható, hogy az adatok jól vannak gyorsítótárazva, és az olvasási gyorsítótár a legjelentősebb (statisztikai) paraméter. Természetesen az üzenetek számának növelése egy kérésben szintén nagyon hasznos a teljesítmény szempontjából. Legjobb pontszámok:

Nos, végül nézzük meg annak a blokknak a modelljét, amely először végrehajtotta a get, majd a következőt:

Itt minden paraméter jelentős. És a vezetők eredményei:

9. Terhelésvizsgálat

Nos, végre elindítunk egy többé-kevésbé tisztességes terhelést, de mindig érdekesebb, ha van mihez hasonlítani. A DataStax, a Cassandra kulcsfontosságú fejlesztőjének honlapján található eredmények Számos NoSQL-tároló NT-je, beleértve a HBase 0.98.6-1-es verzióját. A betöltést 40 szál, 100 bájt adatméret, SSD lemezek végezték. A Read-Modify-Write műveletek tesztelésének eredménye a következő eredményeket mutatta.

Ha jól értem, az olvasás 100 rekordból álló blokkban és 16 HBase csomópontnál történt, a DataStax teszt 10 ezer művelet/másodperc teljesítményt mutatott ki.

Még szerencse, hogy a mi klaszterünkben is 16 csomópont van, de nem túl „szerencsés”, hogy mindegyikben 64 mag (szál), míg a DataStax tesztben csak 4. Ellenben SSD-meghajtójuk van, nálunk HDD-k. vagy több a HBase új verziója és a CPU kihasználtsága a terhelés alatt gyakorlatilag nem nőtt jelentősen (vizuálisan 5-10 százalékkal). Próbáljuk meg azonban ezt a konfigurációt használni. Az alapértelmezett táblázatbeállítások, a kiolvasás a 0 és 50 millió közötti kulcstartományban véletlenszerűen történik (azaz lényegében minden alkalommal új). A táblázat 50 millió rekordot tartalmaz, 64 partícióra osztva. A kulcsok kivonatolása a crc32 használatával történik. A táblázat beállításai az alapértelmezettek, az MSLAB engedélyezve van. 40 szál indításakor minden szál 100 véletlenszerű kulcsból álló készletet olvas be, és azonnal visszaírja a generált 100 bájtot ezekbe a kulcsokba.

Állvány: 16 DataNode és 16 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 szál). HBase verzió 1.2.0-cdh5.14.2.

Az átlagos eredmény közelebb van a másodpercenkénti 40 ezer művelethez, ami lényegesen jobb, mint a DataStax tesztben. Kísérleti célokra azonban kissé módosíthatja a feltételeket. Nem valószínű, hogy minden munkát kizárólag egy asztalon végeznek, és csak egyedi kulcsokon. Tegyük fel, hogy van egy bizonyos „forró” kulcskészlet, amely a fő terhelést generálja. Ezért próbáljunk meg létrehozni egy terhelést nagyobb rekordokkal (10 KB), szintén 100-as kötegekben, 4 különböző táblában és a kért kulcsok tartományát 50 ezerre korlátozva Az alábbi grafikonon 40 szál elindítása látható, minden szál a következő egy 100 kulcsból álló készlet, és azonnal visszaír ezekre a kulcsokra véletlenszerűen 10 KB-ot.

Állvány: 16 DataNode és 16 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 szál). HBase verzió 1.2.0-cdh5.14.2.

A terhelés során a fent látható módon többször is nagy tömörítés indult, ennek hiányában a teljesítmény fokozatosan romlik, azonban a végrehajtás során további terhelés is keletkezik. A leállásokat különböző okok okozzák. Néha a szálak befejezték a munkát, és az újraindításuk szünetet tartott, néha pedig harmadik féltől származó alkalmazások terhelést okoztak a fürtön.

Az olvasás és azonnali írás az egyik legnehezebb munkaforgatókönyv a HBase számára. Ha csak kis, például 100 bájtos put kéréseket adunk le, 10-50 ezres csomagokba egyesítve, másodpercenként több százezer műveletet kaphatunk, és hasonló a helyzet a csak olvasható kérésekkel is. Érdemes megjegyezni, hogy az eredmények radikálisan jobbak, mint a DataStax által elért eredmények, leginkább az 50 ezres blokkokban lévő kérések miatt.

Állvány: 16 DataNode és 16 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 szál). HBase verzió 1.2.0-cdh5.14.2.

10. Konklúziók

Ez a rendszer meglehetősen rugalmasan konfigurált, de számos paraméter hatása továbbra is ismeretlen. Néhányukat tesztelték, de nem kerültek bele a kapott tesztkészletbe. Az előzetes kísérletek például jelentéktelen jelentőséget mutattak egy olyan paraméternek, mint a DATA_BLOCK_ENCODING, amely a szomszédos cellákból származó értékek segítségével kódolja az információkat, ami érthető véletlenszerűen generált adatok esetén. Ha nagyszámú ismétlődő objektumot használ, a nyereség jelentős lehet. Általánosságban elmondható, hogy a HBase egy meglehetősen komoly és átgondolt adatbázis benyomását kelti, amely meglehetősen produktív lehet nagy adattömbökkel végzett műveleteknél. Főleg, ha időben el lehet különíteni az olvasási és írási folyamatokat.

Ha van valami az Ön véleménye szerint, amit nem tártak fel eléggé, készen állok részletesebben elmondani. Meghívjuk Önt, hogy ossza meg tapasztalatait, vagy vitassa meg, ha valamivel nem ért egyet.

Forrás: will.com