Google`s BigTable: Ein verteiltes Speichersystem für strukturierte
Werbung
Google's BigTable: Ein verteiltes Speichersystem für strukturierte Daten von Florian Eiteljörge Übersicht 1. 2. 3. 4. Was ist Bigtable? Datenmodell Implementierung/Architektur von Bigtable 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 Master-Server Tablet-Server Tablet-Server Tablet-Server Daten verwalten/ ausliefern Daten verwalten/ ausliefern Daten verwalten/ ausliefern Nach: Bigtable: A Distributed Storage System for Structured Data, Chang, Dean, Gemawat, Hsieh, Wallach, Burrows, Chandra, Fikes und Gruber, 2006/2008 Master-Server • pro Cluster existiert nur ein aktiver MasterServer • 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 Start eines Master-Servers 4. Metadaten-Tabelle einlesen 1. Master-Sperre anfordern Master-Server Chubby-Service 2. nach Tablet-Servern scannen 3. Tablet-Server kontaktieren 5. nicht zugewiesene Tablets zuweisen Tablet-Server Tablet-Server Tablet-Server … 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 MetadataTablet TabellenTablets Root-Tablet (unteilbar) Chubby-Service Clients nutzen Cache zum speichern von Tablet-Positionen -> die meisten Client-Anfragen gehen direkt an den richtigen Tablet-Server 1 Zeile pro Metadata-Tablet 1 Zeile pro Tabellen-Tablet 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 Tabletzuweisung, LoadBalancing, MetadatenOperationen Tablet-Server Tablet-Server Tablet-Server Daten verwalten/ ausliefern Daten verwalten/ ausliefern Daten verwalten/ ausliefern GFS Chubby Service Verweis auf RootTablet, Master-Lock 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 15.000 Dateien, was 600 GB Daten entsprach Wiederhergestellt in ca. 23 Minuten, Replikationsrate von 440 MB/s – Gleichzeitiger Ausfall von zwei Servern mit 16.000 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-EndProdukten Architektur des GFS Nach: The Google File System von S. Ghemawat, H. Gobioff, S.-T. Leung, 2003 Bigtable Übersicht Bigtable Client Bigtable ClientBibliothek Master-Server Tabletzuweisung, LoadBalancing, MetadatenOperationen Tablet-Server Tablet-Server Tablet-Server Daten verwalten/ ausliefern Daten verwalten/ ausliefern Daten verwalten/ ausliefern GFS Chubby Service Persistenz von Daten Logs Verweis auf RootTablet, Master-Lock Nach: Bigtable: A Distributed Storage System for Structured Data, Chang, Dean, Gemawat, Hsieh, Wallach, Burrows, Chandra, Fikes und Gruber, 2006/2008 Schreibvorgänge MapReduce-Einsatz möglich Memtable Schreib-Operation GFS Commit Log SSTable-Dateien Nach: Bigtable: A Distributed Storage System for Structured Data, Chang, Dean, Gemawat, Hsieh, Wallach, Burrows, Chandra, Fikes und Gruber, 2006/2008 Minor Compaction Memtable Memtable erreicht Grenzwert GFS Commit Log SSTable-Dateien Major Compaction Memtable Scheduler Commit Log SSTable-Dateien GFS Major Compaction Memtable Scheduler alle zum Löschen markierten Zellen werden entfernt GFS Commit Log SSTable-Dateien Lesevorgänge MapReduce-Einsatz möglich Memtable Lese-Operation Bloom Filter GFS Commit Log SSTable-Dateien 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 MetadatenOperationen Bigtable ClientBibliothek Master-Server Tabletzuweisung, LoadBalancing lesen/ schreiben TabletPosition bestimmen Tablet-Server Tablet-Server Tablet-Server Daten verwalten/ ausliefern Daten verwalten/ ausliefern Daten verwalten/ ausliefern Cluster Management System GFS Chubby Service Monitoring, Ausfallmanagement Persistenz von Daten Logs Verweis auf RootTablet, Master-Lock Nach: Bigtable: A Distributed Storage System for Structured Data, Chang, Dean, Gemawat, Hsieh, Wallach, Burrows, Chandra, Fikes und Gruber, 2006/2008 Vergleich mit relationalen DBMS relationale DBMS Bigtable Anfragesprache meist SQL C++ Transaktionen Ja nur auf Zeilenbene Datentypbindung Ja Nein Relationale Operationen Ja Nein Skalierbarkeit • Oracle 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 MessagingDienst 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 SQLDatenbanken • volle SQL-Unterstützung (inkl. relationaler Operationen) • MapReduce-Funktionalität beim Lesen • automatische Replikation (GFS) • hohe Latenz (50-100 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
