Diese Seite wurde von der Cloud Translation API übersetzt.

Routingoptionen

Wenn Sie Anfragen von einer Anwendung an Bigtable senden, verwenden Sie ein Anwendungsprofil, das Bigtable angibt, wie die Anfragen zu verarbeiten sind. In einem Anwendungsprofil wird die Routingrichtlinie für die Anfragen angegeben. Bei Instanzen mit Replikation wird mit der Routingrichtlinie gesteuert, welche Cluster die Anfragen empfangen und wie Failover behandelt werden.

In diesem Dokument werden die Routingrichtlinien beschrieben, die für ein Standard-App-Profil verfügbar sind.

Routing-Richtlinien sind besonders wichtig für Anwendungsfälle mit Workload-Isolation, wenn Sie Data Boost nicht verwenden können. Sie können sie in Verbindung mit Anfrageprioritäten konfigurieren.

Routingrichtlinien wirken sich nicht auf die Replikation aus. Sie sollten sich jedoch mit der Bigtable-Replikation vertraut machen, bevor Sie diese Seite lesen. Lesen Sie auch den Abschnitt Failover.

Single-Cluster-Routing

Eine Single-Cluster-Routingrichtlinie leitet alle Anfragen an einen einzigen Cluster in Ihrer Instanz weiter. 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-Konsistenz für eine Arbeitslast in einer replizierten Instanz erreichen, wenn Sie ein Anwendungsprofil für diese Arbeitslast so konfigurieren, dass Single-Cluster-Routing verwendet wird, um Lese- und Schreibanfragen an denselben Cluster zu senden. Sie können Traffic für zusätzliche Arbeitslasten auf der replizierten Instanz je nach den Anforderungen Ihrer Arbeitslasten 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 die Instanz einen Cluster hat. Wenn der Cluster nicht mehr verfügbar ist, wird der Traffic automatisch auf den nächsten verfügbaren Cluster übertragen.

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 auslösen können, wenn Sie Multi-Cluster-Routing verwenden. Weitere Informationen finden Sie unter Transaktionen mit einer einzelnen Zeile.

Verwenden Sie Multi-Cluster-Routing, wenn Sie Hochverfügbarkeit (High Availability, HA) benötigen. Empfohlene Instanzkonfigurationen und weitere Informationen finden Sie unter Hochverfügbarkeit erstellen.

Es gibt zwei Arten von Multi-Cluster-Routing: Beliebiger Cluster und Clustergruppe.

Weitere Informationen zu SQL-bezogenen Routing-Überlegungen finden Sie im Abschnitt Routing mit SQL in diesem Dokument.

Beliebiges Cluster-Routing

Beim Any-Cluster-Routing ist jeder Cluster in der Instanz verfügbar, um Anfragen zu empfangen und für das Failover.

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

Routing mit Zeilenaffinität

Beim Row-Affinity-Routing werden Lese- und Schreibanfragen für einzelne Zeilen automatisch an einen bestimmten Cluster weitergeleitet, basierend auf dem Zeilenschlüssel der Anfrage.

Wenn Sie Multi-Cluster-Routing verwenden möchten, um eine höhere Rate an Read-Your-Writes-Konsistenz zu erreichen, und die meisten Ihrer Anfragen Einzelzeilenoperationen sind, können Sie das Routing mit Zeilenaffinität (Sticky Routing) verwenden. Um das Routing mit Zeilenaffinität zu aktivieren, verwenden Sie ein benutzerdefiniertes App-Profil mit aktiviertem Flag --row-affinity. Bigtable verwendet den Zeilenschlüssel der Anfrage, um automatisch zu bestimmen, an welchen Cluster die Anfrage weitergeleitet werden soll. Sie können die Zuordnung zwischen dem Zeilenschlüssel und dem Cluster nicht manuell festlegen.

Das Routing mit Zeilenaffinität kann nur für Lese- oder Schreibanfragen für einzelne Zeilen verwendet werden. Dazu gehören Anfragen, bei denen ReadRows mit einem angegebenen Schlüssel, MutateRow mit einem angegebenen Schlüssel, MutateRows mit einem angegebenen Schlüssel und BulkMutateRow mit einem angegebenen Schlüssel aufgerufen wird.

