Mit Ansätzen wie Mapreduce und Bigtable hat Google die Art und Weise, wie große Datenmengen verarbeitet werden, maßgeblich beeinflusst. Mapreduce ist die Grundlage von Apache Hadoop, das heute von vielen Unternehmen eingesetzt wird, bei HBase wurde nach dem Vorbild von Bigtable entwickelt. Die Idee hinter Mapreduce und auch Bigtable hatte Google zuvor jeweils in Form von wissenschaftlichen Aufsätzen erläutert. Nun erläutert Google mit Spanner ein System, das bei Google Mapreduce und Bigtable ablöst und einige neue Ansätze enthält.

Google selbst setzt Spanner seit rund drei Jahren ein. Es ist die Grundlage für F1, der Datenbank hinter Googles Werbenetzwerk. Google hat dabei MySQL durch F1 ersetzt, denn F1 soll so ausfallsicher und skalierbar sein wie NoSQL-Datenbanken, dabei aber den Vorteil einer SQL-Datenbank bieten. Möglich macht dies Spanner.

Googles global verteilte Datenbank

Google beschreibt Spanner als global verteilte Datenbank, die skalierbar, multiversional und synchron repliziert wird. Dabei handle es sich um das erste System, das Daten im globalen Maßstab verteilt und dennoch aus externer Sicht konsistente, verteilte Transaktionen unterstützt. Dabei soll Spanner eine hohe Verfügbarkeit und minimale Latenzen beim Lesen und Schreiben von Daten bieten.

Der Schlüssel dazu sind Zeitstempel, partielles Locking und synchrone Replikation. Spanner basiert zwar auf Ideen aus Bigtable, ist aber ein deutlicher Schritt hin zu einem global verteilten relationalen Datenbankmanagementsystem. So soll Spanner das von Jeff Dean 2009 formulierte Ziel erreichen: ein System, das mehrere Exabyte (10^18 Byte) Daten in mehreren Billionen Verzeichnissen auf mehreren Millionen Maschinen in tausenden Rechenzentren und einem Namensraum auf der ganzen Welt verteilt.

Letztendlich soll Spanner so extern konsistente, globale Schreibtransaktionen mit synchroner Replikation, nicht blockierende Lesezugriffe auf Daten der Vergangenheit und lockfreie Nur-Lese-Transaktionen bieten. Die Daten werden dabei semirelational gespeichert, wobei kleine Schemaänderungen vorgenommen werden können, ohne dass dazu die gesamte Datenbank gesperrt werden muss. Die Abfrage erfolgt über ein SQL-ähnliches Interface, die Verteilung der Daten erledigt Spanner vollautomatisch, einschließlich Auto-Rebalancing. Die Kontrolle über die Datenreplikation und -verortung liegt aber bei der jeweiligen Applikation.

Wie Spanner funktioniert

Die große Neuerung an Spanner ist dessen Umgang mit Zeit. Sämtliche Einträge in der Datenbank werden mit einem Zeitstempel versehen, so dass Spanner jederzeit erkennen kann, welcher Eintrag neuer ist. Da dies aber über mehrere auf der ganzen Welt verteilte Rechenzentren funktionieren soll, muss das System aber damit umgehen können, dass die Zeit in den einzelnen Systemen voneinander abweicht.

Dazu setzt Google zum einen auf ein System aus GPS-Empfängern und Atomuhren in den Rechenzentren, um dafür zu sorgen, dass die Zeit überall möglichst synchron gehalten wird. Zum anderen führt Google aber einen Unsicherheitsfaktor ein, der die trotz GPS und Atomuhren auftretenden Zeitdifferenzen ausgleicht. Das sich daraus ergebende Zeitintervall nennt Google "TrueTime".

Truetime garantiert, dass eine Transaktion in dem angegebenen Intervall stattgefunden hat, ganz gleich, welches System in welchem Rechenzentrum an welchem Ort auf der Welt diese abgewickelt hat. Das Intervall wird ständig angepasst, wobei Spanner davon ausgeht, dass die Abweichung der Uhren in den einzelnen Systemen steigt, bis diese wieder mit einem Zeit-Master abgeglichen werden. Die angenommene Abweichung schwankt bei Google zwischen 1 und 7 ms. Sie liegt im Mittel bei 4 ms. Alle 30 Sekunden holt sich der Zeit-Deamon die aktuelle Zeit.

Lesende Zugriffe verwenden immer einen Zeitstempel: Entweder wird dieser explizit angegeben oder vom System automatisch zugewiesen. So kann sichergestellt werden, dass Antworten nur von einem replizierenden Server kommen, dessen Datenbestand aktuell genug ist.

Die Zeitstempel werden auch bei Schemaänderungen genutzt. Spanner verfügt dazu über eine spezielle Transaktion für atomare Schemaänderungen, die die Datenbank nicht blockieren. Einer solchen Schemaänderung wird ein in der Zukunft liegender Zeitstempel zugewiesen, ab dem dann alle Systeme das neue Schema nutzen.