Routingoptionen

Wenn Sie Anfragen von einer Anwendung an Bigtable senden, verwenden Sie ein App-Profil, das Bigtable mitteilt, wie die Anfragen verarbeitet werden sollen. In einem App-Profil ist die Routingrichtlinie für die Anfragen angegeben. Bei Instanzen mit Replikation wird mit der Routingrichtlinie festgelegt, welche Cluster die Anfragen erhalten und wie Failover verarbeitet werden.

In diesem Dokument werden die Routingrichtlinien beschrieben, die für einen standardmäßigen App-Profil.

Routingrichtlinien sind besonders wichtig für Anwendungsfälle der Arbeitslastisolierung, wenn Sie Data Boost (Vorabversion) nicht verwenden können. Sie können sie in in Verbindung mit Anfrageprioritäten.

Routingrichtlinien wirken sich nicht auf die Replikation aus, aber Sie sollten wissen, Bigtable Replikation funktioniert, bevor Sie diese Seite lesen. Lesen Sie auch den Hilfeartikel Failover.

Single-Cluster-Routing

Eine Single-Cluster-Routingrichtlinie leitet alle Anfragen an einen Cluster in Ihrem Instanz. Wenn dieser Cluster nicht mehr verfügbar ist, müssen Sie manuell ein Failover auf einen anderen Cluster machen.

Dies ist die einzige Routingrichtlinie, mit der Sie Transaktionen für einzelne Zeilen aktivieren können.

Eine replizierte Instanz bietet normalerweise Eventual Consistency. Sie können jedoch Read-Your-Writes Einheitlichkeit für eine Arbeitslast in einer replizierten Instanz, wenn Sie dafür ein Anwendungsprofil konfigurieren mit dem Single-Cluster-Routing Lese- und Schreibanfragen an den denselben Cluster. Je nach Arbeitslastanforderungen können Sie Traffic für zusätzliche Arbeitslasten in der replizierten Instanz an andere Cluster in der Instanz weiterleiten.

Multi-Cluster-Routing

Eine Multi-Cluster-Routingrichtlinie leitet Anfragen, die Sie an eine Instanz senden, an der nächstgelegenen Region, in der sich die Instanz befindet. Wenn der Cluster nicht verfügbar ist, wird der Traffic automatisch auf den nächstgelegenen Cluster verfügbar.

Diese Konfiguration bietet Eventual Consistency. Sie können die Option für einzelne Zeilen nicht aktivieren mit Multi-Cluster-Routing, da Transaktionen für einzelne Zeilen Ursache Konflikte wenn Sie Multi-Cluster-Routing verwenden. Weitere Informationen finden Sie unter Transaktionen mit einer Zeile.

Verwenden Sie Multi-Cluster-Routing, wenn Sie Hochverfügbarkeit möchten. Empfohlene Instanzkonfigurationen und weitere Informationen finden Sie unter Hochverfügbarkeit erstellen.

Die beiden Arten von Multi-Cluster-Routing sind beliebiger Cluster und Cluster Gruppe.

Beliebiges Clusterrouting

Bei diesem Routing kann jeder Cluster in der Instanz Anfragen empfangen und für das Failover verwendet werden.

Clustergruppen-Routing

Wenn Sie einen oder mehrere Cluster einer Instanz vom möglichen Failover ausschließen möchten, können Sie das Clustergruppen-Routing verwenden. Bei dieser Form des Multi-Cluster-Routings können Sie eine Teilmenge von Clustern angeben, an die ein Anwendungsprofil Traffic senden kann. Das kann hilfreich sein, wenn Sie einen Cluster für eine separate Arbeitslast reservieren möchten.

Transaktionen für einzelne Zeilen

In Bigtable-Mutationen, wie Lese-, Schreib- und Löschanfragen, sind sie auf Zeilenebene immer atomar. Dazu gehören Mutationen in mehreren Spalten in einer einzelnen Zeile, solange sie im selben Mutationsvorgang enthalten sind. Bigtable unterstützt keine Transaktionen, die mehr als eine Zeile atomar aktualisieren.

