Google's BigTable: Ein verteiltes Speichersystem für strukturierte Daten von Florian Eiteljörge

Übersicht 1.Was ist Bigtable? 2.Datenmodell 3.Implementierung/Architektur von Bigtable 4.Vergleich mit relationalen DBMS und weitere Entwicklungen

Was ist Bigtable? verteilter, strukturierter Datenspeicher wird seit 2003 von Google entwickelt und betrieben wird in zahlreichen Projekten und Produkten von Google verwendet, u.a. –Personalisierte Suche –Google Earth –Google Analytics

Designanforderungen breit einsetzbar Skalierbarkeit –Daten im Petabyte-Bereich (1 Petabyte = 1000 Terabyte) –Millionen Lese-/Schreibvorgänge pro Sekunde Hochverfügbarkeit/Fehlertoleranz gegenüber Hardwareausfällen Self-managing –Server dynamisch hinzufügen/entfernen –automatisches Loadbalancing

Datenmodell Bigtable-Cluster: Ansammlung von Prozessen, die die Bigtable-Software ausführen Cluster besteht aus Tabellen, die im wesentlichen –verteilte, –persistente, –multidimensionale, –sortierte Maps sind.

Tabellen bestehen aus einer Sammlung von Zellen Zellen sind dreidimensional organisiert Zellenzugriff über mehrdimensionale Schlüssel: (row:string, column:string, time:int64) → cell-content:string Nach: Bigtable: A Distributed Storage System for Structured Data, Chang, Dean, Gemawat, Hsieh, Wallach, Burrows, Chandra, Fikes und Gruber, 2006/2008

Zeilen Daten werden in lexikographisch Reihenfolge nach dem Zeilenschlüssel sortiert gespeichert Zeilenschlüssel: beliebiger String (max. 64KB) Transaktionen auf Zeilenebene beschränkt

Spalten einzelne Spalte in Bigtable sehr leichtgewichtig Tabellen haben oftmals mehrere tausend Spalten Beispiel Website: jeder Hyperlink einer Website entspricht eigener Spalte

Spalten Spalten mit ähnlichem Inhalt werden in „column families“ gegliedert Zugriff erfolgt über family:qualifier (z.B. „anchor:cnnsi.com“) Tabellen enthalten meist mehrere Hundert column families Access Control basiert auf column families

Zeitstempel 64bit Integer; Zeitpunkte werden in Mikrosekunden gespeichert gibt normalerweise an zu welchem Zeitpunkt der Datensatz aktuell war automatische Garbage Collection: Benutzer kann wählen was gespeichert wird: –die n letzten Versionen des Datensatzes –Werte, die in den letzten n Minuten/Stunden/Tagen geschrieben wurden

Bigtable Übersicht Tablet-Server Nach: Bigtable: A Distributed Storage System for Structured Data, Chang, Dean, Gemawat, Hsieh, Wallach, Burrows, Chandra, Fikes und Gruber, 2006/2008

Tablet-Server verwaltet „Tablets“ Tablets sind die Partitionen aus denen Tabellen bestehen jede Tabelle besteht anfangs aus einer Partition, also einem Tablet wächst eine Tabelle über bestimmte Größe, wird sie automatisch aufgeteilt –Zeilen werden niemals geteilt –aufeinanderfolgende Zeilen werden zusammen gespeichert in sog. Locality Groups

Tablet-Server Zielgröße für Tablets: 1GB jeder Tablet-Server verwaltet zwischen 10 und 1000 Tablets, abhängig von –der tatsächlichen Größe der Tablets und  Empfehlung der Entwickler: keine Zeile größer als wenige hundert Gigabyte –der Häufigkeit der Zugriffe auf ein Tablet Bigtable-Cluster besteht i.d.R. aus sehr vielen Tablet-Servern (mehrere Hundert oder mehr) -> automatisches Loadbalancing notwendig

