HBase fordeler, ulemper og ytelse flaskehals

Hva er HBase?

HBase er en åpen kildekode, distribuert, kolonneorientert NoSQL-database som kjører oppå Hadoop Distributed File System (HDFS). Modellert på Google Bigtable lagrer data i tabeller laget av rader og kolonnefamilier, og den er designet for sparsomme datasett som kan vokse til milliarder av rader og millioner av kolonner.

I motsetning til en relasjonsdatabase bruker ikke HBase et fast skjema eller tilbyr en spørreoptimalisering. I stedet adresseres hver verdi av en radnøkkel, kolonnefamilie, kolonnekvalifikator og tidsstempel, noe som gjør tilfeldige sanntidslesinger og -skrivinger raske selv i massiv skala.

En HBase-klynge er avhengig av noen få kjernekomponenter. HMaster koordinerer klyngen og tildeler regioner, regionserverne lagrer og betjener de faktiske dataene, og Apache Dyrepasser tracfinner ut hvilke servere som er aktive og hjelper med failover. Fordi det ligger i Hadoop-økosystemet, fungerer HBase med verktøy som MapReduce, Hiveog Pig for batchanalyse. For en dypere titt på de interne detaljene, se HBase-arkitektur.

Fordeler med HBase

Her er de viktigste fordelene med å bruke HBase:

• Lagrer svært store datasett oppå HDFS og kan aggregere og analysere milliarder av rader som finnes i HBase-tabeller.
• Databasen kan deles på tvers av mange klienter i et distribuert miljø.
• Datalesing og -behandling tar kortere tid sammenlignet med tradisjonelle relasjonsmodeller.
• Støtter raske tilfeldige lese- og skriveoperasjoner.
• HBase brukes mye til analytiske operasjoner på nett.
• I bankapplikasjoner, som for eksempel sanntidssaldooppdateringer for minibanker, håndterer HBase høyvolums lesing og skriving pålitelig.

Ulemper med HBase

Her er de viktigste begrensningene til HBase:

• HBase er ikke en fullstendig erstatning for tradisjonelle relasjonsmodeller; noen relasjonsfunksjoner støttes ikke.
• HBase kan ikke utføre funksjoner som SQLDen støtter ikke SQL-struktur, så den har ingen spørreoptimalisering.
• HBase er CPU- og minneintensiv med stor sekvensiell input- eller output-tilgang, mens MapReduce-jobber stort sett er I/O-bundet med fast minne. Integrering av HBase med MapReduce-jobber kan gi uforutsigbare latenser.
• Integrering av HBase med Pig- og Hive-jobber kan noen ganger føre til minneproblemer i klyngen.
• I et delt klyngemiljø krever oppsettet færre oppgaveplasser per node å allokere for HBase CPU-krav.

Ytelsesflaskehalser i HBase

HBase leverer skalering, men flere arkitektoniske valg skaper ytelsesflaskehalser som team bør planlegge rundt:

I et stort produksjonsmiljø kan en HBase-klynge kjøre på tvers av tusenvis av noder, men bare HMaster fungerer som master for alle de underordnede Region-serverne. Hvis HMaster går ned, kan gjenoppretting ta lang tid, selv om klienter fortsatt kan nå en Region-server. Det er mulig å kjøre en standby-master, men bare én HMaster er aktiv om gangen, og det er ikke umiddelbart å forfremme den andre HMasteren etter en feil. Som et resultat er HMasteren en anerkjent ytelsesflaskehals.

HBase støtter ikke krysstabell- eller koblingsoperasjoner direkte. Sammenkoblinger kan implementeres med MapReduce, men det legger til betydelig design- og utviklingstid, og noen tabellkoblinger er i praksis upraktiske i HBase.

Migrering av data fra et eksternt RDBMS til HBase krever vanligvis et nytt skjemadesign, og den migreringsprosessen kan ta lang tid. Spørringer er også vanskelige: mange team legger til et SQL-lag, for eksempel Apache Phoenix, oppå HBase, slik at de kan lese og skrive data med kjente spørsmål.

HBase støtter bare én enkelt indeks – radnøkkelen fungerer som primærnøkkel – så søk på andre felt er trege. Team omgår dette ved å skrive MapReduce-kode eller ved å integrere Apache. Solr og Apache Phoenix for sekundær indeksering.

• Sikkerhetskontrollene for datatilgang for flere brukere har bare blitt forbedret sakte.
• HBase støtter ikke delvise nøkler fullt ut.
• Bare én standard sorteringsrekkefølge er tillatt per tabell.
• Det er vanskelig å lagre store binære filer i HBase.
• HBase-lagring begrenser sanntidsspørringer og sortering.
• Nøkkeloppslag og områdeoppslag i tabellinnhold kan begrense spørringer som må kjøres i sanntid.
• Standardindeksering er fraværende; programmerere må skrive ekstra kode eller skript for å legge til indeksering.
• Maskinvarekrav og minneblokkallokering gjør HBase dyr å kjøre.
• En distribuert klynge trenger mange servere – separate noder for NameNode-, DataNodes-, ZooKeeper- og Region-serverne.
• Maskiner med høyt minne er nødvendig for god ytelse.
• Totale kostnader og vedlikehold er høyere enn enklere alternativer.

HBase vs. RDBMS

Artikkelen stiller gjentatte ganger HBase opp mot tradisjonelle relasjonsdatabaser. Tabellen nedenfor oppsummerer de viktigste forskjellene, slik at du kan bestemme hvilken modell som passer til en arbeidsmengde:

Kort sagt, HBase favoriserer skalering og sanntidstilgang, mens en RDBMS favoriserer omfattende spørringer og sterk konsistens. Velg HBase når datavolum og skrivegjennomstrømning vokser for mye av det en relasjonsdatabase komfortabelt kan håndtere.

Spørsmål og svar