Gjennomgang: HBase er enormt skalerbar - og enormt kompleks

Apache HBase beskriver seg selv som "Hadoop-databasen", noe som kan være litt forvirrende, ettersom Hadoop vanligvis forstås å referere til det populære rammeverket for MapReduce. Men Hadoop er egentlig et paraplynavn for et helt økosystem av teknologier, hvorav noen HBase bruker til å lage en distribuert, kolonneorientert database bygget på de samme prinsippene som Googles Bigtable. HBase bruker ikke Hadoop's MapReduce-funksjoner direkte, selv om HBase kan integreres med Hadoop for å fungere som en kilde eller destinasjon for MapReduce-jobber.

Kjennetegnene til HBase er ekstrem skalerbarhet, høy pålitelighet og skjemafleksibiliteten du får fra en kolonneorientert database. Mens tabeller og kolonnefamilier må defineres på forhånd, kan du legge til nye kolonner på farten. HBase tilbyr også sterk radnivåkonsistens, innebygd versjonering og "koprosessorer" som gir ekvivalenter av utløsere og lagrede prosedyrer.

[Også på: Big data showdown: Cassandra vs. HBase | Hvilken freaking database skal jeg bruke? | Bossie Awards 2013: De beste open source-verktøyene for store data | NoSQL-oppgjør: MongoDB vs. Couchbase | Få et sammendrag av nøkkelhistoriene hver dag i Daily newsletter. ]

HBase er designet for å støtte spørsmål med store datasett, og er optimalisert for leseytelse. For skriver, søker HBase å opprettholde konsistens. I motsetning til "til slutt konsistent" Cassandra, tilbyr ikke HBase forskjellige innstillinger for konsistensnivå (for å bekrefte skrivingen etter at en node har skrevet den eller et quorum av noder har skrevet den). Dermed er prisen på HBases sterke konsistens at skrivingen kan være tregere.

HDFS - Hadoop Distributed File System - er Hadoop-økosystemets grunnlag, og det er filsystemet på toppen som HBase ligger. Designet for å kjøre på råvaremaskinvare og tåle svikt i medlemsnoder, fungerer HDFS best for batchbehandlingssystemer som foretrekker streamet tilgang til store datasett. Dette ser ut til å gjøre det upassende for den tilfeldige tilgangen man forventer i databasesystemer som HBase. Men HBase tar skritt for å kompensere for HDFS ellers upassende oppførsel.

Zookeeper, en annen Hadoop-teknologi (men ikke lenger brukt av nåværende versjoner av Hadoop MapReduce-motoren), er en distribuert kommunikasjonstjeneste. Zookeeper opprettholder en synkronisert datastruktur i minnet som er tilgjengelig for flere klienter. Datastrukturen er organisert som et filsystem, selv om strukturens komponenter (znoder) kan være databeholdere, så vel som elementer i et hierarkisk tre. Tenk deg et filsystem der filene også kan være kataloger.

HBase bruker Zookeeper til å koordinere klyngeaktiviteter og overvåke helsen til medlemsnoder. Når du kjører en HBase-klynge, må du også kjøre Zookeeper parallelt. HBase vil kjøre og administrere Zookeeper som standard, men du kan konfigurere HBase til å bruke et separat administrert Zookeeper-oppsett. Du kan til og med kjøre Zookeeper-serverprosessene på samme maskinvare som de andre HBase-prosessene, men det anbefales ikke, spesielt for en HBase-klynge med høyt volum.

Hvordan HBase fungerer

Mer presist, en rad er en samling av nøkkel / verdipar, nøkkelen er en kolonneidentifikator og verdien er innholdet i cellen som eksisterer i skjæringspunktet mellom en bestemt rad og kolonne. Men fordi HBase er en kolonneorientert database, trenger ikke to rader i en tabell de samme kolonnene. For å komplisere saken ytterligere er data versjonert i HBase. De faktiske koordinatene til en verdi (celle) er tupelen {radnøkkel, kolonnetast, tidsstempel}. I tillegg kan kolonner grupperes i kolonnefamilier, som gir en databasedesigner ytterligere kontroll over tilgangskarakteristikkene, ettersom alle kolonnene i en kolonnefamilie vil bli lagret i nærheten av hverandre.

