Replikationsübersicht

Mit der Replikation für Bigtable können Sie die Verfügbarkeit und Langlebigkeit Ihrer Daten erhöhen, indem Sie sie über mehrere Regionen oder mehrere Zonen innerhalb derselben Region kopieren. Außerdem können Sie Arbeitslasten isolieren. Dazu leiten Sie verschiedene Arten von Anfragen an verschiedene Cluster weiter.

Auf dieser Seite lernen Sie die Funktionsweise der Replikation in Bigtable kennen sowie verschiedene gängige Anwendungsfälle. Außerdem werden das Konsistenzmodell, das Bigtable bei aktivierter Replikation verwendet, und die Vorgehensweise bei einem Failover von einem Cluster auf einen anderen erläutert.

Beispiele für Einstellungen, die Sie zum Implementieren gängiger Anwendungsfälle verwenden können, finden Sie unter Beispiele für Replikationseinstellungen.
Informationen zum Erstellen einer Instanz mit Replikation finden Sie unter Instanz erstellen.
Informationen zum Aktivieren der Replikation für eine vorhandene Instanz finden Sie unter Cluster hinzufügen.
Informationen zu den mit der Replikation verbundenen Kosten finden Sie unter Preise.

Bevor Sie diese Seite lesen, sollten Sie sich mit den Informationen unter Übersicht über Bigtable vertraut machen.

Funktionsweise der Replikation

Wenn Sie die Replikation in einer Bigtable-Instanz verwenden möchten, erstellen Sie eine neue Instanz mit mehr als einem Cluster oder fügen Sie einer vorhandenen Instanz Cluster hinzu.

Bigtable-Instanzen können Cluster in bis zu acht Bigtable-Regionen haben. In jeder dieser acht Regionen kann die Instanz nur einen Cluster pro Zone enthalten. Wenn Sie beispielsweise eine Instanz in 8 Regionen mit jeweils 3 Zonen erstellen, kann die Instanz bis zu 24 Cluster haben.

Jede Zone in einer Region kann nur einen Cluster enthalten. Wenn Sie Cluster in verschiedenen Zonen oder Regionen haben, können Sie auch dann auf die Daten Ihrer Instanz zugreifen, wenn eine Google Cloud-Zone oder -Region nicht mehr verfügbar ist.

Wenn Sie eine Instanz mit mehr als einem Cluster erstellen, synchronisiert Bigtable sofort Ihre Daten zwischen den Clustern. Dabei wird in jeder Zone, in der Ihre Instanz über einen Cluster verfügt, eine separate, unabhängige Kopie der Daten erstellt. Wenn Sie einer vorhandenen Instanz einen neuen Cluster hinzufügen, kopiert Bigtable ebenso Ihre vorhandenen Daten aus der Zone des ursprünglichen Clusters in die Zone des neuen Clusters und synchronisiert dann Änderungen an Ihren Daten zwischen den Zonen.

Bigtable repliziert alle Änderungen an Ihren Daten automatisch. Dies schließt folgende Arten von Änderungen ein:

Aktualisierungen von Daten in vorhandenen Tabellen
Neue und gelöschte Tabellen
Hinzugefügte und entfernte Spaltenfamilien
Änderungen an der Speicherbereinigungsrichtlinie einer Spaltenfamilie

Dabei sollten Sie beachten, dass die Replikation eine gewisse Latenzzeit hat und dass die Konsistenz zwischen den Replikaten eventuell nicht gegeben ist. Beachten Sie, dass die Replikation eine gewisse Latenz hat und dass die Konsistenz zwischen den Clustern letztendlich auftritt.

Bigtable behandelt jeden Cluster in der Instanz als primären Cluster, sodass Sie in jedem Cluster Lese- und Schreibvorgänge ausführen können. Außerdem lässt sich die Instanz so einrichten, dass Anfragen von verschiedenen Arten von Anwendungen an verschiedene Cluster weitergeleitet werden.

Bevor Sie Cluster zu einer Instanz hinzufügen, sollten Sie sich mit den Einschränkungen vertraut machen, die beim Ändern der Richtlinien für die automatische Speicherbereinigung für replizierte Tabellen gelten.

Leistung

Die Verwendung der Replikation hat Auswirkungen auf die Leistung, die Sie berücksichtigen sollten, wenn Sie eine replizierte Instanz erstellen oder die Replikation aktivieren, indem Sie einen Cluster zu einer Instanz mit einem einzelnen Cluster hinzufügen. So haben beispielsweise replizierte Cluster in verschiedenen Regionen normalerweise eine höhere Replikationslatenz als replizierte Cluster in derselben Region. Darüber hinaus benötigen Cluster in Instanzen mit mehr als einem Cluster häufig mehr Knoten, um den zusätzlichen Aufwand für die Replikation zu bewältigen. Weitere Informationen finden Sie unter Leistung verstehen.

