Teoria è pratica di l'usu di HBase

Bonghjornu Mi chjamu Danil Lipovoy, a nostra squadra in Sbertech hà cuminciatu à aduprà HBase cum'è almacenamiento per dati operativi. In u cursu di studià, l'esperienza hà accumulatu chì vulia sistematizà è discrive (speremu chì serà utile à parechji). Tutti l'esperimenti sottu sò stati realizati cù e versioni HBase 1.2.0-cdh5.14.2 è 2.0.0-cdh6.0.0-beta1.

1. Architettura generale
2. Scrive dati à HBASE
3. Lettura di dati da HBASE
4. Cache di dati
5. Trattamentu di dati batch MultiGet/MultiPut
6. Strategia per a split tables in regions (splitting)
7. Tolleranza di difetti, compactificazione è locu di dati
8. Impostazioni è prestazioni
9. Test di Stress
10. scuperti

1. Architettura generale

U Maestru di salvezza ascolta u latu di u core di l'attivu nantu à u node ZooKeeper è, in casu di sparizione, ripiglià e funzioni di u maestru.

2. Scrivite dati à HBASE

Prima, fighjemu u casu più simplice - scrivite un oggettu chjave-valore à una tavula cù put (rowkey). U cliente deve prima scopre induve si trova u Root Region Server (RRS), chì guarda a hbase:meta table. Riceve sta infurmazione da ZooKeeper. Dopu à quale accede à RRS è leghje a tavola hbase:meta, da quale estrae l'infurmazioni nantu à quale RegionServer (RS) hè rispunsevuli di almacenà e dati per una data rowkey in a tavola d'interessu. Per un usu futuru, a meta table hè in cache da u cliente è per quessa i chjami successivi vanu più veloce, direttamente à RS.

Dopu, RS, avè ricevutu una dumanda, prima di tuttu u scrive à WriteAheadLog (WAL), chì hè necessariu per a ricuperazione in casu di crash. Allora salva i dati in MemStore. Questu hè un buffer in memoria chì cuntene un inseme ordinatu di chjave per una determinata regione. Una tavula pò esse divisa in regioni (partizioni), ognuna di quali cuntene un inseme disjoint di chjave. Questu permette di mette e regioni in diversi servitori per ottene un rendimentu più altu. Tuttavia, malgradu l'evidenza di sta dichjarazione, avemu da vede dopu chì questu ùn hè micca travagliatu in tutti i casi.

Dopu avè postu una entrata in MemStore, una risposta hè tornata à u cliente chì l'entrata hè stata salvata bè. In ogni casu, in a realità hè guardatu solu in un buffer è ghjunghje à u discu solu dopu chì un certu periodu di tempu hè passatu o quandu hè pienu di novi dati.

Quandu eseguisce l'operazione "Sguassà", i dati ùn sò micca sguassati fisicamente. Sò simpricimenti marcati cum'è sguassati, è a distruzzione stessu si faci à u mumentu di chjamà a funzione cumpatta maiò, chì hè descritta in più detail in u paràgrafu 7.

I fugliali in u furmatu HFile sò accumulati in HDFS è da u tempu à u tempu hè lanciatu u prucessu di compactu minore, chì simpricimenti unisce i fugliali chjuchi in i più grandi senza sguassà nunda. À u tempu, questu si trasforma in un prublema chì appare solu quandu leghje e dati (avemu da vultà à questu un pocu dopu).

In più di u prucessu di carica sopra descrittu, ci hè una prucedura assai più efficace, chì hè forse u latu più forte di sta basa di dati - BulkLoad. Si trova in u fattu chì formemu indipindentamente HFiles è i mette nantu à u discu, chì ci permette di scala perfettamente è ottene una velocità assai decente. In fattu, a limitazione quì ùn hè micca HBase, ma e capacità di u hardware. Quì sottu sò i risultati di u boot in un cluster custituitu da 16 RegionServers è 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads), versione HBase 1.2.0-cdh5.14.2.

Quì pudete vede chì aumentendu u nùmeru di partizioni (regioni) in a tavula, cum'è esecutori Spark, avemu un aumentu di a velocità di scaricamentu. Inoltre, a vitezza dipende di u voluminu di registrazione. I grandi blocchi dannu un aumentu di MB / sec, i picculi blocchi in u nùmeru di registri inseriti per unità di tempu, tutti l'altri cose sò uguali.

