Diese Seite wurde von der Cloud Translation API übersetzt.

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 ein Standard-App-Profil verfügbar sind.

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

Routingrichtlinien haben keine Auswirkungen auf die Replikation. Sie sollten sich jedoch mit der Funktionsweise der Bigtable-Replikation vertraut machen, bevor Sie diese Seite lesen. Lesen Sie auch den Hilfeartikel Failover.

Single-Cluster-Routing

Mit einer Single-Cluster-Routingrichtlinie werden alle Anfragen an einen Cluster in Ihrer Instanz weitergeleitet. 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 Lese- und Schreibanfragen mit Single-Cluster-Routing an denselben Cluster gesendet werden. 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

Mit einer Multi-Cluster-Routing-Richtlinie werden Anfragen, die Sie an eine Instanz senden, an die nächstgelegene Region weitergeleitet, in der sich ein Cluster der Instanz befindet. 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 Transaktionen für einzelne Zeilen nicht 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 Zeile.

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

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

Beliebiges Cluster-Routing

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.

Routing mit Zeilenaffinität

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

Wenn Sie mit dem Multi-Cluster-Routing eine höhere Rate der Read-Your-Writes-Konsistenz erreichen möchten und die meisten Ihrer Anfragen Vorgänge für einzelne Zeilen sind, können Sie das Zeilenaffinitäts-Routing (Sticky-Routing) verwenden. Wenn Sie das Routing mit Zeilenaffinität aktivieren möchten, 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. Die Zuordnung zwischen dem Zeilenschlüssel und dem Cluster kann nicht manuell festgelegt werden.

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 Schlüssel, MutateRow, MutateRows mit einem Schlüssel und BulkMutateRow mit einem Schlüssel aufgerufen werden.

In den folgenden Fällen wird die Read-Your-Writes-Konsistenz beim Routing mit Zeilenaffinität nicht vollständig erreicht:

Cluster zur Instanz hinzufügen: Beim Routing mit Zeilenaffinität wird basierend auf dem Zeilenschlüssel bestimmt, an welchen Cluster weitergeleitet werden soll. Wenn der Instanz ein neuer Cluster hinzugefügt oder ein Cluster entfernt wird, während das Routing mit Zeilenaffinität aktiviert ist, ändert sich möglicherweise die Zuweisung des Zeilenschlüssels. Damit die Reihenfolge des Cluster-Failovers trotz Änderungen an der Clusterliste der Instanz gleich bleibt, empfehlen wir die Verwendung von Clustergruppen. Legen Sie dazu das Flag --restrict-to fest.

Bei Clustergruppen können Sie einen Cluster in einer Instanz nicht löschen, während er von einem App-Profil verwendet wird. Außerdem erhält ein neuer Cluster, der der Instanz hinzugefügt wird, erst dann Anfragen, wenn er der Clustergruppe des App-Profils explizit hinzugefügt wurde.
Failover: Wenn ein Cluster nicht verfügbar oder nicht betriebsbereit 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.

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-Modify-Write-Vorgang liest einen vorhandenen Wert, erhöht oder ergänzt diesen und schreibt den aktualisierten Wert in die Tabelle.
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 Aggregierungsfeld senden, wird der neue Wert mit dem vorhandenen Wert zusammengeführt. Mit Aggregationen können Sie eine fortlaufende Summe oder einen fortlaufenden 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 von Konfiguration erstellen, müssen Sie gewährleisten, dass keine in Konflikt stehenden Read-Modify-Write- oder Check-Mutate-Anfragen an verschiedene Cluster gesendet werden.