Anwendungsfälle

In diesem Abschnitt werden einige gängige Anwendungsfälle für die Bigtable-Replikation beschrieben. Unter Beispiele für Replikationseinstellungen finden Sie die besten Konfigurationseinstellungen für die einzelnen Anwendungsfälle sowie Implementierungstipps für andere Anwendungsfälle.

Anwendungsbereitstellung und Batchlesevorgänge isolieren

Wenn Sie einen einzelnen Cluster zum Ausführen eines Batchanalysejobs mit zahlreichen großen Lesevorgängen sowie zum Ausführen einer Anwendung verwenden, die sowohl Lese- als auch Schreibvorgänge verarbeitet, ist mit einer Verlangsamung der Vorgänge für den Nutzer zu rechnen. Wenn Sie hingegen die Replikation aktivieren, können Sie Anwendungsprofile mit Single-Cluster-Routing verwenden, um Batchanalysejobs und Anwendungstraffic an unterschiedliche Cluster weiterzuleiten. Die Nutzer Ihrer Anwendung sind somit nicht von den Batchjobs betroffen. Weitere Informationen zur Implementierung dieses Anwendungsfalls.

Verfügbarkeit verbessern

Wenn eine Instanz nur einen einzigen Cluster hat, sind die Langlebigkeit und Verfügbarkeit Ihrer Daten auf die Zone beschränkt, in der sich dieser Cluster befindet. Mit der Replikation kann sowohl die Langlebigkeit als auch die Verfügbarkeit verbessert werden, da separate Kopien Ihrer Daten in mehreren Zonen oder Regionen gespeichert und bei Bedarf automatisch per Failover zwischen Clustern übertragen werden. Weitere Informationen zur Implementierung dieses Anwendungsfalls.

Sicherungen praktisch in Echtzeit bereitstellen

In manchen Fällen müssen Anfragen immer an einen einzigen Cluster weitergeleitet werden, beispielsweise wenn das Lesen veralteter Daten inakzeptabel ist. Allerdings können Sie auch dann die Replikation verwenden. Dabei ist ein Cluster für die Verarbeitung von Anfragen zuständig, während ein anderer Cluster als echtzeitnahe Sicherung dient. Wenn der verarbeitende Cluster nicht mehr verfügbar ist, können Sie die Ausfallzeit durch ein manuelles Failover auf den Sicherungscluster minimieren. Weitere Informationen zur Implementierung dieses Anwendungsfalls.

Globale Präsenz für Ihre Daten gewährleisten

Sie können die Replikation an Standorten auf der ganzen Welt einrichten, um Ihre Daten näher an Ihre Kunden zu bringen. Sie können beispielsweise eine Instanz mit replizierten Clustern in den USA, Europa und Asien erstellen und Anwendungsprofile einrichten, um den Anwendungstraffic zum nächsten Cluster weiterzuleiten. Weitere Informationen zur Implementierung dieses Anwendungsfalls.

Konsistenzmodell

Für die Bigtable-Replikation gilt standardmäßig Eventual Consistency. Dieser Begriff bedeutet, dass eine Änderung, die in einen bestimmten Cluster geschrieben wurde, letztendlich auch in den anderen Clustern in der Instanz gelesen werden kann, allerdings erst, nachdem die Änderung zwischen den Clustern repliziert wurde.

Bei einer intakten Instanz kann sich bei der Replikation eine Verzögerung von ein paar Sekunden oder Minuten ergeben, allerdings nicht von Stunden. Wenn allerdings eine große Datenmenge in einen Cluster geschrieben wird oder ein Cluster überlastet bzw. vorübergehend nicht verfügbar ist, kann es eine Weile dauern, bis die Replikation nachgezogen hat. Die Replikation kann auch länger dauern, wenn die Cluster weit voneinander entfernt sind. Daher sollten Sie normalerweise nicht davon ausgehen, dass Sie immer den zuletzt geschriebenen Wert lesen oder dass eine Wartezeit von ein paar Sekunden nach einem Schreibvorgang für Bigtable ausreicht, um die Änderung zu replizieren.

