Teoria e pratica dell'uso di HBase

Buon pomeriggio Mi chiamo Danil Lipovoy, il nostro team di Sbertech ha iniziato a utilizzare HBase come archivio per i dati operativi. Nel corso del suo studio si è accumulata esperienza che ho voluto sistematizzare e descrivere (speriamo che possa essere utile a molti). Tutti gli esperimenti seguenti sono stati eseguiti con le versioni HBase 1.2.0-cdh5.14.2 e 2.0.0-cdh6.0.0-beta1.

1. Architettura generale
2. Scrittura dei dati su HBASE
3. Lettura dei dati da HBASE
4. Cache dei dati
5. Elaborazione dati batch MultiGet/MultiPut
6. Strategia per dividere le tabelle in regioni (splitting)
7. Tolleranza agli errori, compattazione e localizzazione dei dati
8. Impostazioni e prestazioni
9. Prove di stress
10. risultati

1. Architettura generale

Il Master di backup ascolta il battito cardiaco di quello attivo sul nodo ZooKeeper e, in caso di scomparsa, assume le funzioni del master.

2. Scrivere i dati su HBASE

Innanzitutto, esaminiamo il caso più semplice: scrivere un oggetto chiave-valore in una tabella utilizzando put(rowkey). Il client deve prima scoprire dove si trova il Root Region Server (RRS), che memorizza la tabella hbase:meta. Riceve queste informazioni da ZooKeeper. Successivamente accede a RRS e legge la tabella hbase:meta, dalla quale estrae informazioni su quale RegionServer (RS) è responsabile della memorizzazione dei dati per un determinato rowkey nella tabella di interesse. Per un uso futuro, la meta tabella viene memorizzata nella cache dal client e quindi le chiamate successive vanno più velocemente, direttamente a RS.

Successivamente, RS, dopo aver ricevuto una richiesta, la scrive prima su WriteAheadLog (WAL), necessario per il ripristino in caso di crash. Quindi salva i dati su MemStore. Si tratta di un buffer in memoria che contiene un set ordinato di chiavi per una determinata regione. Una tabella può essere divisa in regioni (partizioni), ciascuna delle quali contiene un insieme disgiunto di chiavi. Ciò ti consente di posizionare regioni su server diversi per ottenere prestazioni più elevate. Tuttavia, nonostante l’ovvietà di questa affermazione, vedremo in seguito che ciò non funziona in tutti i casi.

Dopo aver inserito una voce nel MemStore, al client viene restituita una risposta che la voce è stata salvata correttamente. Tuttavia, in realtà viene memorizzato solo in un buffer e arriva sul disco solo dopo che è trascorso un certo periodo di tempo o quando si riempie di nuovi dati.

Quando si esegue l'operazione "Elimina", i dati non vengono eliminati fisicamente. Sono semplicemente contrassegnati come cancellati e la distruzione stessa avviene al momento della chiamata della funzione compatta principale, descritta più dettagliatamente nel paragrafo 7.