Pudete ancu inizià a carica in dui tavule à u stessu tempu è uttene u doppiu di a velocità. Quì sottu pudete vede chì a scrittura di blocchi 10 KB à duie tavule à una volta si trova à una velocità di circa 600 MB/sec in ognunu (totale 1275 MB/sec), chì coincide cù a velocità di scrittura à una tavola 623 MB/sec (vede No. 11 sopra)

Ma a seconda corsa cù record di 50 KB mostra chì a vitezza di scaricamentu cresce ligeramente, chì indica chì si avvicina à i valori limite. À u listessu tempu, avete bisognu di mantene in mente chì ùn ci hè praticamenti micca carica creata nantu à HBASE stessu, tuttu ciò chì hè necessariu di questu hè di prima dà dati da hbase:meta, è dopu avè rinforzatu HFiles, resettate i dati BlockCache è salvà u MemStore buffer à u discu, se ùn hè micca viotu.

3. Lettura di dati da HBASE

Se assumemu chì u cliente hà digià tutte l'infurmazioni da hbase:meta (vede u puntu 2), allura a dumanda va direttamente à u RS induve a chjave necessaria hè guardata. Prima, a ricerca hè fatta in MemCache. Indipendentemente da s'ellu ci hè dati o micca, a ricerca hè ancu realizata in u buffer BlockCache è, se ne necessariu, in HFiles. Se i dati sò stati truvati in u schedariu, hè piazzatu in BlockCache è serà tornatu più veloce nantu à a prossima dumanda. A ricerca in HFile hè relativamente veloce grazia à l'usu di u filtru Bloom, i.e. dopu avè lettu una piccula quantità di dati, determina immediatamente se stu schedariu cuntene a chjave necessaria è, se no, passa à u prossimu.

Dopu avè ricevutu dati da queste trè fonti, RS genera una risposta. In particulare, pò trasferisce parechje versioni truvate di un ughjettu à una volta se u cliente hà dumandatu a versione.

4. Data Caching

I buffer MemStore è BlockCache occupanu finu à u 80% di a memoria RS assignata nantu à u mucchio (u restu hè riservatu à i travaglii di serviziu RS). Se u modu di usu tipicu hè tali chì i prucessi scrivenu è leghje immediatamente i stessi dati, allora hè sensu per riduce BlockCache è cresce MemStore, perchè Quandu i dati di scrittura ùn entranu micca in a cache per a lettura, BlockCache serà utilizatu menu freti. U buffer BlockCache hè custituitu di duie parti: LruBlockCache (sempre in u heap) è BucketCache (di solitu off-heap o in un SSD). BucketCache deve esse usatu quandu ci sò parechje richieste di lettura è ùn si mette micca in LruBlockCache, chì porta à u travagliu attivu di Garbage Collector. À u listessu tempu, ùn deve micca aspittà un aumentu radicali di u rendiment da l'usu di a cache di lettura, ma torneremu à questu in u paragrafu 8.

Ci hè un BlockCache per tuttu u RS, è ci hè un MemStore per ogni tavula (una per ogni Famiglia di Colonna).

comu descrittu in teoria, quandu scrivite, i dati ùn entranu micca in u cache è in verità, tali paràmetri CACHE_DATA_ON_WRITE per a tavula è "Cache DATA on Write" per RS ​​sò stati falsi. In ogni casu, in pratica, se scrivemu dati in MemStore, poi sguassate à u discu (cusì sguassate), poi sguassate u schedariu resultanti, dopu eseguendu una dumanda di ottene, riceveremu bè i dati. Inoltre, ancu s'è disattivate completamente BlockCache è riempite a tavula cù novi dati, poi resettate u MemStore à u discu, sguassate è dumandate da una altra sessione, seranu sempre recuperati da un locu. Allora HBase guarda micca solu dati, ma ancu misteri misteriosi.

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

U paràmetru "Cache DATA on Read" hè stallatu à false. Sì avete idee, benvenutu per discutiri in i cumenti.

5. Trattamentu di dati Batch MultiGet / MultiPut

Trattamentu di e richieste singole (Get / Put / Delete) hè una operazione abbastanza caru, perchè se pussibule, duvete cumminà in una Lista o Lista, chì vi permette di ottene un impulsu significativu di rendiment. Questu hè soprattuttu veru per l'operazione di scrittura, ma quandu leghje ci hè a seguente trappula. U graficu sottu mostra u tempu di leghje 50 000 records da MemStore. A lettura hè stata realizata in un filu è l'assi horizontale mostra u numeru di chjave in a dumanda. Quì pudete vede chì quandu cresce à mille chjave in una dumanda, u tempu d'esekzione scende, i.e. a velocità aumenta. In ogni casu, cù u modu MSLAB attivatu per difettu, dopu à questu sogliu principia una calata radicali di u rendiment, è più grande hè a quantità di dati in u record, più longu u tempu di operazione.