Wenn Sie eine andere Konsistenzgarantie benötigen, kann Bigtable bei aktivierter Replikation auch Read-Your-Writes-Konsistenz bereitstellen. Diese gewährleistet, dass eine Anwendung nie Daten liest, die älter als die aktuellen Schreibvorgänge sind. Damit Read-Your-Writes-Konsistenz für eine Gruppe von Anwendungen gegeben ist, muss jede Anwendung in der Gruppe ein Anwendungsprofil mit konfiguriertem Single-Cluster-Routing verwenden. Außerdem müssen alle Anwendungsprofile Anfragen an denselben Cluster weiterleiten. Sie können die zusätzlichen Cluster der Instanz gleichzeitig für andere Zwecke verwenden.

Bei einigen Replikationsanwendungsfällen kann Bigtable auch strikte Konsistenz bieten. Diese sorgt dafür, dass alle Anwendungen die Daten im selben Zustand sehen. Für strikte Konsistenz verwenden Sie die zuvor beschriebene Konfiguration des Anwendungsprofils für das Single-Cluster-Routing für Read-Your-Writes-Konsistenz. Die zusätzlichen Cluster der Instanz dürfen jedoch nicht verwendet werden, es sei denn, ein Failover zu einem anderen Cluster muss durchgeführt werden. Anhand der Beispiele für Replikationseinstellungen können Sie feststellen, ob dies für Ihren Anwendungsfall möglich ist.

Konfliktlösung

Jeder Zellenwert in einer Bigtable-Tabelle wird durch das Vierertupel (Zeilenschlüssel, Spaltenfamilie, Spaltenqualifizierer, Zeitstempel) eindeutig identifiziert. Weitere Informationen zu diesen Kennzeichnungen finden Sie unter Bigtable-Speichermodell. In dem seltenen Fall, dass zwei Schreibvorgänge mit demselben identischen Vierertupel an zwei verschiedene Cluster gesendet werden, löst Bigtable den Konflikt automatisch mithilfe eines internen Algorithmus des Typs last write wins auf Grundlage der serverseitigen Zeit auf. Die Bigtable-Implementierung "Last write Wins" (Zeitpunkte des letzten Schreibvorgangs) ist deterministisch. Wenn die Replikation aufholt, haben alle Cluster denselben Wert für das Vierertupel.

Anwendungsprofile

Wenn eine Instanz Replikation verwendet, geben Sie mithilfe von Anwendungsprofilen (bzw. App-Profilen) Routingrichtlinien an. Anwendungsprofile bestimmen außerdem, ob Sie Transaktionen für einzelne Zeilen ausführen können. Dazu gehören Read-Modify-Write-Vorgänge (einschließlich Erhöhungen und Anfügungen) sowie Check-Mutate-Vorgänge (auch bedingte Mutationen oder bedingte Schreibvorgänge genannt).

Weitere Informationen finden Sie unter Anwendungsprofile. Beispiele für Einstellungen, die Sie zum Implementieren gängiger Anwendungsfälle verwenden können, finden Sie unter Beispiele für Replikationseinstellungen.

Routingrichtlinien

Jedes Anwendungsprofil hat eine Routingrichtlinie, die steuert, welche Cluster eingehende Anfragen von Ihren Anwendungen verarbeiten. Zu den Optionen für Routingrichtlinien gehören:

Single-Cluster-Routing: Sendet alle Anfragen an einen von Ihnen angegebenen Cluster.
Multi-Cluster-Routing an einen beliebigen Cluster: Sendet Anfragen an den nächsten verfügbaren Cluster in der Instanz.
Clustergruppen-Routing: Sendet Anfragen an den nächsten verfügbaren Cluster innerhalb einer Clustergruppe, die Sie in den Anwendungsprofileinstellungen angeben.

Failovers

Wenn ein Bigtable-Cluster nicht mehr reagiert, ermöglicht die Replikation für den eingehenden Traffic ein Failover auf einen anderen Cluster in derselben Instanz. Failovers können manuell oder automatisch ausgelöst werden, je nachdem, welches Anwendungsprofil eine Anwendung verwendet und wie das Anwendungsprofil konfiguriert ist.

Weitere Informationen finden Sie unter Failovers.

Zeilenbereiche bei aktivierter Replikation löschen

Mit der Cloud Bigtable Admin API können Sie einen zusammenhängenden Zeilenbereich aus einer Tabelle basierend auf den zugehörigen Zeilenschlüsseln löschen. Bei Instanzen ohne Replikation kann Bigtable einen Zeilenbereich schnell und effizient löschen. Allerdings ist das Löschen eines Zeilenbereichs bei aktivierter Replikation wesentlich zeitaufwendiger und ineffizienter.