Video: Database Clustering Tutorial 1 - Intro to Database Clustering 2024
NoSQL-Datenbanken sind für sehr große Datensätze geeignet. Bigtable Klone wie HBase sind keine Ausnahme. Sie werden wahrscheinlich mehrere kostengünstige Commodity-Server in einem einzigen Cluster verwenden wollen und nicht eine sehr leistungsfähige Maschine. Dies liegt daran, dass Sie eine bessere Gesamtleistung pro Dollar erzielen können, wenn Sie viele Commodity-Server verwenden, und nicht einen wesentlich teureren, leistungsstärkeren Server.
Neben der Möglichkeit zur schnellen Skalierung können kostengünstige Commodity-Server Ihren Datenbankdienst auch widerstandsfähiger machen und so Hardware-Ausfälle vermeiden. Dies liegt daran, dass andere Server den Dienst übernehmen müssen, wenn das Motherboard eines einzelnen Servers ausfällt. Dies ist bei einem einzelnen großen Server nicht der Fall.
Die Abbildung zeigt eine hochverfügbare HBase-Konfiguration mit einem Beispiel für die Aufteilung der Daten auf die Server.
Das Diagramm zeigt zwei Knoten (HRegionServers) in einem hoch verfügbaren Setup, die jeweils als Backup für das andere fungieren.
In vielen Produktions-Setups können Sie mindestens drei Knoten für hohe Verfügbarkeit benötigen, um sicherzustellen, dass zwei Server-Ausfälle, die zeitlich nahe beieinander liegen, behandelt werden können. Das ist nicht so selten wie man denkt! Ratschläge variieren je Bigtable; zum Beispiel empfiehlt HBase für einen Cluster mindestens fünf Knoten:
-
Jeder Regionsserver verwaltet seinen eigenen Schlüsselsatz.
Das Entwerfen einer Zeilenzuordnungsstrategie ist wichtig, weil es bestimmt, wie die Last über den Cluster verteilt wird.
-
| Jede Region verfügt über ein eigenes Schreibprotokoll und einen speicherinternen Speicher.
In HBase werden alle Daten in einen Speicher im Arbeitsspeicher geschrieben, und später wird dieser Speicher auf die Festplatte geschrieben. Auf der Festplatte werden diese Speicher Speicherdateien genannt.
HBase interpretiert Speicherdateien als einzelne Dateien, aber in Wirklichkeit sind sie in Chunks über ein verteiltes Hadoop-Dateisystem (HDFS) verteilt. Dies sorgt für eine hohe Ingest- und Retrieval-Geschwindigkeit, da alle großen I / O-Operationen auf viele Maschinen verteilt sind.
Um die Datenverfügbarkeit zu maximieren, verwaltet Hadoop standardmäßig drei Kopien jeder Datendatei. Große Installationen haben
-
Eine primäre Kopie
-
Ein Replikat innerhalb desselben Racks
-
Ein weiteres Replikat in einem anderen Rack
Vor Hadoop 2. 0 konnten Namenodes nicht hoch verfügbar gemacht werden. Diese enthielten eine Liste aller aktiven Server im Cluster. Sie waren daher ein einziger Punkt des Scheiterns. Seit Hadoop 2. 0 existiert diese Grenze nicht mehr.