I testi sò stati realizati nantu à una macchina virtuale, core 8, versione HBase 2.0.0-cdh6.0.0-beta1.

U modu MSLAB hè pensatu per riduce a frammentazione di l'heap, chì si trova per via di a mistura di dati da e generazioni novi è vechji. Cum'è una soluzione, quandu MSLAB hè attivatu, i dati sò posti in cellule relativamente chjuche (pezzi) è processati in pezzi. In u risultatu, quandu u voluminu in u pacchettu di dati dumandatu supera a dimensione attribuita, u rendiment diminuisce drasticamente. Per d 'altra banda, disattivà stu modu hè ancu micca cunsigliatu, postu chì vi purterà à fermate per via di GC durante i mumenti di trattamentu intensivu di dati. Una bona suluzione hè di aumentà u voluminu cellula in u casu di scrittura attiva via mette simultaneamente cù a lettura. Hè da nutà chì u prublema ùn accade micca se, dopu a registrazione, eseguite u cumandamentu di flush, chì resetta u MemStore à u discu, o se caricate cù BulkLoad. A tavula sottu mostra chì e dumande da u MemStore per dati più grande (è a stessa quantità) risultanu in rallentamenti. Tuttavia, aumentendu u chunksize turnemu u tempu di trasfurmazione à a norma.

In più di aumentà u chunksize, spliting the data by region helps, i.e. split tavola. Questu risultatu in menu richieste chì venenu à ogni regione è se si mette in una cellula, a risposta ferma bona.

6. Strategia per split tables in regions (splitting)

Siccomu HBase hè un almacenamentu di u valore di chjave è a partizione hè realizata da chjave, hè estremamente impurtante di dividisce e dati in modu uniforme in tutte e regioni. Per esempiu, a particione di una tale tavula in trè parti hà da esse divisu i dati in trè regioni:

Succede chì questu porta à un rallentamentu bruscu se i dati caricati dopu s'assumiglia, per esempiu, valori longu, a maiò parte di elli cumincianu cù a stessa cifra, per esempiu:

1000001
1000002
...
1100003

Siccomu i chjavi sò guardati cum'è un array di byte, tutti cumincianu u listessu è appartenenu à a listessa regione # 1 chì almacenanu sta gamma di chjavi. Ci sò parechje strategie di partitioning:

HexStringSplit - Trasforma a chjave in una stringa codificata esadecimale in a gamma "00000000" => "FFFFFFFF" è padding à a manca cù zeri.

UniformSplit - Trasforma a chjave in un array di byte cù codificazione esadecimale in a gamma "00" => "FF" è padding à a diritta cù zeri.

Inoltre, pudete specificà qualsiasi intervallu o set di chjave per splitting è cunfigurà auto-splitting. In ogni casu, unu di l'approcciu più simplice è efficaci hè UniformSplit è l'usu di a concatenazione di hash, per esempiu, u paru più significativu di byte da eseguisce a chjave attraversu a funzione CRC32 (rowkey) è a rowkey stessu:

hash + rowkey

Allora tutti i dati seranu distribuiti in modu uniforme in e regioni. Quandu leghje, i primi dui byte sò solu scartati è a chjave originale ferma. RS cuntrola ancu a quantità di dati è chjavi in ​​a regione è, se i limiti sò superati, automaticamente si rompe in parte.

7. Fault tolerance è data locu

Siccomu una sola regione hè rispunsevule per ogni settore di chjave, a suluzione à i prublemi assuciati à i crashes RS o a disattivazione hè di guardà tutte e dati necessarii in HDFS. Quandu RS casca, u maestru rileva questu per l'assenza di un battitu di u core in u node ZooKeeper. Allora assigna a regione servita à un altru RS è postu chì i HFiles sò almacenati in un sistema di fugliale distribuitu, u novu pruprietariu li leghje è cuntinueghja à serve i dati. In ogni casu, postu chì alcune di e dati ponu esse in MemStore è ùn anu micca u tempu di entra in HFiles, WAL, chì hè ancu guardatu in HDFS, hè utilizatu per restaurà a storia di l'operazioni. Dopu chì i cambiamenti sò appiicati, RS hè capaci di risponde à e dumande, ma a mossa porta à u fattu chì alcune di e dati è i prucessi chì li servenu finiscinu in nodi diffirenti, i.e. a località hè in diminuzione.