En skriveoperasjon i HBase registrerer først dataene i en forpliktelseslogg (en "skriv-frem-logg"), deretter til en intern minnestruktur kalt MemStore. Når MemStore fylles, skylles den til disken som en enhet som kalles en HFile. HFiles lagres som en sekvens av datablokker, med en indeks vedlagt til filens slutt. En annen indeks, lagret i minnet, gir raskere søk etter data i HFiles.

HFiles er uforanderlige når de er skrevet. Hvis en nøkkel slettes, registrerer HBase en spesiell "gravstein" -markør for å feire slettingen. Gravsteiner fjernes (det samme er slettede data) når HFiles komprimeres med jevne mellomrom.

HBase prøver å tilfredsstille leseoperasjoner først gjennom MemStore. Unnlater det, sjekker HBase enda en struktur i minnet, BlockStore, som er en lesecache designet for å levere ofte lest data fra minnet, i stedet for fra de diskbaserte HFiles.

HBase splitter rader etter regioner, som er definert av en rekke radnøkler. Hver region i en HBase-klynge styres av en RegionServer-prosess. Vanligvis er det en enkelt RegionServer-prosess per HBase-node. Når datamengden vokser, deler HBase regioner og migrerer de tilknyttede dataene til forskjellige noder i klyngen for balanseringsformål.

HBases klyngearkitektur er ikke helt symmetrisk. For eksempel må hver klynge ha en enkelt, aktiv masternode. Flere noder kan (og bør) betegnes som hovednoder, men når klyngen starter, koordineres kandidaten slik at bare en er fungerende mester. Det er mesterens ansvar å overvåke regionservere, håndtere regionservers failover og koordinere regiondelinger.

Hvis masternoden krasjer, kan klyngen fremdeles operere i steady-state-modus - administrere lese- og skriveforespørsler - men kan ikke utføre noen av operasjonene som krever masterkoordinering (for eksempel rebalansering). Dette er grunnen til at det er en god ide å spesifisere flere hovednoder; hvis og når den regjerende mesteren skulle mislykkes, vil den raskt byttes ut.

Du kan kjøre HBase oppå et eget filsystem for utviklingsformål, men en distribuert HBase-klynge kjører på HDFS, som - som nevnt tidligere - virker som en dårlig lekeplass for HBase. Til tross for det streamingorienterte underliggende filsystemet, oppnår HBase rask tilfeldig I / U. Det oppnår denne magien ved en kombinasjon av batching-skrivinger i minnet og vedvarende data til disk ved hjelp av loggstrukturerte flettetrær. Som et resultat blir alle tilfeldige skrivinger utført i minnet, og når data skylles til disk, blir dataene først sortert, deretter skrevet sekvensielt med tilhørende indeks. Tilfeldige lesinger blir først forsøkt i minnet, som nevnt ovenfor. Hvis de forespurte dataene ikke er i minnet, er det påfølgende disksøket raskt fordi dataene er sortert og indeksert.

Jobber med HBase

Mens HBase ikke støtter transaksjoner, er det heller ikke til slutt konsistent; heller, HBase støtter sterk konsistens, i det minste på nivå med en enkelt rad. HBase har ingen sans for datatyper; alt lagres som en rekke byte. Imidlertid definerer HBase en spesiell "mot" -datatype, som gir en atominnhøyingsoperasjon - nyttig for eksempel å telle visninger av en webside. Du kan øke et hvilket som helst antall tellere i en enkelt rad via en enkelt samtale, og uten å måtte låse raden. Vær oppmerksom på at tellere blir synkronisert for skriveoperasjoner (flere skrivinger vil alltid utføre konsistente trinn), men ikke nødvendigvis for leseoperasjoner.

HBase-skallet er faktisk et modifisert, interaktivt Ruby-skall som kjører i JRuby, med Ruby som kjøres i en Java-VM. Alt du kan gjøre i det interaktive Ruby-skallet, kan du gjøre i HBase-skallet, noe som betyr at HBase-skallet kan være et kraftig skriptmiljø.

Den siste versjonen av skallet gir et slags objektorientert grensesnitt for å manipulere HBase-tabeller. Du kan for eksempel tilordne en tabell til en JRuby-variabel og deretter utstede en metode på tabellobjektet ved hjelp av standard prikknotasjon. For eksempel hvis du har definert en tabell og tildelt den til myTable variabel, kan du skrive (sette) data til tabellen med noe sånt som:

