Replikationsübersicht

Mit Replikation für Bigtable können Sie die Verfügbarkeit erhöhen und Langlebigkeit Ihrer Daten durch Kopieren über mehrere Regionen oder mehrere Zonen hinweg in derselben Region. 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 häufiger Anwendungsfälle verwenden können, finden Sie unter Beispiele für Replikationskonfigurationen.
  • 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

Zur Verwendung einer Replikation in einer Bigtable-Instanz, müssen Sie eine neue Instanz mit mehr als einem Cluster erstellen oder einer vorhandenen Instanz Cluster hinzufügen.

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 erstellen, die jeweils 3 Zonen haben, kann Ihre Instanz bis zu 24 Cluster haben.

Jede Zone in einer Region kann nur einen Cluster enthalten. Cluster in verschiedenen Zonen oder Regionen können Sie auf die Daten Ihrer Instanz 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

Die Replikation weist eine gewisse Latenz auf und die Konsistenz zwischen Clustern kann letztendlich auftreten.

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 in einer Instanz erstellen, sollten Sie sich mit den Einschränkungen vertraut machen, die beim Ändern von Richtlinien zur automatischen Speicherbereinigung für replizierte Tabellen gelten.

Leistung

Die Verwendung der Replikation hat Auswirkungen auf die Leistung, die Sie ab diesem Zeitpunkt einplanen sollten Sie erstellen eine replizierte Instanz oder aktivieren die Replikation, indem Sie einen Cluster hinzufügen auf eine Single-Cluster-Instanz. So haben beispielsweise replizierte Cluster in verschiedenen Regionen normalerweise eine höhere Replikationslatenz als replizierte Cluster in derselben Region. Außerdem werden Cluster in Instanzen mit mehr als einem ein Cluster benötigt häufig mehr Knoten, um den zusätzlichen Aufwand der Replikationsverarbeitung 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. Um strikte Konsistenz zu erreichen, verwenden Sie die oben beschriebene App-Profilkonfiguration mit Single-Cluster-Routing für Read-Your-Writes-Konsistenz. Dabei dürfen Sie jedoch nicht die zusätzlichen Cluster der Instanz verwenden, es sei denn, es muss ein Failover zu einem anderen Cluster erfolgen. 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 häufiger Anwendungsfälle verwenden können, finden Sie unter Beispiele für Replikationskonfigurationen.

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 eingehende, für das Failover des Traffics 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 auf Basis der zugehörigen Zeilenschlüssel 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.

Nächste Schritte