TrueTime ist ein hochverfügbarer verteilter Zeitgeber, der für Anwendungen auf allen Google-Servern bereitgestellt 1 wird. TrueTime ermöglicht es Anwendungen, monoton steigende Zeitstempel zu generieren: Eine Anwendung kann einen Zeitstempel T berechnen, der garantiert größer als jeder Zeitstempel T' ist, wenn T' vor dem Erzeugen von T beendet wurde. Diese Garantie gilt für alle Server und Zeitstempel.
Dieses Feature von TrueTime wird von Spanner verwendet, um Zeitstempeln Transaktionen. Insbesondere wird jeder Transaktion ein Zeitstempel zugewiesen, der den Zeitpunkt widerspiegelt, ab dem Spanner das Ereignis als eingetreten einstuft. Da Spanner die versionsübergreifende Gleichzeitigkeitserkennung verwendet, können Spanner-Clients dank der Reihenfolgegarantie für Zeitstempel konsistente Lesevorgänge über eine ganze Datenbank hinweg ausführen (sogar über mehrere Cloud-Regionen hinweg), ohne Schreibvorgänge zu blockieren.
Externe Konsistenz
Spanner bietet für Kunden die strengste Gleichzeitigkeitserkennung. Garantien für Transaktionen, die als extern Einheitlichkeit2 Bei externer Konsistenz verhält sich das System wie wenn alle Transaktionen sequenziell ausgeführt werden, obwohl Spanner die Daten auf mehreren Servern (und möglicherweise auf mehreren Rechenzentren) für höhere Leistung und Verfügbarkeit. Wenn eine Transaktion abgeschlossen ist, bevor der Commit einer anderen Transaktion beginnt, garantiert das System, dass Kunden nie einen Zustand sehen, der die Auswirkung der zweiten Transaktion enthält, aber nicht die der ersten. Cloud Spanner ist intuitiv, semantisch nicht von einer Datenbank mit einem einzelnen Rechner zu unterscheiden ist. Obwohl es so starke Garantien bietet, ermöglicht Spanner es Anwendungen, Leistungen zu erzielen, die mit Datenbanken mit schwächeren Garantien (und im Gegenzug besseren Leistungen) zu vergleichen sind. Zum Beispiel Datenbanken, die Snapshots unterstützen, -Isolierung, lässt Spanner Schreibvorgänge zu, ohne durch schreibgeschützten Transaktionen, ohne jedoch die Anomalien aufzuzeigen, -Isolation ermöglicht.
Externe Konsistenz vereinfacht die Anwendungsentwicklung erheblich. Angenommen, Sie haben eine Banking-Anwendung auf Spanner erstellt und einer Ihrer Kunden beginnt mit 50 € im Bankkonto und 50 $ auf dem Sparkonto. Ihre Anwendung startet dann einen Workflow, in dem zuerst eine Transaktion T1 übergeben wird, um 200 € auf das Sparkonto zu überweisen, und anschließend eine zweite Transaktion T2 ausgeführt wird, um eine Lastschrift über 150 € von dem Bankkonto abzubuchen. Nehmen wir weiter an, dass am Ende des Tages negative Salden auf einem Konto automatisch von anderen Konten gedeckt werden und ein Kunde eine Strafe erhält, wenn der Gesamtbetrag aller Konten zu einem Zeitpunkt an diesem Tages negativ ist. Externe Konsistenz garantiert, dass alle Leser der Datenbank erkennen, dass die Zahlung T2 vor der Abbuchung T1 stattgefunden hat, weil der Commit von T1 nach dem von T2 anfängt. Anders ausgedrückt garantiert externe Konsistenz, dass niemand jemals einen Zustand sehen wird, bei dem T2 vor T1 auftritt. Das heißt, die Abbuchung wird nie eine Strafe aufgrund unzureichender Mittel nach sich ziehen.
Eine traditionelle Datenbank, die Speicher mit einer Version und eine strikte Zweiphasensperrung verwendet, bietet externe Konsistenz. Leider erhält ein solches System jedes Mal, wenn Ihre Anwendung die aktuellen Daten lesen möchte (auch "starker Lesevorgang" genannt), eine Lesesperre auf den Daten, wodurch Schreibvorgänge an den gelesenen Daten blockiert werden.
Zeitstempel und versionsübergreifende Gleichzeitigkeitserkennung (Multi-Version Concurrency Control, MVCC)
Für das Lesen ohne Blockierung von Schreibvorgängen bieten Spanner und viele andere Datenbanksysteme mehrere unveränderliche Datenversionen aufbewahren (oft als Multiversions-Nebenläufigkeit bezeichnet) -Kontrolle). Ein Schreibvorgang erstellt eine neue unveränderliche Version, deren Zeitstempel dem Zeitstempel der Schreibtransaktion entspricht. Ein "Snapshot-Lesevorgang" bei einem Zeitstempel gibt den Wert der neuesten Version vor diesem Zeitstempel zurück und muss Schreibvorgänge nicht blockieren. Daher ist es wichtig, dass die den Versionen zugewiesenen Zeitstempel die Reihenfolge einhalten, in der Transaktionen übergeben werden können. Wir nennen diese Eigenschaft "ordnungsgemäße Zeitstempel". Beachten Sie, dass die Existenz eines ordnungsgemäßen Zeitstempels äquivalent zur externen Konsistenz ist.
Warum ordnungsgemäße Zeitstempel wichtig sind, sehen Sie am Online-Banking-Beispiel aus dem vorherigen Abschnitt. Ohne ordnungsgemäße Zeitstempel könnte T2 ein Zeitstempel zugewiesen werden, der früher als der Zeitstempel ist, der T1 zugewiesen ist (wenn beispielsweise ein hypothetisches System lokale Uhren anstelle von TrueTime verwendet und die Uhr des Servers, der T2 verarbeitet, etwas langsamer geht). Ein Snapshot-Lesevorgang könnte die Abbuchung von T2 widerspiegeln, aber nicht die Zahlung T1, obwohl der Kunde gesehen hat, dass die Zahlung beendet war, bevor die Abbuchung gestartet wurde.
Es ist einfach, richtige Zeitstempel für eine Datenbank mit einem einzelnen Gerät zuzuweisen (zum Beispiel können Sie Zeitstempel einfach von einem globalen, monoton ansteigenden Zähler zuweisen lassen). Die Umsetzung in einem weitverbreiteten System wie Spanner, welche Server weltweit Zeitstempel zuweisen müssen, schwierig zu erledigen ist.
Spanner hängt von TrueTime ab, um eine kontinuierlich steigende Zahl von Zeitstempel. Spanner verwendet diese Zeitstempel auf zwei Arten. Erstens werden diese als ordnungsgemäße Zeitstempel für Schreibtransaktionen verwendet, ohne dass eine globale Kommunikation erforderlich ist. Zweitens werden sie als Zeitstempel für starke Lesevorgänge verwendet, was ermöglicht, dass starke Lesevorgänge in einer Kommunikationsrunde ausgeführt werden können, selbst bei starken Lesevorgängen, die sich über mehrere Server erstrecken.
FAQ
Welche Konsistenzgarantien bietet Spanner?
Spanner bietet externe Konsistenz, die die strengste Konsistenzeigenschaft für Transaktionsverarbeitungssysteme ist. Diese Konsistenzeigenschaft wird von allen Transaktionen in Spanner erfüllt, nicht nur von den Transaktionen innerhalb einer Partition. Externe Konsistenz gibt an, dass Spanner Transaktionen auf eine Art und Weise ausführt, die von einem System, in dem die Transaktionen seriell ausgeführt werden, nicht zu unterscheiden ist. Außerdem stimmt die serielle Reihenfolge mit der Reihenfolge überein, in der Transaktionen festgeschrieben werden können. Da die für Transaktionen erzeugten Zeitstempel der seriellen Reihenfolge entsprechen, gilt Folgendes: Wenn ein Client den Start des Festschreibungsvorgangs für eine Transaktion T2 erkennt, nachdem eine andere Transaktion T1 abgeschlossen ist, ordnet das System einen Zeitstempel für T2 zu, der höher als der Zeitstempel für T1 ist.
Bietet Spanner Linearisierbarkeit?
Ja. Tatsächlich bietet Spanner externe Konsistenz, was eine als Linearisierbarkeit, da die Linearisierbarkeit nichts aussagt, zum Verhalten von Transaktionen. Die Linearisierbarkeit ist eine Eigenschaft gleichzeitig existierender Objekte, die atomische (kleinstmögliche) Lese- und Schreibvorgänge unterstützen. Ein Objekt wird in einer Datenbank in der Regel durch eine einzelne Zeile oder eine einzelne Zelle repräsentiert. Die externe Konsistenz ist eine Eigenschaft von Transaktionsverarbeitungssystemen, bei denen Transaktionen, die mehrere Lese- und Schreibvorgänge enthalten, von Clients dynamisch synthetisiert werden. Die Linearisierbarkeit kann als Sonderfall der externen Konsistenz betrachtet werden, bei dem eine Transaktion nur einen einzigen Lese- oder Schreibvorgang für ein einziges Objekt enthalten darf.
Bietet Spanner Serialisierbarkeit?
Ja. Spanner bietet mit der externen Konsistenz eine Eigenschaft, die die Serialisierbarkeit noch übertrifft. Ein Transaktionsverarbeitungssystem gilt als serialisierbar, wenn es Transaktionen auf eine Weise ausführt, die von einem System mit serieller Transaktionsausführung nicht zu unterscheiden ist. Spanner garantiert auch dass die serielle Reihenfolge mit der Reihenfolge übereinstimmt, in der die Transaktionen Commit durchgeführt wird.
Betrachten Sie noch einmal das zuvor verwendete Banking-Beispiel. In einem System, das Serialisierbarkeit ohne externe Konsistenz bietet, könnte das System die Reihenfolge ändern, obwohl der Kunde T1 und dann T2 sequenziell ausführt. Dies könnte dazu führen, dass für die Lastschrift eine Strafgebühr aufgrund von zu geringem Guthaben fällig wird.
Bietet Spanner hohe Konsistenz?
Ja. Tatsächlich bietet Spanner externe Konsistenz, was eine als Strong Consistency. Der Standardmodus für Lesevorgänge in Spanner ist „strong“ (stark), was garantiert, dass die Auswirkungen aller Transaktionen die vor dem Start des Vorgangs übergeben wurden, unabhängig davon, den Lesevorgang empfängt.
Was unterscheidet die "hohe Konsistenz" von der externen Konsistenz?
Ein Replikationsprotokoll weist eine "hohe Konsistenz" auf, wenn die replizierten Objekte linearisierbar sind. Ähnlich wie bei der Linearisierbarkeit ist auch die "hohe Konsistenz" schwächer einzustufen als die "externe Konsistenz", da sie nichts über das Verhalten der Transaktionen aussagt.
Bietet Spanner Eventual Consistency (verzögerte Konsistenz)?
Spanner bietet externe Konsistenz, was eine viel stärkere Eigenschaft als die verzögerte Konsistenz ist. Bei Eventual Consistency werden schwächere Garantien in Kauf genommen, um eine höhere Leistung zu erzielen. Eventual Consistency ist problematisch, da sie ermöglicht, dass die Leser auf einen Datenbankzustand zugreifen können, der nie real vorhanden war (z. B. könnte ein Lesevorgang einen Zustand abrufen, bei dem Transaktion B festgeschrieben ist, Transaktion A jedoch nicht, obwohl A vor B ausgeführt wurde). Spanner bietet veraltete Lesevorgänge, die ähnliche Leistungsvorteile wie Eventual Consistency bieten, jedoch mit viel höheren Konsistenzgarantien. Ein veralteter Lesevorgang gibt Daten von einem „alten“ Zeitstempel zurück, bei dem keine Schreibvorgänge blockiert werden können, da frühere Datenversionen unveränderlich sind.