Die Read-Your-Writes-Konsistenz wird bei der zeilenbasierten Weiterleitung in den folgenden Fällen nicht vollständig erreicht:

Cluster zur Instanz hinzufügen: Beim Routing mit Zeilenaffinität wird anhand des Zeilenschlüssels bestimmt, zu welchem Cluster die Anfrage weitergeleitet werden soll. Wenn der Instanz ein neuer Cluster hinzugefügt oder daraus entfernt wird, während das Row-Affinity-Routing aktiviert ist, kann sich die Zuweisung von Zeilenschlüsseln ändern. Damit die Cluster-Failover-Reihenfolge trotz Änderungen an der Clusterliste der Instanz gleich bleibt, empfehlen wir, Clustergruppen zu verwenden und das Flag --restrict-to festzulegen.

Bei Clustergruppen können Sie einen Cluster in einer Instanz nicht löschen, während er von einem App-Profil verwendet wird. Außerdem werden Anfragen erst an neue Cluster weitergeleitet, die der Instanz hinzugefügt werden, wenn sie explizit der Clustergruppe des Anwendungsprofils hinzugefügt werden.
Failover: Wenn ein Cluster nicht verfügbar oder fehlerhaft ist, werden Anfragen an den betroffenen Cluster gemäß der Failover-Reihenfolge an den nächsten Cluster weitergeleitet. Diese Umleitung kann sich auf die Konsistenz auswirken.

Weitere Informationen zu Failovers finden Sie unter Failovers. Wie Sie einen Failover ausführen, erfahren Sie unter Failover verwalten.

Routing mit SQL

Wenn Sie Bigtable mit SQL abfragen, müssen Sie bestimmte Aspekte hinsichtlich der Weiterleitung Ihrer Anfragen berücksichtigen. Das Routing-Verhalten für SQL-Abfragen unterscheidet sich in folgenden Punkten von anderen Arten von Bigtable-Anfragen:

Eine Multi-Cluster-Routing-Richtlinie bietet zwar durch automatisches Failover für die meisten Anfragen eine hohe Verfügbarkeit, dieses Verhalten gilt jedoch nicht für SQL-Abfragen. Wenn eine SQL-Anfrage fehlschlägt, wird kein Failover auf einen anderen Cluster ausgeführt, auch wenn Ihr App-Profil für Multi-Cluster-Routing konfiguriert ist.
Beim Row-Affinity-Routing werden Lese- und Schreibvorgänge für einzelne Zeilen anhand des Zeilenschlüssels automatisch an einen bestimmten Cluster weitergeleitet. Bigtable unterstützt diese Routingrichtlinie jedoch nicht für SQL-Abfragen. Diese Einschränkung bedeutet, dass Sie das Row-Affinity-Routing nicht mit der Methode ExecuteQuery verwenden können, auch wenn die Abfrage so konzipiert ist, dass nur eine einzelne Zeile gelesen wird. Wenn Sie eine ExecuteQuery-Anfrage mit einem App-Profil senden, für das das Flag --row-affinity aktiviert ist, wird die Anfrage erfolgreich ausgeführt, aber die Zeilenaffinität wird nicht erzwungen.

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. Bei einem Read-Modify-Write-Vorgang wird ein vorhandener Wert gelesen, erhöht oder ergänzt 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. 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 vermeiden, indem Sie Aggregate verwenden. Wenn Sie eine Add-Anfrage für ein aggregiertes Feld senden, wird der neue Wert mit dem vorhandenen Wert zusammengeführt. Mit Aggregaten können Sie eine laufende Summe oder einen Zähler führen. Weitere Informationen finden Sie unter Werte beim Schreiben 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 App 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 von Konfiguration erstellen, müssen Sie dafür sorgen, dass keine in Konflikt stehenden Read-Modify-Write- oder Check-Mutate-Anfragen an verschiedene Cluster gesendet werden.