A suluzione à u prublema hè a cumpattazione maiò - sta prucedura traslada i schedari à quelli nodi chì sò rispunsevuli di elli (induve si trovanu e so regioni), per via di quale durante sta prucedura a carica nantu à a reta è i dischi aumenta assai. Tuttavia, in u futuru, l'accessu à e dati hè notevolmente acceleratu. Inoltre, major_compaction realiza a fusione di tutti i HFiles in un schedariu in una regione, è ancu pulisce e dati secondu e paràmetri di a tavola. Per esempiu, pudete specificà u numeru di versioni di un ughjettu chì deve esse ritenutu o a vita dopu chì l'ughjettu hè sguassatu fisicamente.

Sta prucedura pò avè un effettu assai pusitivu nantu à u funziunamentu di HBase. A stampa sottu mostra cumu u rendiment hè degradatu da u risultatu di a registrazione di dati attiva. Quì pudete vede cumu 40 fili anu scrittu à una tavola è 40 fili simultaneamente leghje dati. I fili di scrittura generanu più è più HFiles, chì sò letti da altri fili. In u risultatu, più è più dati deve esse eliminati da a memoria è eventualmente u GC principia à travaglià, chì praticamente paralizeghja tuttu u travagliu. U lanciamentu di a compactazione maiò hà purtatu à a pulitura di i detriti resultanti è a risturazione di a produtividade.

A prova hè stata realizata nantu à 3 DataNodes è 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads). Versione HBase 1.2.0-cdh5.14.2

Hè da nutà chì a cumpattazione maiò hè stata lanciata nantu à una tavula "live", in quale a dati hè stata attivamente scritta è leghje. Ci era una dichjarazione in linea chì questu puderia guidà à una risposta incorrecta quandu leghje e dati. Per verificà, hè stata lanciata un prucessu chì hà generatu novi dati è hà scrittu à una tavula. Dopu à quale aghju lettu immediatamente è verificatu se u valore resultanti coincide cù ciò chì era scrittu. Mentre chì stu prucessu era in esecuzione, a cumpattazione maiò hè stata eseguita circa 200 volte è ùn hè micca registratu un solu fallimentu. Forse u prublema si prisenta raramente è solu durante a carica alta, per quessa, hè più sicuru di piantà i prucessi di scrittura è lettura cum'è pianificatu è eseguisce a pulizia per impedisce tali drawdowns GC.

Inoltre, a cumpattazione maiò ùn affetta micca u statu di u MemStore; per sguassà à u discu è compactificà, avete bisognu di usà flush (connection.getAdmin().flush(TableName.valueOf(tblName))).

8. Settings è prestazione

Comu digià dettu, HBase mostra u so più grande successu induve ùn hà micca bisognu di fà nunda, quandu eseguisce BulkLoad. Tuttavia, questu hè applicà à a maiò parte di i sistemi è e persone. In ogni casu, questu strumentu hè più adattatu per almacenà e dati in massa in grandi blocchi, mentre chì se u prucessu richiede parechje richieste di lettura è scrittura cuncurrenti, i cumandamenti Get and Put descritti sopra sò usati. Per determinà i paràmetri ottimali, i lanciamenti sò stati realizati cù diverse cumminazzioni di parametri di tabella è paràmetri:

• 10 fili sò stati lanciati simultaneamente 3 volte in una fila (chjamemu questu un bloccu di fili).
• U tempu di funziunamentu di tutti i filamenti in un bloccu hè statu mediu è era u risultatu finali di l'operazione di u bloccu.
• Tutti i fili travagliavanu cù a stessa tavola.
• Prima di ogni iniziu di u bloccu di filu, hè stata realizata una compactazione maiò.
• Ogni bloccu hà fattu solu una di e seguenti operazioni:

— Metti
— Get
- Get + Mette

• Ogni bloccu hà realizatu 50 000 iterazioni di u so funziunamentu.
• A dimensione di bloccu di un record hè 100 bytes, 1000 bytes o 10000 bytes (aleatoriu).
• I blocchi sò stati lanciati cù diversi numeri di chjave dumandate (o una chjave o 10).
• I blocchi sò stati eseguiti sottu diverse paràmetri di tavulinu. Paràmetri cambiati:

