Präsentation herunterladen
Die Präsentation wird geladen. Bitte warten
Veröffentlicht von:Liese Teresa Hauer Geändert vor über 7 Jahren
1
Google's BigTable: Ein verteiltes Speichersystem für strukturierte Daten von Florian Eiteljörge
2
Übersicht 1.Was ist Bigtable? 2.Datenmodell 3.Implementierung/Architektur von Bigtable 4.Vergleich mit relationalen DBMS und weitere Entwicklungen
3
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
4
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
5
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.
6
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
7
Zeilen Daten werden in lexikographisch Reihenfolge nach dem Zeilenschlüssel sortiert gespeichert Zeilenschlüssel: beliebiger String (max. 64KB) Transaktionen auf Zeilenebene beschränkt
8
Spalten einzelne Spalte in Bigtable sehr leichtgewichtig Tabellen haben oftmals mehrere tausend Spalten Beispiel Website: jeder Hyperlink einer Website entspricht eigener Spalte
9
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
10
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
11
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
12
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
13
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
14
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
15
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?
16
Chubby sog. Distributed Lock Manager synchronisiert Zugriff auf verteilte Ressourcen jeder Tablet- und Master-Server meldet sich bei Chubby an
17
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
18
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
19
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
20
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
21
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?
22
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
23
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
24
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
25
Architektur des GFS Nach: The Google File System von S. Ghemawat, H. Gobioff, S.-T. Leung, 2003
26
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
27
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
28
Minor Compaction GFS Memtable SSTable-DateienCommit Log Memtable erreicht Grenzwert
29
Major Compaction GFS Memtable SSTable-DateienCommit Log Scheduler
30
Major Compaction GFS Memtable SSTable-DateienCommit Log Scheduler alle zum Löschen markierten Zellen werden entfernt
31
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
32
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
33
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
34
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
35
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 (50-100 ms Schreiben, 5-10 ms Lesen)
36
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
Ähnliche Präsentationen
© 2024 SlidePlayer.org Inc.
All rights reserved.