Routingoptionen

Wenn Sie Anfragen von einer Anwendung an Bigtable senden, verwenden Sie eine Anwendung , das Bigtable mitteilt, wie um die Anfragen zu verarbeiten. Ein Anwendungsprofil gibt das Routing Richtlinie für die Anfragen. Bei Instanzen mit Replikation ist die Routingrichtlinie legt fest, 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 Arbeitslasten Anwendungsfälle der Isolierung können Sie Data Boost (Vorschau) 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. Weitere Informationen Failovers

Single-Cluster-Routing

Eine Single-Cluster-Routingrichtlinie leitet alle Anfragen an einen Cluster in Ihrem Instanz. Wenn dieser Cluster nicht mehr verfügbar ist, muss ein manuelles Failover auf einen anderen Cluster.

Dies ist die einzige Routingrichtlinie, mit der Sie einzelne Zeilen Transaktionen.

Eine replizierte Instanz stellt normalerweise Eventuelle Consistency (Einheitlichkeit). 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. Sie können Traffic für zusätzliche Arbeitslasten auf der replizierten zu anderen Clustern in der Instanz, je nach Arbeitslast Anforderungen.

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 Einzeilig Transaktionen.

Verwenden Sie Multi-Cluster-Routing, wenn Sie Hochverfügbarkeit möchten. Für empfohlene Instanzkonfigurationen und weitere Details finden Sie unter Hochverfügbarkeit erstellen (HA).

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

Beliebiges Clusterrouting

Beliebiges Cluster-Routing macht jeden Cluster in der Instanz für den Empfang verfügbar für -Anfragen und für das Failover.

Clustergruppenrouting

Wenn Sie einen oder mehrere Cluster einer Instanz Failover ausführen, können Sie Clustergruppenrouting verwenden. Diese 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 kann nicht unterstützen Transaktionen, bei denen mehr als eine Zeile atomar aktualisiert wird.

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 anhängt. 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. Das führt dazu, dass Vorgänge, die eine Zeile erfordern, Transaktionen können 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 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 Weitere Informationen finden Sie unter Werte beim Schreiben aggregieren.

Um das Problem zu veranschaulichen, das auftreten kann, wenn Sie keine Aggregatfunktionen verwenden, nehmen wir an, haben Sie eine Tabelle, in der Sie Daten für ein Ticketing-System speichern. Sie verwenden eine Ganzzahlzähler zum Speichern der Anzahl der verkauften Tickets Jedes Mal Sie ein Ticket verkaufen, sendet Ihre App ein Read-Modify-Write-Element 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