Bigtable Übersicht Nach: Bigtable: A Distributed Storage System for Structured Data, Chang, Dean, Gemawat, Hsieh, Wallach, Burrows, Chandra, Fikes und Gruber, 2006/2008 Master-Server Tablet-Server Daten verwalten/ ausliefern

Master-Server pro Cluster existiert nur ein aktiver Master- Server führt Metadatenoperationen wie z.B. anlegen oder löschen von Schemata durch weist Tablet-Servern Tablets zu (lastabhängig) überwacht, dass alle Tablets zugewiesen sind Wie stellt man fest, dass alle Tablets zugewiesen sind?

Chubby sog. Distributed Lock Manager synchronisiert Zugriff auf verteilte Ressourcen jeder Tablet- und Master-Server meldet sich bei Chubby an

2. nach Tablet-Servern scannen Start eines Master-Servers Master-ServerChubby-Service Tablet-Server 1. Master-Sperre anfordern 3. Tablet-Server kontaktieren … 4. Metadaten-Tabelle einlesen 5. nicht zugewiesene Tablets zuweisen

Chubby – Weitere Aufgaben speichert Schema-Informationen für Bigtable Informationen sind für den Start von Bigtable zwingend notwendig sendet ein Server keine regelmäßigen Nachrichten (sog. Heartbeats) an Chubby, verliert er seine Locks Folge: Master weist Tablets neu zu

Auffinden eines Tablets Chubby-Service Root-Tablet (unteilbar) Metadata- Tablet Tabellen- Tablets 1 Zeile pro Metadata-Tablet 1 Zeile pro Tabellen-Tablet Clients nutzen Cache zum speichern von Tablet-Positionen -> die meisten Client-Anfragen gehen direkt an den richtigen Tablet-Server Nach: Bigtable: A Distributed Storage System for Structured Data, Chang, Dean, Gemawat, Hsieh, Wallach, Burrows, Chandra, Fikes und Gruber, 2006/2008

Bigtable Übersicht Master-Server Tablet-Server Chubby Service GFS Tabletzuweisung, Load- Balancing, Metadaten- Operationen Daten verwalten/ ausliefern Verweis auf Root- Tablet, Master-Lock Daten verwalten/ ausliefern Nach: Bigtable: A Distributed Storage System for Structured Data, Chang, Dean, Gemawat, Hsieh, Wallach, Burrows, Chandra, Fikes und Gruber, 2006/2008

Google File System (GFS) von Google entwickeltes, verteiltes Dateisystem zur Speicherung von sehr großen Datenmengen von Bigtable für Persistenz genutzt Daten werden im „SSTable“-Format gespeichert SSTable: persistente, geordnete, unveränderliche Key-Value-Map Warum setzt Bigtable auf GFS?

GFS Hochverfügbarkeit –von allen Daten im GFS werden automatisch mindestens zwei Kopien angelegt –fällt ein Server aus oder wird eine Datei beschädigt, werden automatisch neue Kopien angelegt und verteilt –Serverausfälle werden als Normalfall angesehen: ständige Replikation ist daher entsprechend effizient implementiert -> dazu ein Beispiel

Replikation im GFS In Versuchen wurden Dateiserver im laufenden Betrieb heruntergefahren um einen Ausfall zu simulieren: –Ausfall eines Servers mit Dateien, was 600 GB Daten entsprach  Wiederhergestellt in ca. 23 Minuten, Replikationsrate von 440 MB/s –Gleichzeitiger Ausfall von zwei Servern mit Dateien und 660 GB Daten - dadurch war von 266 Dateien nur noch eine Kopie vorhanden  diese 266 Dateien wurden in 2 Minuten wiederhergestellt

Skalierbarkeit im GFS wird im Wesentlichen durch die Architektur erreicht (dazu gleich mehr) Server können jederzeit hinzugefügt oder entfernt werden Server basieren auf Standardhardware deren Verfügbarkeit am Markt (Einkauf) eher gewährleistet werden kann, als von High-End- Produkten

