Clustering i NoSQL-dummies

NoSQL databaser passer godt til store datasett. Bigtable kloner som HBase er intet unntak. Du vil sannsynligvis ønske å bruke flere billige vare servere i en enkelt klynge i stedet for en veldig kraftig maskin. Dette skyldes at du kan få samlet bedre ytelse per dollar ved å bruke mange vare servere, i stedet for en mye mer kostbar enkelt, kraftig server.

I tillegg til å være i stand til å skalere raskt, kan rimelige vareservere også gjøre databasetjenesten mer motstandsdyktig og dermed bidra til å unngå maskinvarefeil. Dette skyldes at du har andre servere som skal overta tjenesten hvis en enkelt server hovedkort mislykkes. Dette er ikke tilfellet med en enkelt stor server.

Figuren viser en svært tilgjengelig HBase-konfigurasjon med et eksempel på datasplittelse mellom servere.

Diagrammet viser to noder (HRegionServers) i et svært tilgjengelig oppsett, hver som fungerer som backup for den andre.

I mange produksjonsoppsett vil du kanskje ha minst tre noder for høy tilgjengelighet for å sikre at to serverfeil i tide til hverandre kan håndteres. Dette er ikke så sjeldent som du tror! Råd varierer per Bigtable; for eksempel anbefaler HBase fem noder som minimum for en klynge:

• Hver regionserver administrerer sitt eget sett med nøkler.

  Å designe en radnøkkelfordelingsstrategi er viktig fordi den dikterer hvordan belastningen spres over klassen.

• | Hver region opprettholder sin egen skrivelogg og i minnesbutikk.

  I HBase skrives alle data til en minnesbutikk, og senere blir denne butikken skyllet til disk. På disk kalles disse butikkene lagre filer .

  HBase tolker lagre filer som enkeltfiler, men i virkeligheten distribueres de i biter over et Hadoop Distributed File System (HDFS). Dette gir høy inntak og henting hastighet fordi alle store I / O operasjoner er spredt over mange maskiner.

For å maksimere datatilgjengelighet holder Hadoop som standard tre eksemplarer av hver datafil. Store installasjoner har

• En primærkopi

• En kopi i samme rack

• En annen kopi i et annet rack

Før Hadoop 2. 0, kunne Namenodes ikke gjøres svært tilgjengelige. Disse vedlikeholdt en liste over alle aktive servere i klyngen. De var derfor et eneste punkt av fiasko. Siden Hadoop 2. 0, eksisterer denne grensen ikke lenger.