Replikationsübersicht

Mit der Replikation in Bigtable können Sie die Verfügbarkeit und Langlebigkeit Ihrer Daten erhöhen. Dazu werden Ihre Daten in mehrere Regionen oder mehrere Zonen innerhalb derselben Region kopiert. 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 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

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 erstellen, die jeweils 3 Zonen haben, kann Ihre 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 der Google Cloud-Zonen oder -Regionen nicht 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 hat eine gewisse Latenzzeit und die Konsistenz zwischen den Clustern ist eventuell nicht gegeben.

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 beim Erstellen einer replizierten Instanz oder beim Aktivieren der Replikation durch Hinzufügen eines Clusters zu einer Instanz mit einem einzelnen Cluster planen sollten. 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 mehreren Clustern 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.

Konsistenzmodelle

In diesem Abschnitt werden die Konsistenzmodelle beschrieben, die Bigtable je nach verwendeter Routing-Richtlinie für die Replikation bereitstellen kann.

Eventual Consistency

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.

Read-Your-Writes-Konsistenz

Sie können die Read-Your-Writes-Konsistenz mit Single-Cluster-Routing erreichen. Mit Multi-Cluster-Routing mit Zeilenaffinitäts-Routing oder wenn sich die Cluster Ihrer Instanz in verschiedenen Regionen befinden, können Sie eine hohe Rate der Read-Your-Writes-Konsistenz erzielen.

Single-Cluster-Routing

Wenn Sie Single-Cluster-Routing verwenden, kann Bigtable bei aktivierter Replikation Read-Your-Writes-Konsistenz bieten. Dieses Konsistenzmodell sorgt dafür, dass eine Anwendung nie Daten liest, die älter als die aktuellen Schreibvorgänge sind.

Jedes verwendete App-Profil muss für Single-Cluster-Routing konfiguriert sein und alle App-Profile müssen Anfragen an denselben Cluster weiterleiten. Sie können die zusätzlichen Cluster der Instanz gleichzeitig für andere Zwecke verwenden.

Multi-Cluster-Routing mit einem Cluster pro Region

Bei Multi-Cluster-Routing leitet Bigtable Anfragen immer an den nächsten Cluster weiter. Wenn sich jeder Cluster in Ihrer Instanz in einer anderen Bigtable-Region befindet und Sie ein Anwendungsprofil verwenden, das für das Multi-Cluster-Routing konfiguriert ist, haben Ihre Daten innerhalb der Quellregion Read-Your-Writes-Konsistenz, sofern kein Failover auftritt.

Routing mit Zeilenaffinität

Wenn Sie eine höhere Rate der Read-Your-Writes-Konsistenz mit Multi-Cluster-Routing zu einer Instanz mit mehr als einem Cluster in einer Region erreichen möchten, können Sie ein Anwendungsprofil verwenden, das für Zeilenaffinitäts-Routing (Sticky-Routing) konfiguriert ist.

Beim Routing mit Zeilenaffinität leitet Bigtable Lese- und Schreibanfragen für einzelne Zeilen basierend auf dem Zeilenschlüssel der Anfrage automatisch an einen bestimmten Cluster weiter. Die Zuordnung zwischen dem Zeilenschlüssel und dem Cluster kann nicht manuell festgelegt werden. Die Konsistenz ist nicht garantiert, da Anfragen aus verschiedenen Gründen fehlschlagen können, z. B. wenn ein Cluster nicht betriebsbereit ist, Netzwerkprobleme auftreten oder der Cluster zu viele Anfragen erhalten hat.

Strikte Konsistenz

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 gängiger 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:
    • Routing an einen beliebigen Cluster: Sendet Anfragen an den nächsten Cluster in der Instanz.
    • Clustergruppen-Routing: Alle Anfragen werden auf von Ihnen angegebene Cluster beschränkt.
    • Zeilenaffinitäts-Routing: Sendet eine Lese- oder Schreibanfrage für eine einzelne Zeile an einen bestimmten Cluster basierend auf dem Zeilenschlüssel der Anfrage. Weitere Informationen finden Sie unter Routing mit Zeilenaffinität.

Failovers

Wenn ein Bigtable-Cluster nicht mehr reagiert, ermöglicht dessen Replikation die Weiterleitung des eingehenden Traffics per Failover an einen anderen Cluster 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