- BlockCache = attivatu o disattivatu
- BlockSize = 65 KB o 16 KB
- Partizioni = 1, 5 o 30
- MSLAB = attivatu o disattivatu

Allora u bloccu pare cusì:

a. U modu MSLAB hè stata attivata / disattivata.
b. Una tavula hè stata creata per quale sò stati stabiliti i seguenti parametri: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
c. A cumpressione hè stata stabilita à GZ.
d. 10 fili sò stati lanciati simultaneamente fendu operazioni 1/10 put/get/get+put in sta tavula cù registri di 100/1000/10000 bytes, eseguendu 50 dumande in una fila (chjavi aleatorii).
e. U puntu d hè ripetutu trè volte.
f. U tempu di funziunamentu di tutti i fili hè statu mediu.

Tutte e cumminazzioni pussibuli sò stati pruvati. Hè prevedibile chì a velocità scenderà cum'è a dimensione di u record aumenta, o chì disattivà a cache causarà rallentamentu. In ogni casu, u scopu era di capisce u gradu è u significatu di l'influenza di ogni paràmetru, cusì i dati raccolti sò stati alimentati in l'input di una funzione di regressione lineale, chì permette di valutà u significatu cù t-statistiche. Quì sottu sò i risultati di i blocchi chì facenu operazioni Put. Set cumpletu di cumminazzioni 2*2*3*2*3 = 144 opzioni + 72 tk. certi sò stati fatti duie volte. Dunque, ci sò 216 corse in totale:

A prova hè stata realizata nantu à un mini-cluster custituitu da 3 DataNodes è 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads). Versione HBase 1.2.0-cdh5.14.2.

A più alta velocità di inserimentu di 3.7 seconde hè stata ottenuta cù u modu MSLAB disattivatu, nantu à una tavula cù una partizione, cù BlockCache attivatu, BlockSize = 16, records di 100 bytes, 10 pezzi per pack.
A più bassa velocità di inserimentu di 82.8 sec hè stata ottenuta cù u modu MSLAB attivatu, nantu à una tavula cù una partizione, cù BlockCache attivatu, BlockSize = 16, records di 10000 bytes, 1 ognunu.

Avà fighjemu u mudellu. Avemu vistu a bona qualità di u mudellu basatu annantu à R2, ma hè assolutamente chjaru chì l'estrapolazione hè contraindicata quì. U cumpurtamentu propiu di u sistema quandu i paràmetri cambianu ùn serà micca lineare; stu mudellu hè necessariu micca per e prediczioni, ma per capisce ciò chì hè accadutu in i paràmetri dati. Per esempiu, quì vedemu da u criteriu di u Studente chì i paràmetri BlockSize è BlockCache ùn importa micca per l'operazione Put (chì in generale hè abbastanza prevedibile):

Ma u fattu chì l'aumentu di u nùmeru di partizioni porta à una diminuzione di u rendiment hè un pocu inesperu (avemu digià vistu l'impattu pusitivu di aumentà u nùmeru di partizioni cù BulkLoad), anchi si capisce. Prima, per a trasfurmazioni, avete da generà richieste à 30 regioni invece di una, è u voluminu di dati ùn hè micca cusì chì questu rende un guadagnu. Siconda, u tempu di u funziunamentu tutale hè determinatu da u RS più lento, è postu chì u numeru di DataNodes hè menu di u numeru di RS, certi rigioni anu una località zero. Ebbè, fighjemu i primi cinque:

Avà valutemu i risultati di eseguisce i blocchi Get:

U nùmeru di partizioni hà persu significatu, chì hè prubabilmente spiegatu da u fattu chì i dati sò in cache bè è a cache di lettura hè u paràmetru più significativu (statisticamente). Naturalmente, aumentà u numeru di missaghji in una dumanda hè ancu assai utile per u rendiment. Top scores:

Eppo, infine, fighjemu u mudellu di u bloccu chì prima hà realizatu ottene è poi mette:

Tutti i paràmetri sò significativi quì. È i risultati di i capi:

9. Test di carica

Ebbè, infine lanceremu una carica più o menu decente, ma hè sempre più interessante quandu avete qualcosa per paragunà. In u situ web di DataStax, u sviluppatore chjave di Cassandra, ci hè Risultati NT di una quantità di almacenamenti NoSQL, cumprese a versione HBase 0.98.6-1. A carica hè stata realizata da 40 fili, data size 100 bytes, dischi SSD. U risultatu di a prova di l'operazioni Read-Modify-Write hà mostratu i seguenti risultati.

