Vantaggi, svantaggi e collo di bottiglia delle prestazioni di HBase

Cos'è HBase?

HBase è un database NoSQL open-source, distribuito e orientato alle colonne che funziona su Hadoop Distributed File System (HDFS). Modellato su Google Bigtable memorizza i dati in tabelle composte da righe e famiglie di colonne ed è progettato per set di dati sparsi che possono raggiungere miliardi di righe e milioni di colonne.

A differenza di un database relazionale, HBase non utilizza uno schema fisso né offre un ottimizzatore di query. Al contrario, ogni valore viene identificato da una chiave di riga, una famiglia di colonne, un qualificatore di colonna e un timestamp, il che rende veloci le operazioni di lettura e scrittura casuali in tempo reale anche su larga scala.

Un cluster HBase si basa su alcuni componenti principali. L'HMaster coordina il cluster e assegna le regioni, i Region Server memorizzano e forniscono i dati effettivi e Apache Custode dello zoo tracindica quali server sono attivi e aiuta con il failover. Poiché si trova all'interno dell'ecosistema Hadoop, HBase funziona con strumenti come MapReduce, Alvearee Pig per l'analisi batch. Per uno sguardo più approfondito agli aspetti interni, vedere il Architettura HBase.

Vantaggi di HBase

Ecco i principali vantaggi derivanti dall'utilizzo di HBase:

• Consente di archiviare set di dati di grandi dimensioni su HDFS e di aggregare e analizzare miliardi di righe contenute nelle tabelle HBase.
• In un ambiente distribuito, il database può essere condiviso tra più client.
• La lettura e l'elaborazione dei dati richiedono meno tempo rispetto ai modelli relazionali tradizionali.
• Supporta operazioni di lettura e scrittura casuali veloci.
• HBase è ampiamente utilizzato per operazioni di analisi online.
• Nelle applicazioni bancarie, come ad esempio gli aggiornamenti in tempo reale del saldo per gli sportelli automatici, HBase gestisce in modo affidabile volumi elevati di operazioni di lettura e scrittura.

Svantaggi di HBase

Ecco i principali limiti di HBase:

• HBase non sostituisce completamente i modelli relazionali tradizionali; alcune funzionalità relazionali non sono supportate.
• HBase non può eseguire funzioni come SQLNon supporta la struttura SQL, quindi non dispone di un ottimizzatore di query.
• HBase richiede un elevato utilizzo di CPU e memoria, con un accesso sequenziale di grandi dimensioni a input e output, mentre i job MapReduce sono per lo più limitati dall'I/O e richiedono una memoria fissa. L'integrazione di HBase con i job MapReduce può produrre latenze imprevedibili.
• L'integrazione di HBase con Pig e i job di Hive può talvolta causare problemi di memoria sul cluster.
• In un ambiente cluster condiviso, la configurazione richiede un minor numero di slot di attività per nodo da allocare per i requisiti della CPU di HBase.

Colli di bottiglia delle prestazioni in HBase

HBase offre scalabilità, ma diverse scelte architetturali creano colli di bottiglia nelle prestazioni, di cui i team dovrebbero tenere conto nella pianificazione:

In un ambiente di produzione di grandi dimensioni, un cluster HBase può estendersi su migliaia di nodi, ma solo l'HMaster funge da master per tutti i Region Server slave. Se l'HMaster si arresta, il ripristino può richiedere molto tempo, anche se i client potrebbero comunque riuscire a raggiungere un Region Server. È possibile utilizzare un master di standby, ma solo un HMaster alla volta può essere attivo e la promozione del secondo HMaster dopo un guasto non è immediata. Di conseguenza, l'HMaster è riconosciuto come un collo di bottiglia per le prestazioni.

HBase non supporta direttamente operazioni di join tra tabelle. I join possono essere implementati con MapReduce, ma ciò comporta un notevole aumento dei tempi di progettazione e sviluppo, e alcuni tipi di join tra tabelle risultano di fatto impraticabili in HBase.

La migrazione dei dati da un RDBMS esterno a HBase di solito richiede una nuova progettazione dello schema e questo processo di migrazione può richiedere molto tempo. Anche l'interrogazione è difficile: molti team aggiungono un livello SQL come Apache Phoenix sopra HBase in modo da poter leggere e scrivere dati con domande familiari.

HBase supporta un solo indice: la chiave di riga funge da chiave primaria, quindi le ricerche su qualsiasi altro campo sono lente. I team aggirano questo problema scrivendo codice MapReduce o integrando Apache. Solr e Apache Phoenix per l'indicizzazione secondaria.

• I controlli di sicurezza per l'accesso multiutente ai dati sono migliorati solo lentamente.
• HBase non supporta completamente le chiavi parziali.
• Per ogni tabella è consentito un solo ordinamento predefinito.
• Archiviare file binari di grandi dimensioni in HBase è difficile.
• L'archiviazione di HBase limita le query e l'ordinamento in tempo reale.
• Le ricerche per chiave e per intervallo sul contenuto delle tabelle possono limitare le query che devono essere eseguite in tempo reale.
• L'indicizzazione predefinita è assente; i programmatori devono scrivere codice o script aggiuntivi per aggiungerla.
• I requisiti hardware e l'allocazione dei blocchi di memoria rendono HBase un'operazione costosa.
• Un cluster distribuito necessita di molti server: nodi separati per NameNode, DataNode, ZooKeeper e Region Server.
• Per ottenere buone prestazioni sono necessarie macchine con molta memoria.
• I costi complessivi e la manutenzione sono superiori rispetto ad alternative più semplici.

HBase contro RDBMS

L'articolo mette ripetutamente a confronto HBase con i database relazionali tradizionali. La tabella seguente riassume le principali differenze, in modo da poter decidere quale modello si adatta meglio al proprio carico di lavoro:

In sintesi, HBase privilegia la scalabilità e l'accesso in tempo reale, mentre un RDBMS privilegia le query avanzate e la coerenza forte. Scegli HBase quando il volume dei dati e la velocità di scrittura superano le capacità di un database relazionale.

DOMANDE FREQUENTI