Diese Seite wurde von der Cloud Translation API übersetzt.

Informationen über Anwendungsprofile

In einem Anwendungsprofil sind Einstellungen gespeichert, die einer Cloud Bigtable-Instanz vorgeben, wie die von einer Anwendung eingehenden Anfragen zu verarbeiten sind. Wenn eine Anwendung eine Verbindung zu einer Bigtable-Instanz herstellt, kann sie ein Anwendungsprofil angeben, das Bigtable für Anfragen verwendet, die die Anwendung über diese Verbindung sendet. In einem Anwendungsprofil ist die Routingrichtlinie definiert, die von Bigtable verwendet wird und die steuert, ob Transaktionen für einzelne Zeilen zulässig sind.

Anwendungsprofile sind besonders nützlich bei Instanzen mit zwei oder mehr Clustern. Auch wenn Ihre Instanz nur einen einzigen Cluster hat, können Sie für jede ausgeführte Anwendung oder für verschiedene Komponenten in einer einzigen Anwendung ein eigenes Anwendungsprofil verwenden. In diesem Fall können Sie sich separate Grafiken Ihrer Bigtable-Messwerte für jedes Anwendungsprofil ansehen.

Auf dieser Seite werden die Einstellungen erläutert, die von einem App-Profil gesteuert werden. Außerdem erfahren Sie, wie App-Profile mit Ihrer Anwendung interagieren.

Wenn Sie Anwendungsprofile zum Konfigurieren von Cluster-Routingrichtlinien verwenden, sollten Sie sich mit den Informationen unter Bigtable-Replikation – Übersicht vertraut gemacht haben, bevor Sie diese Seite lesen.

Routingrichtlinie

In einem Anwendungsprofil ist die Routingrichtlinie angegeben, die Bigtable für jede Anfrage verwenden soll:

Single-Cluster-Routing 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.
Multi-Cluster-Routing leitet Anfragen automatisch an den nächsten Cluster in einer Instanz weiter. Wenn der Cluster nicht mehr verfügbar ist, wird der Traffic automatisch auf den nächsten verfügbaren Cluster übertragen. Bigtable betrachtet Cluster in einer einzelnen Region als äquidistant, auch wenn sie sich in verschiedenen Zonen befinden. Sie können ein Anwendungsprofil für die Weiterleitung an einen beliebigen Cluster in einer Instanz konfigurieren oder eine Clustergruppe angeben, die das Anwendungsprofil anweist, Anfragen nur an einige Cluster der Instanz weiterzuleiten.
Clustergruppen-Routing: Sendet Anfragen an den nächsten verfügbaren Cluster innerhalb einer Clustergruppe, die Sie in den Anwendungsprofileinstellungen angeben.

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 Multi-Cluster-Instanzen führen.

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.

Funktionsweise von App-Profilen

Ein App-Profil gibt die Einstellungen an, die Bigtable zur Verarbeitung der eingehenden Anfragen einer Instanz verwendet.

Viele Bigtable-Nutzer haben mehrere Anwendungen, die eine Verbindung zur selben Instanz herstellen. Beispielsweise könnten Sie eine Anwendung haben, die angeforderte Daten an Kunden sendet, und eine andere Anwendung, die gelegentlich Batchjobs zur Datenanalyse ausführt. Für diese unterschiedlichen Anwendungen sollten Sie mehrere Anwendungsprofile erstellen – mindestens eins für jede Anwendung – und jedes Anwendungsprofil mit den richtigen Einstellungen für die jeweilige Anwendung konfigurieren. Mit dieser Einrichtung können Sie die Einstellungen für eine Anwendung ändern und für andere Anwendungen unverändert lassen.

Sie könnten auch eine einzige Anwendung haben, die mehrere Funktionen ausführt, beispielsweise das Anzeigen von aktuellen Daten und die Abfrage von Verlaufsdaten. Für diese unterschiedlichen Funktionen sollten Sie ein Anwendungsprofil pro Funktion erstellen, sodass Sie jede Funktion unterschiedlich konfigurieren und die Einstellungen für eine Funktion aktualisieren und für andere Funktionen unverändert lassen können.

Jede Instanz hat ein default-Anwendungsprofil. Sie können aber für jede Instanz auch benutzerdefinierte Anwendungsprofile erstellen. In den folgenden Abschnitten werden standardmäßige (default) und benutzerdefinierte Anwendungsprofile beschrieben.

Zur Verwendung eines App-Profils geben Sie dieses in Ihrem Code an, wenn Sie eine Verbindung zu Ihrer Instanz herstellen. Wenn Sie kein Anwendungsprofil angeben, verwendet Bigtable das standardmäßige App-Profil der Instanz.

Standardmäßiges App-Profil

Beim Erstellen einer Instanz erstellt Bigtable automatisch ein standardmäßiges Anwendungsprofil für die Instanz. Wenn Ihre Anwendung kein Anwendungsprofil angibt oder wenn Sie mit HBase Shell eine Verbindung zu Ihrer Instanz herstellen, verwendet Bigtable die Einstellungen im standardmäßigen Anwendungsprofil. Sie können diese Einstellungen jederzeit ansehen und ändern.

Die Einstellungen im Standard-Anwendungsprofil einer Instanz hängen von der Anzahl der Cluster ab, die die Instanz beim ersten Erstellen hatte:

Wenn Sie die Instanz mit 1 Cluster erstellt haben, verwendet das default-Anwendungsprofil das Single-Cluster-Routing und ermöglicht Transaktionen mit einer Zeile. Dadurch wird gewährleistet, dass das spätere Hinzufügen zusätzlicher Cluster das Verhalten Ihrer vorhandenen Anwendungen nicht ändert.
Wenn Sie die Instanz mit 2 oder mehr Clustern erstellt haben, verwendet das default-Anwendungsprofil das Multi-Cluster-Routing. Transaktionen für einzelne Zeilen sind beim Multi-Cluster-Routing nie zulässig.

Das standardmäßige Anwendungsprofil wird beim Hinzufügen oder Entfernen von Clustern nicht geändert. Sie müssen das standardmäßige Anwendungsprofil manuell aktualisieren, um dessen Einstellungen zu ändern. Als Best Practice sollten Sie jedoch ein neues Anwendungsprofil erstellen und verwenden, statt das standardmäßige Anwendungsprofil zu ändern.

Benutzerdefinierte App-Profile

Ein benutzerdefiniertes Anwendungsprofil ist ein Anwendungsprofil, das Sie erstellen und konfigurieren. Eine Instanz kann bis zu 2.000 Anwendungsprofile haben.