In quantu capiscu, a lettura hè stata realizata in blocchi di 100 records è per i nodi 16 HBase, a prova DataStax hà dimustratu un rendimentu di 10 mila operazioni per seconda.

Hè furtunatu chì u nostru cluster hà ancu 16 nodi, ma ùn hè micca assai "furtunatu" chì ognunu hà 64 core (fili), mentre chì in a prova di DataStax ci sò solu 4. Per d 'altra banda, anu unità SSD, mentri avemu HDD. o più a nova versione di HBase è l'utilizazione di CPU durante a carica praticamenti ùn anu micca aumentatu significativamente (visualmente da 5-10 per centu). Tuttavia, pruvemu à principià cù sta cunfigurazione. Paràmetri predeterminati di a tavola, a lettura hè realizata in a gamma chjave da 0 à 50 milioni in modu aleatoriu (vale à dì, essenzialmente novu ogni volta). A tavula cuntene 50 milioni di dischi, spartuti in 64 partizioni. I chjavi sò hashed cù crc32. I paràmetri di a tavola sò predeterminati, MSLAB hè attivatu. Lanciando 40 fili, ogni filu leghje un inseme di 100 chjavi aleatorii è scrive immediatamente i 100 bytes generati in queste chjavi.

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

U risultatu mediu hè più vicinu à 40 mila operazioni per seconda, chì hè significativamente megliu cà in a prova DataStax. Tuttavia, per scopi sperimentali, pudete cambià ligeramente e cundizioni. Hè abbastanza improbabile chì tuttu u travagliu serà realizatu solu nantu à una tavola, è ancu solu nantu à e chjave uniche. Assumimu chì ci hè un certu settore "caldo" di chjave chì genera a carica principale. Dunque, pruvemu di creà una carica cù registri più grande (10 KB), ancu in batch di 100, in 4 diverse tavule è limitendu a gamma di chjave dumandate à 50 mila. U graficu sottu mostra u lanciu di fili 40, ogni filu leghje. un set di 100 chjavi è scrive immediatamente 10 KB aleatoriu nantu à sti chjavi.

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

Durante a carica, a cumpattazione maiò hè stata lanciata parechje volte, cum'è mostratu sopra, senza sta prucedura, u rendiment si degrada gradualmente, ma ancu una carica addiziale sorge durante l'esecuzione. I drawdowns sò causati da diverse ragioni. Calchì volta i fili finiscinu di travaglià è ci era una pausa mentre eranu riavviati, qualchì volta l'applicazioni di terzu creanu una carica nantu à u cluster.

A lettura è a scrittura immediata hè unu di i scenarii di travagliu più difficili per HBase. Sè vo fate solu picculi richieste di mette, per esempiu 100 bytes, cumminendu in pacchetti di 10-50 mila pezzi, pudete ottene centinaie di millaie di operazioni per seconda, è a situazione hè simile cù e dumande di sola lettura. Hè da nutà chì i risultati sò radicali megliu cà quelli ottenuti da DataStax, soprattuttu per via di richieste in blocchi di 50 mila.

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

10. Cunclusioni

Stu sistema hè abbastanza flexible cunfiguratu, ma l'influenza di un gran numaru di parametri resta sempre scunnisciutu. Certi di elli sò stati pruvati, ma ùn sò micca stati inclusi in u set di teste resultanti. Per esempiu, esperimenti preliminari anu dimustratu un significatu insignificante di un tali paràmetru cum'è DATA_BLOCK_ENCODING, chì codifica l'infurmazioni utilizendu valori da e cellule vicine, chì hè comprensibile per dati generati aleatoriamente. Se utilizate un gran numaru di oggetti duplicati, u guadagnu pò esse significativu. In generale, pudemu dì chì HBase dà l'impressione di una basa di dati abbastanza seria è ben pensata, chì pò esse abbastanza produtiva quandu eseguisce operazioni cù grandi blocchi di dati. In particulare s'ellu hè pussibule separà i prucessi di lettura è scrittura in u tempu.

S'ellu ci hè qualcosa in u vostru parè chì ùn hè micca divulgatu abbastanza, sò prontu à dì vi in ​​più detail. Vi invitemu à sparte a vostra sperienza o discute se ùn site micca d'accordu cù qualcosa.

Source: www.habr.com