Allerdings unterstützt Bigtable verschiedene Schreibvorgänge, die eine Transaktion in anderen Datenbanken erfordern. In der Praxis verwendet Bigtable Transaktionen für einzelne Zeilen, um diese Vorgänge auszuführen. Diese Vorgänge umfassen sowohl Lese- als auch Schreibzugriffe, die alle atomar ausgeführt werden. Trotzdem sind die Vorgänge nur auf Zeilenebene atomar:

  • Read-Modify-Write-Vorgänge, einschließlich Erhöhungen und Anfügungen. Ein Read-Change-Write-Vorgang liest value; erhöht den vorhandenen Wert oder ergänzt ihn. und schreibt den aktualisierten Wert in die Tabelle ein.
  • Check-Mutate-Vorgänge, die auch bedingte Mutationen oder bedingte Schreibvorgänge genannt werden. Bei einem Check-Mutate-Vorgang prüft Bigtable eine Zeile, um festzustellen, ob eine angegebene Bedingung erfüllt wird. Wenn dies der Fall ist, schreibt Bigtable neue Werte in die Zeile.

Konflikte zwischen Transaktionen für einzelne Zeilen

Jeder Cluster in einer Bigtable-Instanz ist ein primärer Cluster, der sowohl Lese- als auch Schreibvorgänge akzeptiert. Vorgänge, die Transaktionen für einzelne Zeilen erfordern, können zu Problemen mit replizierten Instanzen führen.

Wenn Ihr Anwendungsfall dies zulässt, können Sie diese Konflikte durch die Verwendung von Aggregaten vermeiden. Wenn Sie eine Anfrage zum Hinzufügen an ein aggregiertes Feld senden, wird der neue Wert mit den vorhandenen Wert. Mit Zusammenfassungen können Sie eine laufende Summe oder einen Zähler führen. Weitere Informationen finden Sie unter Werte zum Zeitpunkt der Schreibvorgänge aggregieren.

Angenommen, Sie haben eine Tabelle, in der Sie Daten für ein Ticketsystem speichern. Sie verwenden einen Ganzzahlzähler, um die Anzahl der verkauften Tickets zu speichern. Jedes Mal, wenn Sie ein Ticket verkaufen, sendet Ihre Anwendung einen Lesen-Ändern-Schreiben-Vorgang, um den Zähler um 1 zu erhöhen.

Wenn Ihre Instanz über einen Cluster verfügt, können Clientanwendungen gleichzeitig Tickets verkaufen und die Zähler ohne Datenverlust erhöhen, da die Anfragen atomar in der Reihenfolge verarbeitet werden, in der sie von diesem einzelnen Cluster empfangen werden.

Wenn Ihre Instanz dagegen mehrere Cluster hat und Ihr Anwendungsprofil Multi-Cluster-Routing zulässt, werden gleichzeitige Anfragen zur Erhöhung des Zählers möglicherweise an verschiedene Cluster gesendet und dann an die anderen Cluster in der Instanz repliziert. Wenn Sie zwei Erhöhungsanfragen zur gleichen Zeit senden, die an verschiedene Cluster weitergeleitet werden, beendet jeder seine Transaktion, ohne vom anderen zu „wissen“. Der Zähler für jeden Cluster wird um eins erhöht. Wenn die Daten in den anderen Cluster repliziert werden, kann Bigtable nicht wissen, dass Sie den Wert um 2 erhöhen möchten.

Damit Sie unbeabsichtigte Ergebnisse vermeiden, führt Bigtable Folgendes aus:

  • Jedes Anwendungsprofil muss angeben, ob Transaktionen für einzelne Zeilen zulässig sind.
  • Außerdem wird verhindert, dass Sie Transaktionen für einzelne Zeilen in einem Anwendungsprofil mit Multi-Cluster-Routing aktivieren, da es keine sichere Möglichkeit zur gleichzeitigen Aktivierung beider Funktionen gibt.
  • Sie erhalten eine Benachrichtigung, wenn Transaktionen für einzelne Zeilen in zwei oder mehr Anwendungsprofilen aktiviert werden, die Single-Cluster-Routing verwenden und auf verschiedene Cluster verweisen. Wenn Sie diese Art der Konfiguration erstellen möchten, müssen Sie sicherstellen, in Konflikt stehende Read-Change-Write- oder Check-Mutate-Anfragen an verschiedene Cluster.

Nächste Schritte