Lad os i dagens indlæg diskutere om HBase-arkitekturen. Lad os børste vores grundlæggende HBase op, inden vi dyber dybere ned i HBase-arkitekturen.
HBase - Grundlæggende:
HBase er en open source, NoSQL, distribueret, ikke-relationel, versioneret, flerdimensionel, kolonneorienteret butik, der er modelleret efter Google BigTable, der kører oven på HDFS. '' NoSQL 'er et bredt udtryk, der betyder, at databasen ikke er en RDBMS, der understøtter SQL som dets primære adgangssprog. Men der er mange typer NoSQL-databaser, og Berkeley DB er et godt eksempel på en lokal NoSQL-database, mens HBase er meget en distribueret database.
HBase indeholder alle funktionerne i Google BigTable. Det begyndte som et projekt af Powerset at behandle store mængder data til naturlig sprog søgning. Det blev udviklet som en del af Apache's Hadoop-projekt og kører oven på HDFS (Hadoop Distributed File System). Det giver fejltolerante måder at lagre store mængder sparsomme data på. HBase er virkelig mere en 'Data Store' end 'Data Base', fordi den mangler mange af de funktioner, der er tilgængelige i RDBMS, såsom indtastede kolonner, sekundære indekser, udløsere og avancerede forespørgselssprog osv.
I de kolonneorienterede databaser lagres datatabel som sektioner af datakolonner snarere end som datarækker. Datamodellen for kolonneorienteret database består af tabelnavn, rækkenøgle, kolonnefamilie, kolonner, tidsstempel. Mens du opretter tabeller i HBase, identificeres rækkerne entydigt ved hjælp af række nøgler og tidsstempel. I denne datamodel er kolonnefamilien statisk, mens kolonner er dynamiske. Lad os nu se på HBase-arkitekturen.
hvad gør en linux-administrator
Hvornår skal man gå til HBase?
HBase er kun en god mulighed, når der er hundreder af millioner eller milliarder af rækker. HBase kan også bruges steder, når man overvejer at flytte fra en RDBMS til HBase som et komplet redesign i modsætning til en port. Med andre ord er HBase ikke optimeret til klassiske transaktionsapplikationer eller endda relationsanalyser. Det er heller ikke en komplet erstatning for HDFS, når du laver stor batch MapReduce. Så hvorfor skulle du gå efter HBase ?? Hvis din applikation har et variabelt skema, hvor hver række er lidt forskellige, skal du se på HBase.
HBase-arkitektur:
Den følgende figur forklarer klart HBase-arkitekturen.
I HBase er der tre hovedkomponenter: Master, Region server og Zoo keeper . De andre komponenter er Memstore, HFile og WAL.
Da HBase kører oven på HDFS, bruger den Master-Slave-arkitekturen, hvor HMaster vil være masterknudepunktet, og Region-serverne er slaveknudepunkterne. Når klienten sender en skriveanmodning, modtager HMaster denne anmodning og videresender den til den respektive Region Server.
postgraduate diplom vs kandidatgrad
Region Server:
Det er et system, der fungerer som en dataknude. Når Region Server (RS) modtager skriveanmodning, dirigeres anmodningen til specifik region. Hver region gemmer sæt rækker. Rigdata kan adskilles i flere kolonnefamilier (CF'er). Data for bestemt CF er gemt i HStore, som består af Memstore og et sæt HFiles.
Hvad gør Memstore?
Memstore holder styr på alle logfiler til læse- og skrivehandlingerne, der er udført inden for den pågældende regionserver. Ud fra dette kan vi sige, at det ligner et navneknudepunkt i Hadoop. Memstore er en lagring i hukommelsen, derfor bruger Memstore lagerhukommelsen i hver hukommelse til at lagre loggene. Når visse tærskler overholdes, skylles Memstore-data i HFile.
Hovedformålet med at bruge Memstore er behovet for at gemme data på DFS bestilt efter række. Da HDFS er designet til sekventiel læsning / skrivning uden tilladelse af filændringer, kan HBase ikke effektivt skrive data til disken, da de modtages: De skrevne data vil ikke blive sorteret (når input ikke er sorteret), hvilket betyder, at det ikke er optimeret til fremtiden hentning. For at løse dette problem modtog HBase-buffere sidst data i hukommelsen (i Memstore), 'sorterer' det, før de skylles, og skriver derefter til HDFS ved hjælp af hurtige sekventielle skrivninger. Derfor indeholder HFile en liste over sorterede rækker.
Hver gang Memstore-skylning sker, oprettes der en HFile til hver CF, og hyppige skylninger kan skabe tonsvis af HFiles. Da HBase under læsning bliver nødt til at se på mange HFiler, kan læsehastigheden lide. For at forhindre åbning af for mange HFiles og undgå forringelse af læseeffektiviteten anvendes HFiles komprimeringsproces. HBase vil med jævne mellemrum (når visse konfigurerbare tærskler er opfyldt) komprimere flere mindre HFiles til en stor. Jo flere filer oprettet af Memstore skyller, jo mere arbejde (ekstra belastning) for systemet. Tilføjet dertil, mens komprimeringsprocessen normalt udføres parallelt med at betjene andre anmodninger, og når HBase ikke kan følge med komprimering af HFiles (ja, der er også konfigurerede tærskler for det), blokerer det for skrivning på RS igen. Som vi diskuterede ovenfor er dette meget uønsket.
Vi kan ikke være sikre på, at dataene vil være vedholdende overalt i Memstore. Antag, at en bestemt datanode er nede. Derefter går de data, der findes på dataknudens hukommelse, tabt.
For at overvinde dette problem, når anmodningen kommer fra mesteren, blev den også skrevet til WAL. WAL er intet andet end Skriv forud logfiler som ligger på HDFS, en permanent lagerplads. Nu kan vi sikre os, at selv når data-noden er nede, går dataene ikke tabt, dvs. vi har kopien af alle de handlinger, du skal udføre i WAL. Når datanoden er oppe, udfører den alle aktiviteterne igen. Når operationen er afsluttet, skylles alt ud fra Memstore og WAL og er skrevet i HFile for at sikre, at vi ikke løber tør for hukommelse.
Lad os tage et simpelt eksempel på, at jeg vil tilføje række 10, så kommer skriveanmodningen ind, der står, at den giver alle metadataene til Memstore og WAL. Når den pågældende række er skrevet i HFile, skylles alt i Memstore og WAL ud.
Dyrepasser:
HBase leveres integreret med Zoo keeper. Når jeg starter HBase, startes Zoo keeper instans også. Årsagen er, at Zoo-keeper hjælper os med at holde styr på alle regionservere, der er der for HBase. Zoo keeper holder styr på, hvor mange regionservere der er, hvilke regionservere holder fra hvilken dataknude til hvilken dataknude. Det holder styr på mindre datasæt, hvor Hadoop går glip af. Det reducerer omkostningerne oven på Hadoop, som holder styr på de fleste af dine metadata. Derfor får HMaster detaljerne om regionservere ved faktisk at kontakte Zoo keeper.
Har du et spørgsmål til os? Nævn dem i kommentarfeltet, så vender vi tilbage til dig.
afslutte et program i java
Relaterede indlæg: