HBase fordele, ulemper og ydeevne flaskehals

Hvad er HBase?

HBase er en open source, distribueret, kolonneorienteret NoSQL-database, der kører oven på Hadoop Distributed File System (HDFS). Modelleret på Google Bigtable lagrer data i tabeller lavet af rækker og kolonnefamilier, og det er designet til sparsomme datasæt, der kan vokse til milliarder af rækker og millioner af kolonner.

I modsætning til en relationsdatabase bruger HBase ikke et fast skema eller tilbyder en forespørgselsoptimerer. I stedet adresseres hver værdi af en rækkenøgle, kolonnefamilie, kolonnekvalifikator og tidsstempel, hvilket gør tilfældige realtidslæsninger og -skrivninger hurtige, selv i massiv skala.

En HBase-klynge er afhængig af et par kernekomponenter. HMaster koordinerer klyngen og tildeler regioner, regionserverne gemmer og håndterer de faktiske data, og Apache Dyrepasser tracfinder ud af, hvilke servere der er aktive, og hjælper med failover. Fordi HBase sidder i Hadoop-økosystemet, fungerer det med værktøjer som f.eks. KortReducer, Hiveog Pig til batchanalyse. For et dybere kig på de interne elementer, se HBase-arkitektur.

Fordele ved HBase

Her er de vigtigste fordele ved at bruge HBase:

• Gemmer meget store datasæt oven på HDFS og kan aggregere og analysere milliarder af rækker, der findes i HBase-tabeller.
• Databasen kan deles på tværs af mange klienter i et distribueret miljø.
• Datalæsning og -behandling tager kortere tid sammenlignet med traditionelle relationelle modeller.
• Understøtter hurtige tilfældige læse- og skriveoperationer.
• HBase bruges i vid udstrækning til online analytiske operationer.
• I bankapplikationer, såsom opdateringer af saldo i realtid for hæveautomater, håndterer HBase pålideligt store mængder læsning og skrivning.

Ulemper ved HBase

Her er de vigtige begrænsninger ved HBase:

• HBase er ikke en komplet erstatning for traditionelle relationelle modeller; visse relationelle funktioner understøttes ikke.
• HBase kan ikke udføre funktioner som f.eks. SQLDen understøtter ikke SQL-struktur, så den har ingen forespørgselsoptimering.
• HBase er CPU- og hukommelseskrævende med stor sekventiel input- eller outputadgang, hvorimod MapReduce-job for det meste er I/O-bundet med fast hukommelse. Integration af HBase med MapReduce-job kan producere uforudsigelige latenser.
• Integration af HBase med Pig- og Hive-job kan nogle gange forårsage hukommelsesproblemer i klyngen.
• I et delt klyngemiljø kræver opsætningen færre opgavepladser pr. node at allokere til HBase CPU-krav.

Ydeevne flaskehalse i HBase

HBase leverer skalering, men flere arkitektoniske valg skaber flaskehalse i ydeevnen, som teams bør planlægge omkring:

I et stort produktionsmiljø kan en HBase-klynge køre på tværs af tusindvis af noder, men kun HMaster fungerer som master for alle de underordnede Region Servers. Hvis HMaster går ned, kan gendannelse tage lang tid, selvom klienter stadig kan nå en Region Server. Det er muligt at køre en standby master, men kun én HMaster er aktiv ad gangen, og det er ikke øjeblikkeligt at promovere den anden HMaster efter en fejl. Som et resultat er HMaster en anerkendt flaskehals i ydeevnen.

HBase understøtter ikke direkte krydstabeller eller join-operationer. Joins kan implementeres med MapReduce, men det tilføjer betydelig design- og udviklingstid, og nogle tabeljoins er reelt upraktiske i HBase.

Migrering af data fra et eksternt RDBMS til HBase kræver normalt et nyt skemadesign, og den migreringsproces kan tage lang tid. Forespørgsler er også vanskelige: mange teams tilføjer et SQL-lag, f.eks. Apache Phoenix, oven på HBase, så de kan læse og skrive data med velkendte spørgsmål.

HBase understøtter kun et enkelt indeks – rækkenøglen fungerer som primærnøgle – så søgninger på alle andre felter er langsomme. Teams omgår dette ved at skrive MapReduce-kode eller ved at integrere Apache. Solr og Apache Phoenix til sekundær indeksering.

• Sikkerhedskontrollerne for dataadgang for flere brugere er kun langsomt blevet forbedret.
• HBase understøtter ikke fuldt ud delvise nøgler.
• Kun én standard sorteringsrækkefølge er tilladt pr. tabel.
• Det er vanskeligt at gemme store binære filer i HBase.
• HBase-lagring begrænser forespørgsler og sortering i realtid.
• Nøgleopslag og områdeopslag i tabelindhold kan begrænse forespørgsler, der skal køre i realtid.
• Standardindeksering er fraværende; programmører skal skrive ekstra kode eller scripts for at tilføje indeksering.
• Hardwarekrav og hukommelsesblokallokering gør HBase dyr at køre.
• En distribueret klynge kræver mange servere – separate noder til NameNode-, DataNodes-, ZooKeeper- og Region-serverne.
• Maskiner med høj hukommelse er nødvendige for god ydeevne.
• De samlede omkostninger og vedligeholdelse er højere end ved enklere alternativer.

HBase vs. RDBMS

Artiklen sætter gentagne gange HBase i kontrast til traditionelle relationelle databaser. Tabellen nedenfor opsummerer de vigtigste forskelle, så du kan beslutte, hvilken model der passer til en arbejdsbyrde:

Kort sagt, HBase foretrækker skalering og adgang i realtid, mens en RDBMS foretrækker omfattende forespørgsler og stærk konsistens. Vælg HBase, når datamængden og skrivegennemstrømningen vokser for meget, hvad en relationsdatabase komfortabelt kan håndtere.

Ofte Stillede Spørgsmål