HBase fordeler, ulemper og ytelse flaskehals
David Carter
HBase-arkitektur har alltid "Enkelt feilpunkt”-funksjonen, og det er ingen unntakshåndteringsmekanisme knyttet til den.
Her vil vi lære hva som er fordeler og ulemper med HBase og ytelsesflaskehalser:
Ytelsesflaskehalser i HBase
- I et hvilket som helst produksjonsmiljø kjører HBase med en klynge på mer enn 5000 noder, bare Hmaster fungerer som master for alle slaveregionsserverne. Hvis Hmaster går ned, kan den først gjenopprettes etter lang tid. Selv om klienten er i stand til å koble til regionserver. Å ha en annen master er mulig, men bare én vil være aktiv. Det vil ta lang tid å aktivere den andre Hmaster hvis hoved Hmaster går ned. Så Hmaster er en ytelsesflaskehals.
- I HBase kan vi ikke implementere kryssdataoperasjoner og sammenføyningsoperasjoner, selvfølgelig kan vi implementere sammenføyningsoperasjonene ved å bruke MapReduce, som vil ta mye tid å designe og utvikle. Tabellsammenføyningsoperasjoner er vanskelige å utføre i HBase. I noen tilfeller er det umulig å lage joinoperasjoner som er relatert til tabeller som er til stede i HBase
- HBase vil kreve ny design når vi ønsker å migrere data fra RDBMS eksterne kilder til HBase-servere. Imidlertid tar denne prosessen mye tid.
- HBase er veldig vanskelig å spørre på. Vi må kanskje integrere HBase med noen SQL lag som Apache phoenix hvor vi kan skrive spørringer for å trigge dataene i HBase. Det er veldig bra å ha Apache Phoenix på toppen av HBase.
- En annen ulempe med HBase er at vi ikke kan ha mer enn én indeksering i tabellen, bare radnøkkelkolonne fungerer som en primærnøkkel. Så ytelsen ville være treg når vi ønsket å søke på mer enn ett felt eller annet enn radtasten. Dette problemet kan vi overvinne ved å skrive MapReduce-kode, integrere med Apache SOLR og med Apache Phoenix.
- Langsomme forbedringer i sikkerheten for de forskjellige brukerne for å få tilgang til dataene fra HBase.
- HBase støtter ikke delvise nøkler helt
- HBase tillater bare én standard sortering per tabell
- Det er veldig vanskelig å lagre store binære filer i HBase
- Lagringen av HBase vil begrense sanntidsspørringer og sortering
- Nøkkeloppslag og områdeoppslag når det gjelder søk i tabellinnhold ved hjelp av nøkkelverdier, det vil begrense søk som utfører i sanntid
- Standardindeksering er ikke til stede i HBase. Programmerere må definere flere linjer med kode eller skript for å utføre indekseringsfunksjonalitet i HBase
- Dyrt i forhold til maskinvarekrav og tildeling av minneblokker.
- Flere servere bør installeres for distribuerte klyngemiljøer (som hver server for NameNode, DataNodes, Dyrepasser, og regionservere)
- Ytelsesmessig krever det maskiner med høyt minne
- Kostnads- og vedlikeholdsmessig er det også høyere
Fordeler med HBase
Her vil vi lære hva som er fordelene med HBase:
- Kan lagre store datasett på toppen av HDFS-fillagring og vil samle og analysere milliarder av rader i HBase-tabellene
- I HBase kan databasen deles
- Operasjoner som datalesing og prosessering vil ta kort tid sammenlignet med tradisjonelle relasjonsmodeller
- Tilfeldige lese- og skriveoperasjoner
- For online analytiske operasjoner brukes HBase mye.
- For eksempel: I bankapplikasjoner som sanntidsdataoppdateringer i minibanker, kan HBase brukes.
Ulemper med HBase
Her er de viktige ulempene/begrensningene til HBase:
- Vi kan ikke helt forvente å bruke HBase som erstatning for tradisjonelle modeller. Noen av de tradisjonelle modellens funksjoner kan ikke støttes av HBase
- HBase kan ikke utføre funksjoner som SQL. Den støtter ikke SQL-struktur, så den inneholder ingen spørringsoptimerer
- HBase er CPU- og minneintensiv med stor sekvensiell inngangs- eller utgangstilgang, mens som Map Reduce-jobber primært er inn- eller utdata bundet med fast minne. HBase integrert med Map-reduce-jobber vil resultere i uforutsigbare ventetider
- HBase integrert med gris og Hive jobber resulterer i noen tidshukommelsesproblemer på klyngen
- I et delt klyngemiljø krever oppsettet færre oppgavespor per node for å allokere for HBase CPU-krav
