Routingoptionen

Wenn Sie Anfragen von einer Anwendung an Bigtable senden, verwenden Sie ein Anwendungsprofil, das Bigtable mitteilt, wie die Anfragen zu verarbeiten sind. Ein Anwendungsprofil gibt die Routingrichtlinie für die Anfragen an. Bei Instanzen mit Replikation steuert die Routingrichtlinie, welche Cluster die Anfragen erhalten und wie Failover verarbeitet werden.

In diesem Dokument werden die Routingrichtlinien beschrieben, die für ein standardmäßiges Anwendungsprofil verfügbar sind.

Routingrichtlinien sind besonders wichtig für Anwendungsfälle zur Arbeitslastisolierung, in denen Data Boost nicht verwendet werden kann (Vorabversion). Sie können sie in Verbindung mit Anfrageprioritäten konfigurieren.

Routingrichtlinien wirken sich nicht auf die Replikation aus, aber Sie sollten mit der Funktionsweise der Bigtable-Replikation vertraut sein, bevor Sie diese Seite lesen. Außerdem sollten Sie Failovers lesen.

Single-Cluster-Routing

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

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

Eine replizierte Instanz sorgt normalerweise für Eventual Consistency. Sie können jedoch Read-Your-Writes-Konsistenz für eine Arbeitslast in einer replizierten Instanz erreichen, wenn Sie ein Anwendungsprofil für diese Arbeitslast so konfigurieren, dass Single-Cluster-Routing zum Senden von Lese- und Schreibanfragen an denselben Cluster verwendet wird. Sie können Traffic für zusätzliche Arbeitslasten auf der replizierten Instanz je nach Arbeitslastanforderungen an andere Cluster in der Instanz weiterleiten.

Multi-Cluster-Routing

Eine Multi-Cluster-Routingrichtlinie leitet Anfragen, die Sie an eine Instanz senden, an die nächstgelegene Region weiter, in der sich die Instanz mit einem Cluster befindet. Wenn der Cluster nicht mehr verfügbar ist, wird der Traffic automatisch auf den nächsten verfügbaren Cluster umgestellt.

Diese Konfiguration bietet Eventual Consistency. Sie können keine Transaktionen für einzelne Zeilen mit Multi-Cluster-Routing aktivieren, da Transaktionen für einzelne Zeilen Datenkonflikte verursachen können, wenn Sie Multi-Cluster-Routing verwenden. Weitere Informationen finden Sie unter Transaktionen für einzelne Zeilen.

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 Clustergruppe.

Beliebiges Clusterrouting

Clusterrouting macht jeden Cluster in der Instanz für den Empfang von Anfragen und für das Failover verfügbar.

Clustergruppenrouting

Wenn Sie einen oder mehrere Cluster einer Instanz vom möglichen Failover ausschließen möchten, können Sie Clustergruppenrouting verwenden. Mit dieser Form des Multi-Cluster-Routings können Sie eine Teilmenge von Clustern angeben, an die ein Anwendungsprofil Traffic senden kann. Dies 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 Inkrementen und Anfügen. Bei einem Read-Modify-Write-Vorgang wird ein vorhandener Wert gelesen, der vorhandene Wert erhöht oder angefügt und der aktualisierte Wert in die Tabelle geschrieben.
  • 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. Daher können Vorgänge, die Transaktionen für einzelne Zeilen erfordern, Probleme in replizierten Instanzen verursachen.

Wenn Ihr Anwendungsfall es zulässt, können Sie diese Konflikte durch die Verwendung von Aggregaten vermeiden. Wenn Sie eine Anfrage zum Hinzufügen an ein Aggregatfeld senden, wird der neue Wert mit dem vorhandenen Wert zusammengeführt. Mit Zusammenfassungen können Sie eine laufende Summe oder einen Zähler führen. Weitere Informationen finden Sie unter Werte zum Schreibzeitpunkt aggregieren.

Nehmen wir an, Sie haben eine Tabelle, in der Sie Daten für ein Ticketing-System speichern, um das Problem zu veranschaulichen, das auftreten kann, wenn Sie keine aggregierten Daten verwenden. Sie verwenden einen Ganzzahlzähler, um die Anzahl der verkauften Tickets zu speichern. Jedes Mal, wenn Sie ein Ticket verkaufen, sendet Ihre App einen read-modify-write-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 sich für diesen Konfigurationstyp entscheiden, dürfen Sie keine in Konflikt stehenden Read-Change-Write- oder Check-Mutate-Anfragen an verschiedene Cluster senden.

Nächste Schritte