HBase-voordelen, nadelen en prestatieknelpunten
HBase-architectuur heeft altijd “Eén punt van mislukking”-functie, en er is geen mechanisme voor de afhandeling van uitzonderingen aan gekoppeld.
Hier zullen we leren wat de voor- en nadelen zijn van HBase en prestatieknelpunten:
Prestatieknelpunten in HBase
- In elke productieomgeving draait HBase met een cluster van meer dan 5000 nodes, alleen Hmaster fungeert als master voor alle slave Region servers. Als Hmaster uitvalt, kan het pas na lange tijd worden hersteld. Zelfs als de client verbinding kan maken met de Region server. Een andere master is mogelijk, maar er zal er maar één actief zijn. Het zal lang duren om de tweede Hmaster te activeren als de hoofd-Hmaster uitvalt. Hmaster is dus een prestatiebottleneck.
- In HBase kunnen we geen cross-data-bewerkingen en samenvoegingsbewerkingen implementeren. Uiteraard kunnen we de samenvoegingsbewerkingen wel implementeren met behulp van KaartVerminderen, wat veel tijd zou kosten om te ontwerpen en ontwikkelen. Tabellen join-bewerkingen zijn moeilijk uit te voeren in HBase. In sommige use cases is het onmogelijk om join-bewerkingen te maken die gerelateerd zijn aan tabellen die aanwezig zijn in HBase
- HBase zou een nieuw ontwerp vereisen als we gegevens van externe RDBMS-bronnen naar HBase-servers willen migreren. Dit proces kost echter veel tijd.
- HBase is erg moeilijk voor het uitvoeren van query's. Mogelijk moeten we HBase met sommige integreren SQL lagen zoals apache phoenix waar we queries kunnen schrijven om de gegevens in de HBase te activeren. Het is echt goed om Apache Phoenix bovenop HBase te hebben.
- Een ander nadeel van HBase is dat we niet meer dan één indexering in de tabel kunnen hebben, alleen de rijsleutelkolom fungeert als primaire sleutel. De prestatie zou dus traag zijn als we op meer dan één veld of op een andere dan de rijtoets wilden zoeken. Dit probleem kunnen we oplossen door MapReduce-code te schrijven, te integreren met Apache SOLR en met Apache Phoenix.
- Langzame verbeteringen in de beveiliging voor de verschillende gebruikers om toegang te krijgen tot de gegevens uit HBase.
- HBase ondersteunt gedeeltelijke sleutels niet volledig
- HBase staat slechts één standaardsortering per tabel toe
- Het is erg moeilijk om grote hoeveelheden binaire bestanden in HBase op te slaan
- De opslag van HBase beperkt real-time queries en sortering
- Sleutelopzoeken en bereikopzoeken in termen van het doorzoeken van tabelinhoud met behulp van sleutelwaarden, zal het de query's beperken die in realtime worden uitgevoerd
- Standaardindexering is niet aanwezig in HBase. Programmeurs moeten verschillende coderegels of scripts definiëren om de indexeringsfunctionaliteit in HBase uit te voeren
- Duur in termen van hardwarevereisten en toewijzingen van geheugenblokken.
- Er moeten meer servers worden geïnstalleerd voor gedistribueerde clusteromgevingen (zoals elke server voor NameNode, DataNodes, Dierentuinmedewerkeren regioservers)
- Qua prestaties zijn er machines met veel geheugen nodig
- Qua kosten en onderhoud is het ook hoger
Voordelen van HBase
Hier zullen we leren wat de voor- en voordelen zijn van HBase:
- Kan grote datasets opslaan bovenop HDFS-bestandsopslag en zal miljarden rijen in de HBase-tabellen aggregeren en analyseren
- In HBase kan de database worden gedeeld
- OperaZaken als het lezen en verwerken van gegevens zullen weinig tijd vergen in vergelijking met traditionele relationele modellen
- Willekeurige lees- en schrijfbewerkingen
- HBase wordt veelvuldig gebruikt voor online analytische bewerkingen.
- Bijvoorbeeld: In banktoepassingen zoals real-time data-updates in geldautomaten kan HBase worden gebruikt.
Nadelen van HBase
Hier zijn de belangrijke nadelen/beperkingen van HBase:
- We kunnen niet verwachten dat we HBase volledig zullen gebruiken als vervanging voor traditionele modellen. Sommige van de traditionele modelfuncties kunnen niet door HBase worden ondersteund
- HBase kan geen functies zoals SQL uitvoeren. Het ondersteunt geen SQL-structuur en bevat dus geen query-optimalisatie
- HBase is CPU- en geheugenintensief met grote sequentiële invoer- of uitvoertoegang, terwijl Map Reduce-taken voornamelijk invoer- of uitvoergebonden zijn met vast geheugen. HBase geïntegreerd met Map-reduce-taken zal resulteren in onvoorspelbare latenties
- HBase geïntegreerd met varkens- en Bijenkorf banen resulteren in wat tijdgeheugenproblemen op cluster
- In een gedeelde clusteromgeving zijn er voor de opstelling minder taakslots per knooppunt nodig om toe te wijzen aan HBase CPU-vereisten