HBase Fördelar, Nackdelar & Prestanda Flaskhals

Vad är HBase?

HBase är en distribuerad, kolumnorienterad NoSQL-databas med öppen källkod som körs ovanpå Hadoop Distributed File System (HDFS). Modellerad efter Google Bigtable lagrar data i tabeller gjorda av rader och kolumnfamiljer, och är utformad för glesa datamängder som kan växa till miljarder rader och miljontals kolumner.

Till skillnad från en relationsdatabas använder HBase inte ett fast schema eller erbjuder en frågeoptimerare. Istället adresseras varje värde av en radnyckel, kolumnfamilj, kolumnkvalificerare och tidsstämpel, vilket gör slumpmässiga realtidsläsningar och skrivningar snabba även i stor skala.

Ett HBase-kluster bygger på ett fåtal kärnkomponenter. HMaster koordinerar klustret och tilldelar regioner, regionservrarna lagrar och hanterar själva data, och Apache ZooKeeper tracvisar vilka servrar som är aktiva och hjälper till med redundansväxling. Eftersom det sitter inom Hadoop-ekosystemet fungerar HBase med verktyg som MapReduce, Bikupaoch Pig för batchanalys. För en djupare titt på interna funktioner, se HBase-arkitektur.

Fördelar med HBase

Här är de viktigaste fördelarna med att använda HBase:

• Lagrar mycket stora datamängder ovanpå HDFS och kan aggregera och analysera miljarder rader som finns i HBase-tabeller.
• Databasen kan delas mellan många klienter i en distribuerad miljö.
• Dataläsning och bearbetning tar kortare tid jämfört med traditionella relationsmodeller.
• Stöder snabba slumpmässiga läs- och skrivoperationer.
• HBase används i stor utsträckning för analytiska operationer online.
• I bankapplikationer, såsom saldouppdateringar i realtid för bankomater, hanterar HBase högvolymsläsningar och skrivningar tillförlitligt.

Nackdelar med HBase

Här är de viktiga begränsningarna med HBase:

• HBase är inte en fullständig ersättning för traditionella relationsmodeller; vissa relationsfunktioner stöds inte.
• HBase kan inte utföra funktioner som SQLDen stöder inte SQL-struktur, så den har ingen frågeoptimerare.
• HBase är CPU- och minnesintensiv med stor sekventiell in- eller utmatningsåtkomst, medan MapReduce-jobb mestadels är I/O-bundna med fast minne. Integrering av HBase med MapReduce-jobb kan ge oförutsägbara latenser.
• Att integrera HBase med Pig- och Hive-jobb kan ibland orsaka minnesproblem i klustret.
• I en delad klustermiljö kräver installationen färre aktivitetsplatser per nod att allokera för HBase CPU-krav.

Prestanda flaskhalsar i HBase

HBase levererar skalbarhet, men flera arkitektoniska val skapar prestandaflaskhalsar som team bör planera kring:

I en stor produktionsmiljö kan ett HBase-kluster köras över tusentals noder, men endast HMaster fungerar som master för alla slav-regionservrar. Om HMaster går ner kan återställningen ta lång tid, även om klienter fortfarande kan nå en regionserver. Det är möjligt att köra en standby-master, men bara en HMaster är aktiv åt gången, och det är inte omedelbart att befordra den andra HMastern efter ett fel. Som ett resultat är HMastern en erkänd prestandaflaskhals.

HBase stöder inte korstabell- eller kopplingsoperationer direkt. Kopplingar kan implementeras med MapReduce, men det lägger till betydande design- och utvecklingstid, och vissa tabellkopplingar är i praktiken opraktiska i HBase.

Att migrera data från ett externt RDBMS till HBase kräver vanligtvis en ny schemadesign, och den migreringsprocessen kan ta lång tid. Frågor är också svåra: många team lägger till ett SQL-lager som Apache Phoenix ovanpå HBase så att de kan läsa och skriva data med bekanta frågor.

HBase stöder bara ett enda index – radnyckeln fungerar som primärnyckel – så sökningar på alla andra fält är långsamma. Team arbetar runt detta genom att skriva MapReduce-kod eller genom att integrera Apache. Solr och Apache Phoenix för sekundär indexering.

• Säkerhetskontrollerna för dataåtkomst för flera användare har bara förbättrats långsamt.
• HBase har inte fullt stöd för partiella nycklar.
• Endast en standardsorteringsordning är tillåten per tabell.
• Att lagra stora binära filer i HBase är svårt.
• HBase-lagring begränsar frågor och sortering i realtid.
• Nyckelsökningar och intervallsökningar av tabellinnehåll kan begränsa frågor som måste köras i realtid.
• Standardindexering saknas; programmerare måste skriva extra kod eller skript för att lägga till indexering.
• Hårdvarukrav och minnesblockallokering gör HBase dyr att köra.
• Ett distribuerat kluster behöver många servrar – separata noder för NameNode-, DataNodes-, ZooKeeper- och Region-servrarna.
• Maskiner med högt minne krävs för bra prestanda.
• Den totala kostnaden och underhållet är högre än för enklare alternativ.

HBase kontra RDBMS

Artikeln jämför upprepade gånger HBase med traditionella relationsdatabaser. Tabellen nedan sammanfattar de viktigaste skillnaderna så att du kan avgöra vilken modell som passar en arbetsbelastning:

Kort sagt, HBase gynnar skalbarhet och realtidsåtkomst, medan en RDBMS gynnar omfattande frågor och stark konsekvens. Välj HBase när datavolym och skrivflöde växer över vad en relationsdatabas bekvämt kan hantera.

Vanliga frågor