Googles Datenbank F1 versöhnt SQL mit NoSQL
Auf der Konferenz "Very Large Data Bases" hat Google erstmals detailliert Auskunft zu seiner selbstgebauten SQL-Datenbank F1 gegeben. Sie soll die Skalierbarkeit von NoSQL-Systemen mit dem Komfort und der Datensicherheit klassischer Datenbanken verbinden.
- Christian Kirsch
In einem ausführlichen Aufsatz beschreibt Google erstmals Aufbau und Funktionsweise seiner hauseigenen SQL-Datenbank F1, die es Mitte 2012 vorstellt hatte. Sie verwaltet AdWords, das früher auf MySQL-Datenbanken lief und mehr als 100 TByte umfasst. Sie beantwortet bis zu mehrere hunderttausend Anfragen pro Sekunde.
F1 beruht auf einer mehrschichtigen Architektur, deren Grundlage Googles Dateisystem BigTable bildet, jetzt Colossus genannt wird. Es speichert die eigentlichen Daten. Darüber sitzt mit Spanner eine Technik, die wesentliche Datenbankfunktionen bereitstellt. Dazu gehören Persistenz, Caching, Transaktionen und Sharding. Die SQL-Abfragen führt der F1-Server aus, der für das parallele Abarbeiten Kinder starten kann, die jeweils einen Teil der Query abarbeiten. Ein Loadbalancer verteilt zuvor die Anfragen der Clients an die verschiedenen F1-Server.
(Bild: google.com)
Für hierarchische Tabellenbeziehungen, etwa in Master-Detail-Konstellationen, trifft F1 spezielle Vorkehrungen. Dabei muss dem Primärschlüssel der Kind-Tabellen der Fremdschlüssel des Master vorangestellt sein. Physisch verwebt F1 die Master- mit den Child-Zeilen (interleaving), sodass die zu einem Master-Record gehörenden Kind-Zeilen direkt darauf folgen. Das soll laut Google insbesondere bei Updates große Geschwindigkeitsvorteile gegenüber der traditionellen Speicherung bringen. Diese hierarchische Struktur ist jedoch nicht zwingend.
Neben den üblichen skalaren Datentypen nehmen Tabellenspalten in F1 sogenannte Protocol Buffer auf. Damit lassen sich strukturierte Daten ablegen, die Felder auch mehrfach enthalten dürfen. Mit dieser Denormalisierung lasse sich die Geschwindigkeitseinbuße und Komplexität von Joins vermeiden, erläutert Google.
AdWords stelle "harte Anforderungen an die Integrität und Konsistenz der Daten", schreiben die Autoren des F1-Papiers. Deshalb seien die ACID-Garantien (Atomicity, Consistency, Isolation, Durability) unabdingbar gewesen. Die in NoSQL-Kreisen so beliebte "letztendliche Konsistenz" (eventual consistency) führe zu erheblichem Aufwand für Entwickler: Sie müssten extrem komplexe und fehleranfällige Mechanismen entwickeln, um auf veraltete Daten reagieren zu können. Folglich bietet F1 auch die in der traditionellen Welt üblichen Transaktionen in drei verschiedenen Abstufungen: optimistisch, pessimistisch und nur lesend (Snapshot).
Eine Absage an NoSQL ist F1 jedoch keineswegs: Das von Google entwickelte Map-Reduce-Verfahren lässt sich auch damit nutzen. Das dafür verwendete Framework greift jedoch aus Performance-Gründen vorbei an den F1-Servern direkt auf die Spanner-Schicht zu. (ck)