I file in formato HFile vengono accumulati in HDFS e di tanto in tanto viene avviato il processo compatto minore, che semplicemente unisce file piccoli in file più grandi senza eliminare nulla. Con il passare del tempo, questo si trasforma in un problema che appare solo durante la lettura dei dati (torneremo su questo un po' più tardi).

Oltre al processo di caricamento sopra descritto, esiste una procedura molto più efficace, che è forse il punto di forza di questo database: BulkLoad. Sta nel fatto che formiamo HFile in modo indipendente e li mettiamo su disco, il che ci consente di scalare perfettamente e raggiungere velocità molto decenti. In effetti, la limitazione qui non è HBase, ma le capacità dell'hardware. Di seguito sono riportati i risultati di avvio su un cluster composto da 16 RegionServer e 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 thread), versione HBase 1.2.0-cdh5.14.2.

Qui puoi vedere che aumentando il numero di partizioni (regioni) nella tabella, così come gli esecutori Spark, otteniamo un aumento della velocità di download. Inoltre, la velocità dipende dal volume di registrazione. I blocchi grandi danno un aumento in MB/sec, i blocchi piccoli nel numero di record inseriti per unità di tempo, a parità di altre condizioni.

Puoi anche iniziare a caricare due tabelle contemporaneamente e ottenere il doppio della velocità. Di seguito puoi vedere che la scrittura di blocchi da 10 KB su due tabelle contemporaneamente avviene ad una velocità di circa 600 MB/sec in ciascuna (totale 1275 MB/sec), che coincide con la velocità di scrittura su una tabella di 623 MB/sec (vedi N. 11 sopra)

Ma la seconda esecuzione con record di 50 KB mostra che la velocità di download aumenta leggermente, il che indica che si sta avvicinando ai valori limite. Allo stesso tempo, è necessario tenere presente che praticamente non viene creato alcun carico su HBASE stesso, tutto ciò che è richiesto è prima fornire i dati da hbase:meta e, dopo aver allineato HFiles, reimpostare i dati BlockCache e salvare il file Buffer MemStore su disco, se non è vuoto.

3. Lettura dei dati da HBASE

Se assumiamo che il client abbia già tutte le informazioni da hbase:meta (vedi punto 2), allora la richiesta va direttamente alla RS dove è memorizzata la chiave richiesta. Innanzitutto, la ricerca viene eseguita in MemCache. Indipendentemente dal fatto che siano presenti o meno dei dati, la ricerca viene effettuata anche nel buffer BlockCache ed eventualmente negli HFiles. Se i dati sono stati trovati nel file, vengono inseriti in BlockCache e verranno restituiti più velocemente alla richiesta successiva. La ricerca in HFile è relativamente veloce grazie all'uso del filtro Bloom, ad es. dopo aver letto una piccola quantità di dati, determina immediatamente se questo file contiene la chiave richiesta e, in caso contrario, passa a quello successivo.

Dopo aver ricevuto i dati da queste tre fonti, RS genera una risposta. In particolare, può trasferire contemporaneamente più versioni trovate di un oggetto se il client ha richiesto il controllo delle versioni.

4. Cache dei dati

I buffer MemStore e BlockCache occupano fino all'80% della memoria RS sull'heap allocata (il resto è riservato alle attività del servizio RS). Se la modalità di utilizzo tipica è tale che i processi scrivono e leggono immediatamente gli stessi dati, allora ha senso ridurre BlockCache e aumentare MemStore, perché Quando i dati di scrittura non entrano nella cache per la lettura, BlockCache verrà utilizzato meno frequentemente. Il buffer BlockCache è composto da due parti: LruBlockCache (sempre sull'heap) e BucketCache (solitamente off-heap o su un SSD). BucketCache dovrebbe essere utilizzato quando ci sono molte richieste di lettura e non rientrano in LruBlockCache, il che porta al lavoro attivo di Garbage Collector. Allo stesso tempo, non dovresti aspettarti un aumento radicale delle prestazioni dall'utilizzo della cache di lettura, ma torneremo su questo nel paragrafo 8

C'è una BlockCache per l'intera RS e c'è un MemStore per ogni tabella (uno per ogni famiglia di colonne).

Come descritto in teoria in fase di scrittura i dati non entrano nella cache ed infatti tali parametri CACHE_DATA_ON_WRITE per la tabella e “Cache DATA on Write” per RS ​​sono impostati a false. Tuttavia, in pratica, se scriviamo dati su MemStore, quindi li scarichiamo su disco (cancellandoli quindi), quindi eliminiamo il file risultante, quindi eseguendo una richiesta get riceveremo con successo i dati. Inoltre, anche se disabiliti completamente BlockCache e riempi la tabella con nuovi dati, quindi reimposti il ​​MemStore su disco, li elimini e li richiedi da un'altra sessione, verranno comunque recuperati da qualche parte. Quindi HBase memorizza non solo dati, ma anche 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

Il parametro "Cache DATA on Read" è impostato su false. Se hai qualche idea, benvenuto per discuterne nei commenti.

5. Elaborazione dati batch MultiGet/MultiPut

L'elaborazione di singole richieste (Get/Put/Delete) è un'operazione piuttosto costosa, quindi, se possibile, dovresti combinarle in un Elenco o Elenco, che consente di ottenere un notevole incremento delle prestazioni. Ciò è particolarmente vero per l'operazione di scrittura, ma durante la lettura si presenta il seguente errore. Il grafico seguente mostra il tempo impiegato per leggere 50 record da MemStore. La lettura è stata eseguita in un thread e l'asse orizzontale mostra il numero di chiavi presenti nella richiesta. Qui puoi vedere che quando si aumenta fino a mille chiavi in ​​una richiesta, il tempo di esecuzione diminuisce, ad es. la velocità aumenta. Tuttavia, con la modalità MSLAB abilitata per impostazione predefinita, dopo questa soglia inizia un calo radicale delle prestazioni e maggiore è la quantità di dati nel record, maggiore è il tempo di funzionamento.

I test sono stati eseguiti su una macchina virtuale, 8 core, versione HBase 2.0.0-cdh6.0.0-beta1.

La modalità MSLAB è progettata per ridurre la frammentazione dell'heap, che si verifica a causa della miscelazione di dati di nuova e vecchia generazione. Per ovviare al problema, quando MSLAB è abilitato, i dati vengono inseriti in celle relativamente piccole (blocchi) ed elaborati in blocchi. Di conseguenza, quando il volume del pacchetto di dati richiesto supera la dimensione allocata, le prestazioni diminuiscono drasticamente. D'altra parte, anche la disattivazione di questa modalità non è consigliabile, poiché causerebbe arresti dovuti al GC durante i momenti di elaborazione intensiva dei dati. Una buona soluzione è aumentare il volume del cellulare in caso di scrittura attiva tramite put contemporaneamente alla lettura. Vale la pena notare che il problema non si verifica se, dopo la registrazione, si esegue il comando flush, che reimposta il MemStore su disco, o se si carica utilizzando BulkLoad. La tabella seguente mostra che le query dal MemStore per dati più grandi (e della stessa quantità) provocano rallentamenti. Tuttavia, aumentando la dimensione del blocco riportiamo il tempo di elaborazione alla normalità.

Oltre ad aumentare la dimensione del blocco, dividere i dati per regione aiuta, ad es. suddivisione del tavolo. Ciò si traduce in un minor numero di richieste che arrivano a ciascuna regione e se rientrano in una cella, la risposta rimane buona.

6. Strategia per la suddivisione delle tabelle in regioni (splitting)

Poiché HBase è un'archiviazione di valori-chiave e il partizionamento viene eseguito per chiave, è estremamente importante dividere i dati equamente in tutte le regioni. Ad esempio, il partizionamento di una tabella di questo tipo in tre parti comporterà la suddivisione dei dati in tre regioni:

Succede che ciò porta ad un forte rallentamento se i dati caricati successivamente assomigliano, ad esempio, a valori lunghi, la maggior parte dei quali inizia con la stessa cifra, ad esempio:

1000001
1000002
...
1100003

Poiché le chiavi vengono archiviate come array di byte, inizieranno tutte allo stesso modo e apparterranno alla stessa regione n. 1 in cui è memorizzato questo intervallo di chiavi. Esistono diverse strategie di partizionamento:

HexStringSplit – Trasforma la chiave in una stringa codificata esadecimale nell'intervallo "00000000" => "FFFFFFFF" e riempiendo a sinistra con zeri.

UniformSplit – Trasforma la chiave in un array di byte con codifica esadecimale nell'intervallo "00" => "FF" e riempimento a destra con zeri.

Inoltre, puoi specificare qualsiasi intervallo o set di chiavi per la suddivisione e configurare la suddivisione automatica. Tuttavia, uno degli approcci più semplici ed efficaci è UniformSplit e l'uso della concatenazione di hash, ad esempio la coppia di byte più significativa dall'esecuzione della chiave attraverso la funzione CRC32(rowkey) e il rowkey stesso:

hash + tasto di riga

Quindi tutti i dati verranno distribuiti uniformemente tra le regioni. Durante la lettura, i primi due byte vengono semplicemente scartati e rimane la chiave originale. RS controlla anche la quantità di dati e chiavi nella regione e, se i limiti vengono superati, li suddivide automaticamente in parti.

7. Tolleranza agli errori e localizzazione dei dati

Poiché solo una regione è responsabile per ciascun set di chiavi, la soluzione ai problemi associati ai crash o allo smantellamento di RS è archiviare tutti i dati necessari in HDFS. Quando RS cade, il master lo rileva attraverso l'assenza di un battito cardiaco sul nodo ZooKeeper. Quindi assegna la regione servita a un'altra RS e poiché gli HFile sono archiviati in un file system distribuito, il nuovo proprietario li legge e continua a servire i dati. Tuttavia, poiché alcuni dati potrebbero trovarsi nel MemStore e non hanno avuto il tempo di entrare in HFiles, WAL, anch'esso archiviato in HDFS, viene utilizzato per ripristinare la cronologia delle operazioni. Dopo che le modifiche sono state applicate, RS è in grado di rispondere alle richieste, ma lo spostamento porta al fatto che alcuni dati e i processi che li servono finiscono su nodi diversi, ad es. la località sta diminuendo

La soluzione al problema è una compattazione maggiore: questa procedura sposta i file su quei nodi che ne sono responsabili (dove si trovano le loro regioni), a seguito della quale durante questa procedura il carico sulla rete e sui dischi aumenta notevolmente. Tuttavia, in futuro, l’accesso ai dati sarà notevolmente accelerato. Inoltre, major_compaction esegue l'unione di tutti gli HFile in un unico file all'interno di una regione e ripulisce anche i dati in base alle impostazioni della tabella. Ad esempio, è possibile specificare il numero di versioni di un oggetto che devono essere conservate o la durata dopo la quale l'oggetto viene eliminato fisicamente.

Questa procedura può avere un effetto molto positivo sul funzionamento di HBase. L'immagine seguente mostra il peggioramento delle prestazioni a causa della registrazione attiva dei dati. Qui puoi vedere come 40 thread hanno scritto su una tabella e 40 thread hanno letto i dati contemporaneamente. I thread di scrittura generano sempre più HFile, che vengono letti da altri thread. Di conseguenza, è necessario rimuovere sempre più dati dalla memoria e alla fine il GC inizia a funzionare, il che praticamente paralizza tutto il lavoro. L'avvio di un'importante compattazione ha portato alla rimozione dei detriti risultanti e al ripristino della produttività.

Il test è stato eseguito su 3 DataNode e 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 thread). Versione HBase 1.2.0-cdh5.14.2

Vale la pena notare che la compattazione principale è stata avviata su una tabella "live", in cui i dati venivano scritti e letti attivamente. C'era una dichiarazione online secondo cui ciò potrebbe portare a una risposta errata durante la lettura dei dati. Per verificare, è stato avviato un processo che generava nuovi dati e li scriveva su una tabella. Dopodiché ho subito letto e controllato se il valore risultante coincideva con quanto annotato. Durante l'esecuzione di questo processo, la compattazione maggiore è stata eseguita circa 200 volte e non è stato registrato un solo guasto. Forse il problema si presenta raramente e solo durante carichi elevati, quindi è più sicuro interrompere i processi di scrittura e lettura come pianificato ed eseguire la pulizia per evitare tali prelievi del GC.

Inoltre, la compattazione principale non influisce sullo stato del MemStore; per scaricarlo su disco e compattarlo, è necessario utilizzare flush (connection.getAdmin().flush(TableName.valueOf(tblName))).

8. Impostazioni e prestazioni

Come già accennato, HBase mostra il suo maggior successo laddove non è necessario fare nulla, durante l'esecuzione di BulkLoad. Tuttavia, questo vale per la maggior parte dei sistemi e delle persone. Tuttavia, questo strumento è più adatto per archiviare dati in blocco in blocchi di grandi dimensioni, mentre se il processo richiede più richieste di lettura e scrittura concorrenti, vengono utilizzati i comandi Get e Put descritti sopra. Per determinare i parametri ottimali, sono stati effettuati lanci con varie combinazioni di parametri e impostazioni della tabella:

• 10 thread sono stati avviati simultaneamente 3 volte di seguito (chiamiamolo blocco di thread).
• È stata calcolata la media del tempo operativo di tutti i thread in un blocco ed è stato il risultato finale dell'operazione del blocco.
• Tutti i thread hanno funzionato con la stessa tabella.
• Prima di ogni inizio del blocco del filo, è stata eseguita una compattazione importante.
• Ogni blocco eseguiva solo una delle seguenti operazioni:

-Mettere
-Ottenere
—Prendi+Metti

• Ogni blocco ha eseguito 50 iterazioni della sua operazione.
• La dimensione del blocco di un record è 100 byte, 1000 byte o 10000 byte (casuale).
• I blocchi venivano lanciati con diversi numeri di chiavi richieste (una chiave o 10).
• I blocchi sono stati eseguiti con diverse impostazioni della tabella. Parametri modificati:

— BlockCache = attivato o disattivato
— Dimensione blocco = 65 KB o 16 KB
— Partizioni = 1, 5 o 30
— MSLAB = abilitato o disabilitato

Quindi il blocco si presenta così:

UN. La modalità MSLAB è stata attivata/disattivata.
B. È stata creata una tabella per la quale sono stati impostati i seguenti parametri: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
C. La compressione è stata impostata su GZ.
D. Sono stati lanciati 10 thread simultaneamente eseguendo 1/10 di operazioni put/get/get+put in questa tabella con record di 100/1000/10000 byte, eseguendo 50 query di seguito (chiavi casuali).
e. Il punto d è stato ripetuto tre volte.
F. È stata calcolata la media del tempo operativo di tutti i thread.

Sono state testate tutte le possibili combinazioni. È prevedibile che la velocità diminuirà all'aumentare delle dimensioni del record o che la disabilitazione della memorizzazione nella cache causerà un rallentamento. Tuttavia, l'obiettivo era comprendere il grado e il significato dell'influenza di ciascun parametro, quindi i dati raccolti sono stati inseriti nell'input di una funzione di regressione lineare, che consente di valutare il significato utilizzando la statistica t. Di seguito sono riportati i risultati dei blocchi che eseguono operazioni Put. Set completo di combinazioni 2*2*3*2*3 = 144 opzioni + 72 tk. alcuni sono stati fatti due volte. Pertanto, ci sono 216 corse in totale:

Il test è stato effettuato su un mini-cluster composto da 3 DataNode e 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 thread). Versione HBase 1.2.0-cdh5.14.2.