Architektur des GFS Nach: The Google File System von S. Ghemawat, H. Gobioff, S.-T. Leung, 2003

Bigtable Übersicht Bigtable Client Master-Server Tablet-Server Chubby ServiceGFS Bigtable Client- Bibliothek Tabletzuweisung, Load- Balancing, Metadaten- Operationen Daten verwalten/ ausliefern Persistenz von Daten Logs Verweis auf Root- Tablet, Master-Lock Nach: Bigtable: A Distributed Storage System for Structured Data, Chang, Dean, Gemawat, Hsieh, Wallach, Burrows, Chandra, Fikes und Gruber, 2006/2008 Daten verwalten/ ausliefern

Schreibvorgänge GFS Memtable SSTable-Dateien Schreib-Operation Commit Log MapReduce-Einsatz möglich Nach: Bigtable: A Distributed Storage System for Structured Data, Chang, Dean, Gemawat, Hsieh, Wallach, Burrows, Chandra, Fikes und Gruber, 2006/2008

Minor Compaction GFS Memtable SSTable-DateienCommit Log Memtable erreicht Grenzwert

Major Compaction GFS Memtable SSTable-DateienCommit Log Scheduler

Major Compaction GFS Memtable SSTable-DateienCommit Log Scheduler alle zum Löschen markierten Zellen werden entfernt

Lesevorgänge GFS Memtable SSTable-Dateien Lese-Operation Bloom Filter Commit Log MapReduce-Einsatz möglich Nach: Bigtable: A Distributed Storage System for Structured Data, Chang, Dean, Gemawat, Hsieh, Wallach, Burrows, Chandra, Fikes und Gruber, 2006/2008

Bigtable Übersicht Bigtable Client Master-Server Tablet-Server Chubby ServiceGFS Cluster Management System Bigtable Client- Bibliothek Metadaten- Operationen Tabletzuweisung, Load- Balancing Daten verwalten/ ausliefern Verweis auf Root- Tablet, Master-Lock Monitoring, Ausfallmanagement lesen/ schreiben Nach: Bigtable: A Distributed Storage System for Structured Data, Chang, Dean, Gemawat, Hsieh, Wallach, Burrows, Chandra, Fikes und Gruber, 2006/2008 Daten verwalten/ ausliefern Persistenz von Daten Logs Tablet- Position bestimmen

Vergleich mit relationalen DBMS relationale DBMSBigtable Anfragesprachemeist SQLC++ TransaktionenJanur auf Zeilenbene DatentypbindungJaNein Relationale Operationen JaNein SkalierbarkeitOracle RAC 11g: 100 Nodes MySQL Cluster 5.1: 255 Nodes MS SQL Server 2008 R2 Datacenter Edition: 256 Prozessoren > 500 Tablet-Server

HBase OpenSource-Implementierung von Bigtable Teil des Apache Hadoop-Projekts in Java geschrieben Einsatz von MapReduce möglich von Facebook für den internen Messaging- Dienst verwendet mehr Details in einem der nächsten Vorträge

Weitere Entwicklung – Googles F1 Hybrid aus relationaler- und NoSQL-Datenbank im Mai 2012 von Google vorgestellt Ziele: –Skalierbarkeit von Bigtable –Usability und Funktionalität von SQL- Datenbanken volle SQL-Unterstützung (inkl. relationaler Operationen) MapReduce-Funktionalität beim Lesen automatische Replikation (GFS) hohe Latenz ( ms Schreiben, 5-10 ms Lesen)

Quellen Bigtable: A Distributed Storage System for Structured Data, Chang, Dean, Gemawat, Hsieh, Wallach, Burrows, Chandra, Fikes und Gruber, 2006/2008 The Google File System, Ghemawat, Gobioff, Leung, 2003 F1 - The Fault-Tolerant Distributed RDBMS Supporting Google's Ad Business, Shute, Oancea, Ellner, Handy, Rollins, Samwel, Vingralek, Whipkey, Chen, Jegerlehner, Littlefield, Tong, 2012