Clustering i NoSQL - dummies

NoSQL databaser er velegnede til meget store datasæt. Bigtable kloner som HBase er ingen undtagelse. Du vil sandsynligvis gerne bruge flere billige vare servere i en enkelt klynge snarere end en meget kraftig maskine. Dette skyldes, at du kan få den samlede bedre ydelse pr. Dollar ved at bruge mange vare servere, snarere end en langt mere kostbar enkelt kraftig server.

Ud over at kunne opskalere hurtigt kan billige vare servere også gøre din database service mere modstandsdygtig og dermed undgå hardwarefejl. Dette skyldes, at du har andre servere til at overtage tjenesten, hvis en enkelt servers bundkort mislykkes. Dette er ikke tilfældet med en enkelt stor server.

Figuren viser en meget tilgængelig HBase-konfiguration med et eksempel på datadeling blandt servere.

Diagrammet viser to noder (HRegionServers) i en meget tilgængelig opsætning, som hver især fungerer som backup.

I mange produktionsopsætninger kan du have mindst tre noder for høj tilgængelighed for at sikre to serverfejl tæt på hinanden, kan håndteres. Dette er ikke så sjældent som du tror! Rådgivning varierer pr. Bigtable; for eksempel anbefaler HBase fem noder som minimum for en klynge:

• Hver regionsserver styrer sit eget sæt nøgler.

  At designe en række nøglefordelingsstrategi er vigtig, fordi den dikterer, hvordan belastningen spredes over klyngen.

• | Hver region opretholder sin egen skrive-log og i-lagerbutik.

  I HBase skrives alle data til en in-memory-butik, og senere bliver denne butik skyllet til disk. På disk kaldes disse butikker gem filer .

  HBase fortolker gemmer filer som enkeltfiler, men i virkeligheden distribueres de i stykker på tværs af et Hadoop Distributed File System (HDFS). Dette giver mulighed for høj indtag og hentningshastighed, fordi alle store I / O-operationer spredes over mange maskiner.

For at maksimere datatilgængeligheden holder Hadoop som standard tre kopier af hver datafil. Store installationer har

• En primær kopi

• En kopi i samme rack

• En anden kopi i et andet rack

Før Hadoop 2. 0 kunne Namenodes ikke laves meget tilgængelige. Disse vedligeholdt en liste over alle aktive servere i klyngen. De var derfor et eneste punkt i fiasko. Siden Hadoop 2. 0 eksisterer denne grænse ikke længere.