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 Ihrer Anwendungen eine Verbindung zu einer Bigtable-Instanz herstellt, kann sie ein App-Profil angeben, das Bigtable dann für alle Anfragen verwendet, die die Anwendung über diese Verbindung sendet.

App-Profile steuern die Kommunikation Ihrer Anwendungen mit Instanzen, die Replikation verwenden. Daher eignen sich App-Profile besonders für 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 App-Profil 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. Beispiele für Einstellungen, die Sie zum Implementieren gängiger Anwendungsfälle verwenden können, finden Sie unter Beispiele für Replikationseinstellungen. Weitere Informationen zum Erstellen und Verwalten von Anwendungsprofilen finden Sie unter Anwendungsprofile konfigurieren.

Wenn Sie App-Profile zum Konfigurieren der Replikation verwenden, sollten Sie sich mit den Informationen unter Bigtable-Replikation vertraut machen, bevor Sie diese Seite lesen.

Einstellungen in App-Profilen

In einem App-Profil ist die Routingrichtlinie definiert, die von Bigtable verwendet wird. Das Anwendungsprofil bestimmt außerdem, ob Transaktionen für einzelne Zeilen zulässig sind.

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.

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 sind Lese- und Schreibvorgänge immer auf Zeilenebene atomar. Bigtable stellt keine Atomarität oberhalb der Zeilenebene zur Verfügung. Beispielsweise unterstützt Bigtable keine Transaktionen, die mehr als eine Zeile atomar aktualisieren.

Allerdings unterstützt Bigtable auch 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 in kleinstmöglicher Form 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 Client-Anwendungen gleichzeitig Tickets verkaufen und die Zähler ohne Datenverlust erhöhen, da die Anfragen in kleinstmöglicher Reihenfolge 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 2 Inkrement-Anfragen zur gleichen Zeit senden, die an verschiedene Cluster weitergeleitet werden, beendet jede 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 möglicherweise 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 App-Profile erstellen – mindestens eins für jede Anwendung – und jedes App-Profil mit den richtigen Einstellungen für die jeweilige Anwendung konfigurieren. Mit dieser Einrichtung können Sie die Einstellungen problemlos 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 App-Profil 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:

Benutzerdefinierte Anwendungsprofile

Sie können viele verschiedene benutzerdefinierte App-Profile für jede Instanz erstellen. Benutzerdefinierte App-Profile dienen dazu, die Interaktion der einzelnen Anwendung oder Anwendungsfunktion mit einer Instanz zu steuern. Beispielsweise könnten Sie ein App-Profil für eine Batchanwendung verwenden, um deren Traffic in einem einzigen Cluster zu isolieren, und ein anderes App-Profil zur Bereitstellung von hoher Verfügbarkeit für eine andere Anwendung nutzen.

Nächste Schritte