La massima velocità di inserimento di 3.7 secondi è stata ottenuta con modalità MSLAB disattivata, su un tavolo con una partizione, con BlockCache abilitato, BlockSize = 16, record da 100 byte, 10 pezzi per confezione.
La velocità di inserimento più bassa di 82.8 sec è stata ottenuta con la modalità MSLAB abilitata, su una tabella con una partizione, con BlockCache abilitato, BlockSize = 16, record da 10000 byte, 1 ciascuno.

Ora diamo un'occhiata al modello. Notiamo la buona qualità del modello basato su R2, ma è assolutamente chiaro che qui l'estrapolazione è controindicata. Il comportamento effettivo del sistema quando i parametri cambiano non sarà lineare; questo modello è necessario non per fare previsioni, ma per comprendere cosa è successo entro i parametri dati. Ad esempio, qui vediamo dal criterio dello Studente che i parametri BlockSize e BlockCache non contano per l'operazione Put (che generalmente è abbastanza prevedibile):

Ma il fatto che l'aumento del numero di partizioni porti ad una diminuzione delle prestazioni è alquanto inaspettato (abbiamo già visto l'impatto positivo dell'aumento del numero di partizioni con BulkLoad), sebbene comprensibile. In primo luogo, per l'elaborazione è necessario generare richieste a 30 regioni anziché a una, e il volume dei dati non è tale da consentire un guadagno. In secondo luogo, il tempo operativo totale è determinato dalla RS più lenta e, poiché il numero di DataNode è inferiore al numero di RS, alcune regioni hanno località zero. Bene, diamo un'occhiata ai primi cinque:

Ora valutiamo i risultati dell'esecuzione dei blocchi Get:

Il numero di partizioni ha perso significato, il che è probabilmente spiegato dal fatto che i dati sono ben memorizzati nella cache e la cache di lettura è il parametro più significativo (statisticamente). Naturalmente, aumentare il numero di messaggi in una richiesta è anche molto utile per le prestazioni. Migliori risultati:

Bene, infine, diamo un'occhiata al modello del blocco che prima ha eseguito get e poi ha messo:

Tutti i parametri sono significativi qui. E i risultati dei leader:

9. Test di carico

Bene, finalmente lanceremo un carico più o meno decente, ma è sempre più interessante quando hai qualcosa con cui confrontarti. Sul sito web di DataStax, lo sviluppatore chiave di Cassandra, c'è risultati NT di una serie di archivi NoSQL, inclusa la versione HBase 0.98.6-1. Il caricamento è stato effettuato da 40 thread, dimensione dati 100 byte, dischi SSD. Il risultato del test delle operazioni di lettura-modifica-scrittura ha mostrato i seguenti risultati.

Da quanto ho capito la lettura è stata effettuata a blocchi di 100 record e per 16 nodi HBase il test DataStax ha evidenziato una performance di 10mila operazioni al secondo.

È una fortuna che anche il nostro cluster abbia 16 nodi, ma non è molto “fortunato” che ognuno abbia 64 core (thread), mentre nel test DataStax ce ne sono solo 4. D'altro canto loro hanno unità SSD, mentre noi abbiamo HDD o più la nuova versione di HBase e l'utilizzo della CPU durante il carico praticamente non sono aumentati in modo significativo (visivamente del 5-10%). Tuttavia, proviamo a iniziare a utilizzare questa configurazione. Impostazioni predefinite della tabella, la lettura viene eseguita nell'intervallo di chiavi da 0 a 50 milioni in modo casuale (ovvero, essenzialmente nuovo ogni volta). La tabella contiene 50 milioni di record, divisi in 64 partizioni. Le chiavi vengono sottoposte ad hashing utilizzando crc32. Le impostazioni della tabella sono predefinite, MSLAB è abilitato. Avviando 40 thread, ciascun thread legge un set di 100 chiavi casuali e riscrive immediatamente i 100 byte generati su queste chiavi.