myTable.put '', '', ''

Dette vil skrive verdien inn i rekken ved kolonne .

Det er noen tredjeparts GUIer for administrasjon for HBase, for eksempel hbase-explorer. HBase selv inneholder noen innebygde nettbaserte overvåkingsverktøy. En HBase-hovednode serverer et webgrensesnitt på port 60010. Bla gjennom den, og du vil finne informasjon om selve masternoden, inkludert starttidspunkt, den nåværende Zookeeper-porten, en liste over regionservere, gjennomsnittlig antall regioner per regionserver , og så videre. En liste over tabeller er også gitt. Klikk på en tabell, så får du vist informasjon, for eksempel områdeserverne som er vert for tabellens komponenter. Denne siden gir også kontroller for å starte en komprimering på bordet eller dele tabellens regioner.

I tillegg kjører hver regionserverknute et overvåkingsnettgrensesnitt ved port 60030. Her finner du mange beregninger: lese- og skriveforsinkelser, for eksempel fordelt på forskjellige persentiler. Du kan også se informasjon om regionene som administreres av denne regionserveren, og du kan generere en dump av de aktive trådene på serveren.

HBase referansehåndbok inneholder en Komme i gang-guide og en FAQ. Det er et live-dokument, så du finner kommentarer fra brukernes fellesskap knyttet til hver oppføring. HBase-nettstedet inneholder også lenker til HBase Java API, samt til videoer og kilder utenfor HBase-informasjon. Mer informasjon finner du i HBase wiki. Selv om det er bra, er ikke HBase-dokumentasjonen helt på nivå med dokumentasjon jeg har sett på andre databaseproduktsider, som Cassandra og MongoDB. Likevel er det rikelig med materiale rundt Internett, og HBase-samfunnet er stort og aktivt nok til at eventuelle HBase-spørsmål ikke blir ubesvart lenge.

En av HBases mer interessante nylige tillegg er støtte for "coprocessors" - brukerkode som kjøres som en del av HBase RegionServer- og Master-prosessene. Det er omtrent to typer medbehandlere: observatører og sluttpunkter. En observatør er en brukerskrevet Java-klasse som definerer metoder som skal påkalles når visse HBase-hendelser inntreffer. Tenk på en observatør som HBase-motstykket til RDBMS-utløseren. En observatør, kalt RegionObserver, kan hekte spesifikke punkter i strømmen av kontroll av datamanipuleringsoperasjoner som få, sette, og slett.

HBase-endepunktsprosessoren fungerer omtrent som en lagret prosedyre. Når den er lastet kan den påberopes fra en observatør, for eksempel, og tillater dermed å legge til nye funksjoner til HBase dynamisk. Det er forskjellige måter å laste kopiprosessorer inn i en HBase-klynge, inkludert via HBase-skallet.

Det kan være vanskelig å konfigurere en stor HBase-klynge. En HBase-klynge inkluderer hovednoder, RegionServer-prosesser, HDFS-prosesser og en hel Zookeeper-klynge som går side om side. Det er klart at feilsøking av en feil kan være en kompleks oppgave, ettersom det er mange bevegelige deler som skal undersøkes.

HBase er veldig mye en utviklingssentrisk database. Den elektroniske referanseveiledningen er sterkt knyttet til HBases Java API-dokumenter. Hvis du vil forstå rollen som en bestemt HBase-enhet - for eksempel et filter - spiller, vær forberedt på å bli overlevert til Java APIs dokumentasjon av filterklassen for en fullstendig forklaring.

Gitt at tilgang er etter rad og at rader er indeksert av radnøkler, følger det at nøye utforming av radnøkkelstruktur er avgjørende for god ytelse. Ironisk nok visste programmerere i de gamle dager av ISAM (Indexed Sequential Access Method) databaser dette godt: Databasetilgang handlet om komponentene - og bestillingen av disse komponentene - i sammensatte nøkkelindekser.

HBase benytter en samling kamptestede teknologier fra Hadoop-verdenen, og det er vel verdt å vurdere når man bygger en stor, skalerbar, svært tilgjengelig, distribuert database, spesielt for applikasjoner der sterk konsistens er viktig.

Apache HBase 0.94 på et øyeblikk