sql >> Databasteknik >  >> NoSQL >> HBase

Hur skalning verkligen fungerar i Apache HBase

Det här inlägget publicerades ursprungligen via blogs.apache.org, vi publicerar det här igen i en något modifierad form för din bekvämlighet:

Vid första anblicken verkar Apache HBase-arkitekturen följa en master/slav-modell där mastern tar emot alla förfrågningar men det verkliga arbetet utförs av slavarna. Så är faktiskt inte fallet, och i den här artikeln kommer jag att beskriva vilka uppgifter som faktiskt hanteras av befälhavaren och slavarna.

Regioner och regionservrar

HBase är Hadoop-lagringshanteraren som tillhandahåller slumpmässig läsning och skrivning med låg latens ovanpå HDFS, och den kan hantera petabyte med data. En av de intressanta funktionerna i HBase är automatisk delning, vilket helt enkelt innebär att tabeller distribueras dynamiskt av systemet när de blir för stora.

Den grundläggande enheten för horisontell skalbarhet i HBase kallas en Region . Regioner är en delmängd av tabellens data och de är i huvudsak ett sammanhängande, sorterat intervall av rader som lagras tillsammans.

Inledningsvis finns det bara en region för en tabell. Som visas nedan, när områden blir för stora efter att ha lagt till fler rader, delas området i två vid mittknappen, vilket skapar två ungefär lika stora halvor.

I HBase kallas slavarna Region Servers . Varje regionserver är ansvarig för att betjäna en uppsättning regioner, och en region (dvs. radintervall) kan endast betjänas av en regionserver.

HBase-arkitekturen har två huvudtjänster:HMaster som är ansvarig för att koordinera klustret och utföra administrativa operationer, och HRegionServer ansvarig för att hantera en delmängd av tabellens data.

HMaster, Region Assignment och Balancing

Som tidigare nämnts koordinerar HBase Master HBase Cluster och ansvarar för den administrativa verksamheten.

En regionserver kan betjäna en eller flera regioner. Varje region tilldelas en regionserver vid uppstart och mastern kan besluta att flytta en region från en regionserver till en annan som ett resultat av en lastbalansoperation. Mastern hanterar även regionserverfel genom att tilldela regionen till en annan regionserver.

Kartläggningen av regioner och regionservrar hålls i en systemtabell som kallas META. Genom att läsa META kan du identifiera vilken region som är ansvarig för din nyckel. Detta innebär att för läs- och skrivoperationer är befälhavaren inte involverad alls och klienter kan gå direkt till den ansvariga regionservern för att betjäna den begärda informationen.

Hitta en radnyckel:Vilken regionserver är ansvarig?

För att lägga eller skaffa en rad behöver klienter inte kontakta mastern, klienter kan direkt kontakta regionservern som hanterar den angivna raden, eller i händelse av en klientskanning kan direkt kontakta uppsättningen regionservrar som ansvarar för att hantera uppsättningen av nycklar:

För att identifiera regionservern gör klienten en fråga på META-tabellen.

META är en systemtabell som används för att hålla reda på regioner. Den innehåller servernamnet och en regionidentifierare som består av ett tabellnamn och startrad-nyckeln. Genom att titta på startnyckeln och nästa region kan startnyckelklienter identifiera radintervallet som finns i en viss region.

Klienten behåller en cache för regionplatserna. Detta undviker att klienter träffar META-tabellen varje gång en operation på samma region utfärdas. Om en region delas eller flyttas till en annan regionserver (på grund av balansering eller tilldelningspolicyer), kommer klienten att få ett undantag som svar och cachen kommer att uppdateras genom att hämta den uppdaterade informationen från META-tabellen:

Eftersom META är en tabell som de andra måste klienten identifiera vilken server META finns på. META-platserna lagras i en ZooKeeper-nod på uppdrag av Mastern, och klienten läser noden direkt för att få adressen till regionservern som innehåller META.

HBases ursprungliga design baserades på BigTable, med en annan tabell som heter -ROOT- som innehåller META-platserna och Apache ZooKeeper pekar på den. HBase 0.96 tog bort det arrangemanget till förmån för enbart ZooKeeper, eftersom META inte kan delas och därför består av en enda region.

Client API:Master and Regions Responsibilities

HBase Java-klient-API har två huvudgränssnitt:

  • HBaseAdmin tillåter interaktion med "tabellschemat" genom att skapa/ta bort/ändra tabeller, och det tillåter interaktion med klustret genom att tilldela/avtilldela regioner, slå samman regioner, kalla på en tömning, och så vidare. Detta gränssnitt kommunicerar med Mastern.
  • HTable tillåter klienten att manipulera data i en specificerad tabell genom att använda get, put, delete och alla andra dataoperationer. Detta gränssnitt kommunicerar direkt med regionservrarna som ansvarar för att hantera den begärda uppsättningen nycklar.

Dessa två gränssnitt har separata ansvarsområden:HBaseAdmin används endast för att utföra adminoperationer och kommunicera med Mastern medan HTable används för att manipulera data och kommunicera med regionerna.

Slutsats

Som vi har sett här betyder det inte att ha en Master/Slav-arkitektur att varje operation går genom mastern. För att läsa och skriva data går HBase-klienten i själva verket direkt till den specifika regionservern som är ansvarig för att hantera radnycklarna för alla dataoperationer (HTable). Mastern används endast av klienten för att skapa, modifiera och ta bort tabeller (HBaseAdmin).

Även om konceptet för en master existerar, är HBase-klienten inte beroende av det för dataoperationer och klustret kan fortsätta att leverera data även om mastern går ner.

Matteo Bertozzi är mjukvaruingenjör i plattformsteamet och en HBase Committer.

Om du är intresserad av HBase, se till att registrera dig för HBaseCon 2013 (13 juni, San Francisco) – gemenskapsevenemanget för HBase-bidragsgivare, utvecklare, administratörer och användare. Utrymmet är begränsat!


  1. Google Cloud Platform – Kan inte ansluta till mongodb

  2. Vårsessionsdata Redis - Få giltiga sessioner, nuvarande användare från Redis Store

  3. Redis:Hur man analyserar ett listresultat

  4. skjuta in objekt i arrayschema i Mongoose