Supporto: 16 DataNode e 16 RS (CPU Xeon E5-2680 v4 a 2.40 GHz * 64 thread). Versione HBase 1.2.0-cdh5.14.2.

Il risultato medio è più vicino alle 40mila operazioni al secondo, un valore significativamente migliore rispetto al test DataStax. Tuttavia, a scopo sperimentale, è possibile modificare leggermente le condizioni. È abbastanza improbabile che tutto il lavoro venga eseguito esclusivamente su un tavolo e anche solo su chiavi univoche. Supponiamo che esista un certo set di chiavi “caldo” che genera il carico principale. Proviamo quindi a creare un caricamento con record più grandi (10 KB), anche in batch di 100, in 4 tabelle diverse e limitando il range di chiavi richieste a 50mila. Il grafico sotto mostra l'avvio di 40 thread, ogni thread legge un set di 100 chiavi e riscrive immediatamente 10 KB casuali su queste chiavi.

Supporto: 16 DataNode e 16 RS (CPU Xeon E5-2680 v4 a 2.40 GHz * 64 thread). Versione HBase 1.2.0-cdh5.14.2.

Durante il carico, è stata avviata più volte una compattazione maggiore, come mostrato sopra; senza questa procedura, le prestazioni diminuiranno gradualmente, tuttavia, durante l'esecuzione si verificherà anche un carico aggiuntivo. I prelievi sono causati da vari motivi. A volte i thread finivano di funzionare e si verificava una pausa durante il riavvio, a volte le applicazioni di terze parti creavano un carico sul cluster.

