I dagens inlägg ska vi diskutera om HBase Architecture. Låt oss förstöra våra grunder i HBase innan vi fördjupar oss i HBase-arkitekturen.
HBase - Grunderna:
HBase är en öppen källkod, NoSQL, distribuerad, icke-relationell, versionerad, flerdimensionell, kolumnorienterad butik som har modellerats efter Google BigTable som körs ovanpå HDFS. '' NoSQL 'är en bred term som betyder att databasen inte är en RDBMS som stöder SQL som dess primära åtkomstspråk. Men det finns många typer av NoSQL-databaser och Berkeley DB är ett bra exempel på en lokal NoSQL-databas, medan HBase är väldigt mycket en distribuerad databas.
HBase erbjuder alla funktioner i Google BigTable. Det började som ett projekt av Powerset för att bearbeta massiva mängder data för naturligt språk sökning. Det utvecklades som en del av Apache's Hadoop-projekt och körs ovanpå HDFS (Hadoop Distribuerat filsystem). Det ger feltoleranta sätt att lagra stora mängder gles data. HBase är verkligen mer en 'Data Store' än 'Data Base' eftersom den saknar många av de funktioner som finns tillgängliga i RDBMS, såsom typade kolumner, sekundära index, utlösare och avancerade frågespråk etc.
I kolumnorienterade databaser lagras datatabellen som sektioner av datakolumner snarare än som datarader. Datamodellen för kolumnorienterad databas består av tabellnamn, radnyckel, kolumnfamilj, kolumner, tidsstämpel. När du skapar tabeller i HBase identifieras raderna unikt med hjälp av radknappar och tidsstämpel. I denna datamodell är kolumnfamiljen statisk medan kolumnerna är dynamiska. Låt oss nu titta på HBase Architecture.
funktion överbelastning i c ++ exempel
När ska jag gå till HBase?
HBase är bara ett bra alternativ när det finns hundratals miljoner eller miljarder rader. HBase kan också användas på platser när man överväger att flytta från en RDBMS till HBase som en fullständig redesign i motsats till en port. Med andra ord är HBase inte optimerad för klassiska transaktionsapplikationer eller ens relationsanalyser. Det är inte heller en komplett ersättning för HDFS när du gör stora batch MapReduce. Varför ska du sedan gå till HBase ?? Om din applikation har ett variabelt schema där varje rad är något annorlunda bör du titta på HBase.
HBase Architecture:
Följande bild förklarar tydligt HBase Architecture.
I HBase finns det tre huvudkomponenter: Mästare, regionserver och djurhållare . De andra komponenterna är Memstore, HFile och WAL.
Eftersom HBase körs ovanpå HDFS använder den Master-Slave-arkitekturen där HMaster kommer att vara huvudnoden och Region Servers är slavnoder. När klienten skickar en skrivförfrågan får HMaster den begäran och vidarebefordrar den till respektive Region Server.
använder skannerklass i Java
Regionserver:
Det är ett system som fungerar som en datanod. När Region Server (RS) tar emot skrivförfrågan, riktar den begäran till specifik region. Varje region lagrar uppsättning rader. Raddata kan separeras i flera kolumner (CF). Data för särskild CF lagras i HStore som består av Memstore och en uppsättning HFiles.
Vad gör Memstore?
Memstore håller reda på alla loggar för läs- och skrivoperationer som har utförts inom den specifika regionservern. Från detta kan vi säga att det fungerar som en namnknut i Hadoop. Memstore är en lagring i minnet, därför använder Memstore lagring i minnet för varje datanod för att lagra loggarna. När vissa trösklar uppfylls, spolas Memstore-data in i HFile.
Det viktigaste syftet för att använda Memstore är behovet av att lagra data på DFS beställt efter radnyckel. Eftersom HDFS är designad för sekventiell läsning / skrivning, utan att filändringar är tillåtna, kan HBase inte effektivt skriva data till hårddisken eftersom den tas emot: de skrivna uppgifterna kommer inte att sorteras (när ingången inte är sorterad) vilket innebär att den inte är optimerad för framtiden hämtning. För att lösa detta problem fick HBase-buffertar senast data i minnet (i Memstore), 'sorterar' det innan de spolas och skriver sedan till HDFS med snabba sekventiella skrivningar. Därför innehåller HFile en lista med sorterade rader.
Varje gång Memstore spola händer skapas en HFile för varje CF och frekventa spolningar kan skapa massor av HFiles. Eftersom HBase kommer att behöva titta på många HFiles under behandlingen kan läshastigheten drabbas. För att förhindra öppning av för många HFiles och undvika försämring av läsprestanda används HFiles komprimeringsprocess. HBase kommer regelbundet (när vissa konfigurerbara trösklar uppfylls) att komprimera flera mindre HFiles till en stor. Det är uppenbart att ju fler filer som skapas av Memstore spolas, desto mer arbete (extra belastning) för systemet. Tillagt till det, medan komprimeringsprocessen vanligtvis utförs parallellt med att betjäna andra förfrågningar och när HBase inte kan hålla jämna steg med komprimering av HFiles (ja, det finns konfigurerade trösklar för det också), kommer det att blockera skrivningar på RS igen. Som vi diskuterade ovan är detta mycket oönskat.
Vi kan inte vara säkra på att informationen kommer att vara beständig hela tiden i Memstore. Antag att en viss datanod är nere. Då går informationen som finns i datanodens minne förlorad.
För att övervinna detta problem, när förfrågan kommer från befälhavaren, skrev den också till WAL. WAL är inget annat än Skriv framåt loggar som finns på HDFS, en permanent lagring. Nu kan vi se till att även om datanoden är nere kommer inte data att gå förlorade d.v.s. vi har en kopia av alla åtgärder som du ska göra i WAL. När datanoden är uppe kommer den att utföra alla aktiviteter igen. När operationen är klar spolas allt ut från Memstore och WAL och skrivs i HFile för att säkerställa att minnet inte tar slut.
Låt oss ta ett enkelt exempel på att jag vill lägga till rad 10 då skrivförfrågan kommer in, det står att det ger alla metadata till Memstore och WAL. När den specifika raden har skrivits in i HFile spolas allt i Memstore och WAL ut.
Zoo Keeper:
HBase levereras integrerad med djurhållaren. När jag startar HBase startas också djurhållarinstans. Anledningen är att djurhållaren hjälper oss att hålla reda på alla regionsservrar som finns för HBase. Zoo djurhållare håller reda på hur många regionservrar som finns, vilka regionsservrar som håller från vilken datanod till vilken datanod. Det håller reda på mindre datamängder där Hadoop missar. Det minskar omkostnaderna ovanpå Hadoop som håller reda på de flesta av dina metadata. Därför får HMaster information om regionservrar genom att faktiskt kontakta djurhållaren.
Har du en fråga till oss? Nämn dem i kommentarfältet så återkommer vi till dig.
avslutar ett program i Java
Relaterade inlägg: