pptx

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
Herunterladen
Random flashcards
Erstellen Lernkarten