Anmeldelse: HBase er masserigt skalerbar - og enormt kompleks

Apache HBase beskriver sig selv som "Hadoop-databasen", hvilket kan være lidt forvirrende, da Hadoop typisk forstås at henvise til den populære MapReduce-behandlingsramme. Men Hadoop er virkelig et paraplynavn for et helt økosystem af teknologier, hvoraf nogle HBase bruger til at oprette en distribueret, kolonneorienteret database bygget på de samme principper som Googles Bigtable. HBase bruger ikke Hadoop's MapReduce-funktioner direkte, selvom HBase kan integreres med Hadoop for at tjene som kilde eller destination for MapReduce-job.

HBase's kendetegn er ekstrem skalerbarhed, høj pålidelighed og den skemafleksibilitet, du får fra en kolonneorienteret database. Mens tabeller og kolonnefamilier skal defineres på forhånd, kan du tilføje nye kolonner i farten. HBase tilbyder også stærk række-niveau konsistens, indbygget versionering og "coprocessorer", der giver ækvivalenter af udløsere og lagrede procedurer.

[Også på: Big data showdown: Cassandra vs. HBase | Hvilken freaking database skal jeg bruge? | Bossie Awards 2013: De bedste open source big data-værktøjer NoSQL-opgør: MongoDB vs. Couchbase | Få en fordøjelse af nøglehistorierne hver dag i det daglige nyhedsbrev. ]

HBase er designet til at understøtte forespørgsler om massive datasæt og er optimeret til læsepræstation. For skriver forsøger HBase at opretholde konsistens. I modsætning til "til sidst konsistent" Cassandra tilbyder HBase ikke forskellige konsistensniveauindstillinger (for at anerkende skrivningen, efter at en node har skrevet den, eller et kvorum af noder har skrevet den). Således er prisen på HBases stærke konsistens, at skrivning kan være langsommere.

HDFS - Hadoop Distribueret Filsystem - er Hadoop-økosystemets fundament, og det er filsystemet ovenpå, hvor HBase er bosat. HDFS er designet til at køre på råvarehardware og tåler medlemsnodefejl og fungerer bedst til batchbehandlingssystemer, der foretrækker streamet adgang til store datasæt. Dette ser ud til at gøre det upassende for den tilfældige adgang, man kan forvente i databasesystemer som HBase. Men HBase tager skridt til at kompensere for HDFS ellers uhensigtsmæssige adfærd.

Zookeeper, en anden Hadoop-teknologi (dog ikke længere brugt af de nuværende versioner af Hadoop MapReduce-motoren), er en distribueret kommunikations- og koordinationstjeneste. Zookeeper opretholder en synkroniseret datastruktur i hukommelsen, der kan tilgås af flere klienter. Datastrukturen er organiseret som et filsystem, selvom strukturens komponenter (znoder) kan være databeholdere såvel som elementer i et hierarkisk træ. Forestil dig et filsystem, hvis filer også kan være kataloger.

HBase bruger Zookeeper til at koordinere klyngeaktiviteter og overvåge medlemsnoders sundhed. Når du kører en HBase-klynge, skal du også køre Zookeeper parallelt. HBase kører og administrerer Zookeeper som standard, selvom du kan konfigurere HBase til at bruge en separat administreret Zookeeper-opsætning. Du kan endda køre Zookeeper-serverprocesserne på den samme hardware som de andre HBase-processer, men det anbefales ikke, især til en HBase-klynge med stort volumen.

Sådan fungerer HBase

Mere præcist er en række en samling af nøgle / værdipar, nøglen er en kolonneidentifikator, og værdien er indholdet af cellen, der findes i skæringspunktet mellem en bestemt række og kolonne. Men fordi HBase er en kolonneorienteret database, behøver ikke to rækker i en tabel have de samme kolonner. For at komplicere forholdene yderligere er data versioneret i HBase. De faktiske koordinater for en værdi (celle) er tuplen {række nøgle, kolonne nøgle, tidsstempel}. Derudover kan kolonner grupperes i kolonnefamilier, som giver en databasedesigner yderligere kontrol over adgangskarakteristikker, da alle kolonner i en kolonnefamilie vil blive gemt tæt på hinanden.