Leggere e scrivere subito è uno degli scenari lavorativi più difficili per HBase. Se si fanno solo piccole richieste put, ad esempio 100 byte, combinandole in pacchi da 10-50mila pezzi, si possono ottenere centinaia di migliaia di operazioni al secondo, e la situazione è simile con le richieste di sola lettura. Vale la pena notare che i risultati sono radicalmente migliori di quelli ottenuti da DataStax, soprattutto grazie alle richieste in blocchi da 50mila.

Supporto: 16 DataNode e 16 RS (CPU Xeon E5-2680 v4 a 2.40 GHz * 64 thread). Versione HBase 1.2.0-cdh5.14.2.

10. risultati

Questo sistema è configurato in modo abbastanza flessibile, ma l'influenza di un gran numero di parametri rimane ancora sconosciuta. Alcuni di essi sono stati testati, ma non sono stati inclusi nel set di test risultante. Ad esempio, gli esperimenti preliminari hanno mostrato un significato insignificante di un parametro come DATA_BLOCK_ENCODING, che codifica le informazioni utilizzando i valori delle celle vicine, il che è comprensibile per i dati generati casualmente. Se utilizzi un numero elevato di oggetti duplicati, il guadagno può essere significativo. In generale, possiamo dire che HBase dà l'impressione di un database abbastanza serio e ben congegnato, che può essere abbastanza produttivo quando si eseguono operazioni con grandi blocchi di dati. Soprattutto se è possibile separare nel tempo i processi di lettura e scrittura.

Se c'è qualcosa secondo te che non viene divulgato abbastanza, sono pronto a raccontartelo in modo più dettagliato. Ti invitiamo a condividere la tua esperienza o discutere se non sei d'accordo con qualcosa.

Fonte: habr.com