En skriveoperation i HBase registrerer først dataene i en commit-log (en "skriv-forud-log"), derefter til en intern hukommelsesstruktur kaldet MemStore. Når MemStore udfyldes, skylles den til disken som en enhed kaldet en HFile. HFiles gemmes som en sekvens af datablokke med et indeks vedhæftet til filens ende. Et andet indeks, der opbevares i hukommelsen, fremskynder søgninger efter data i HFiles.

HFiles er uforanderlige, når de er skrevet. Hvis en nøgle slettes, registrerer HBase en speciel "gravsten" -markør for at fejre sletningen. Gravsten fjernes (ligesom slettede data), når HFiles periodisk komprimeres.

HBase forsøger at tilfredsstille læseoperationer først gennem MemStore. I modsat fald kontrollerer HBase endnu en struktur i hukommelsen, BlockStore, som er en læsecache designet til at levere ofte læst data fra hukommelsen snarere end fra de diskbaserede HFiles.

HBase splinter rækker efter regioner, der er defineret af en række række nøgler. Hver region i en HBase-klynge styres af en RegionServer-proces. Der er typisk en enkelt RegionServer-proces pr. HBase-node. Efterhånden som datamængden vokser, opdeler HBase regioner og migrerer de tilknyttede data til forskellige noder i klyngen til afbalanceringsformål.

HBases klyngearkitektur er ikke helt symmetrisk. For eksempel skal hver klynge have en enkelt, aktiv masternode. Flere noder kan (og bør) betegnes som masternoder, men når klyngen starter, koordinerer kandidatmestrene, så kun en er den fungerende master. Det er mesterens ansvar at overvåge regionservere, håndtere failover til regionsserver og koordinere opdeling af regioner.

Skulle masternoden gå ned, kan klyngen stadig fungere i steady-state-tilstand - administrere læse- og skriveanmodninger - men kan ikke udføre nogen af ​​de operationer, der kræver masterkoordinationen (såsom rebalansering). Derfor er det en god ide at specificere flere masternoder; hvis og når den regerende master mislykkes, udskiftes den hurtigt.

Du kan køre HBase oven på et oprindeligt filsystem til udviklingsformål, men en implementeret HBase-klynge kører på HDFS, som - som tidligere nævnt - virker som en dårlig legeplads for HBase. På trods af det streamingorienterede underliggende filsystem opnår HBase hurtig tilfældig I / O. Det udfører denne magi ved en kombination af batch-skrivning i hukommelse og vedvarende data til disk ved hjælp af logstrukturerede flette træer. Som et resultat udføres alle tilfældige skrivninger i hukommelsen, og når data skylles til disk, sorteres dataene først og skrives derefter sekventielt med et ledsagende indeks. Tilfældige aflæsninger forsøges først i hukommelsen som nævnt ovenfor. Hvis de ønskede data ikke er i hukommelsen, er den efterfølgende disksøgning hurtig, fordi dataene sorteres og indekseres.

Arbejde med HBase

Mens HBase ikke understøtter transaktioner, er det heller ikke i sidste ende konsistent; snarere understøtter HBase stærk konsistens, i det mindste på niveau med en enkelt række. HBase har ingen sans for datatyper; alt er gemt som en række bytes. HBase definerer dog en speciel "tæller" -datatype, som giver mulighed for en atomforøgelse - f.eks. Nyttig til at tælle visninger af en webside. Du kan øge et hvilket som helst antal tællere inden for en enkelt række via et enkelt opkald og uden at skulle låse rækken. Bemærk, at tællere synkroniseres til skriveoperationer (flere skriv vil altid udføre ensartede intervaller), men ikke nødvendigvis til læseoperationer.

HBase-shell er faktisk en modificeret, interaktiv Ruby-shell, der kører i JRuby, hvor Ruby udføres i en Java VM. Alt hvad du kan gøre i den interaktive Ruby shell, kan du gøre i HBase-shell, hvilket betyder, at HBase-shell kan være et kraftigt scriptmiljø.

Den seneste version af skallen giver en slags objektorienteret grænseflade til manipulation af HBase-tabeller. Du kan for eksempel tildele en tabel til en JRuby-variabel og derefter udstede en metode på tabelobjektet ved hjælp af standardpunktnotationen. For eksempel, hvis du har defineret en tabel og tildelt den til myTable variabel, kan du skrive (sætte) data til tabellen med noget som:

myTable.put '', '', ''

Dette ville skrive værdien ind i rækken ved kolonne .

Der er nogle tredjepartsledelses-GUI'er til HBase, såsom hbase-explorer. HBase selv indeholder nogle indbyggede webbaserede overvågningsværktøjer. En HBase-masternode serverer en webgrænseflade på port 60010. Gennemse den, og du finder oplysninger om selve masternoden inklusive starttidspunkt, den aktuelle Zookeeper-port, en liste over regionsservere, det gennemsnitlige antal regioner pr. Regionsservere , og så videre. Der er også en liste over tabeller. Klik på en tabel, og du får vist oplysninger, såsom de regionale servere, der er vært for bordets komponenter. Denne side indeholder også kontrolelementer til initiering af en komprimering på bordet eller opdeling af bordets regioner.

Derudover kører hver regionserverknudepunkt en overvågningswebgrænseflade i port 60030. Her finder du masser af metrics: læse- og skrivelatenser, for eksempel opdelt i forskellige percentiler. Du kan også se oplysninger om de regioner, der administreres af denne regionserver, og du kan generere et dump af de aktive tråde på serveren.

HBase-referencevejledningen indeholder en Kom godt i gang-guide og en FAQ. Det er et live-dokument, så du finder brugerfællesskabskommentarer knyttet til hver post. HBase-webstedet indeholder også links til HBase Java API samt til videoer og kilder til HBase-information uden for webstedet. Flere oplysninger findes i HBase wiki. Mens det er godt, er HBase-dokumentationen ikke helt på niveau med dokumentation, jeg har set på andre databaseproduktwebsteder, såsom Cassandra og MongoDB. Ikke desto mindre er der masser af materiale rundt på Internettet, og HBase-samfundet er stort og aktivt nok til, at eventuelle HBase-spørgsmål ikke bliver ubesvarede længe.

En af HBases mere interessante nyere tilføjelser er understøttelse af "coprocessorer" - brugerkode, der udføres som en del af HBase RegionServer- og Master-processerne. Der er omtrent to slags coprocessorer: observatører og slutpunkter. En observatør er en brugerskrevet Java-klasse, der definerer metoder, der skal påberåbes, når visse HBase-hændelser opstår. Tænk på en observatør som HBase-modstykke til RDBMS-udløseren. En observatør, kaldet RegionObserver, kan tilslutte specifikke punkter i strømmen af ​​kontrol med datemanipulationsoperationer som f.eks få, sætteog slet.

HBase-slutpunktsprocessoren fungerer meget som en lagret procedure. Når det er indlæst, kan det f.eks. Påberåbes fra en observatør og derved tillade dynamisk at tilføje nye funktioner til HBase. Der er forskellige måder at indlæse coprocessorer i en HBase-klynge, herunder via HBase-shell.

Det kan være svært at konfigurere en stor HBase-klynge. En HBase-klynge indeholder masternoder, RegionServer-processer, HDFS-processer og en hel Zookeeper-klynge, der kører side om side. Det er klart, at fejlfinding af en fejl kan være en kompleks opgave, da der er mange bevægelige dele, der skal undersøges.

HBase er meget en udviklercentreret database. Dens online referencevejledning er stærkt knyttet til HBases Java API-dokumenter. Hvis du vil forstå den rolle, som en bestemt HBase-enhed - f.eks. Et filter - spiller, skal du være forberedt på at blive afleveret til Java API's dokumentation for filterklassen for en fuldstændig forklaring.

Da adgang er efter række, og at rækker indekseres af række nøgler, følger det, at omhyggeligt design af række nøglestruktur er afgørende for god ydeevne. Ironisk nok vidste programmører i de gode gamle dage af ISAM-databaser (Indexed Sequential Access Method) dette godt: Databaseadgang handlede om komponenterne - og rækkefølgen af ​​disse komponenter - i sammensatte-nøgleindekser.

HBase anvender en samling kamptestede teknologier fra Hadoop-verdenen, og det er værd at overveje, når man bygger en stor, skalerbar, meget tilgængelig, distribueret database, især til de applikationer, hvor stærk konsistens er vigtig.

Apache HBase 0.94 et overblik