Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Sitzungen

Übersicht über Sitzungen

Auf dieser Seite wird das erweiterte Konzept von Sitzungen in Cloud Spanner beschrieben, einschließlich Best Practices für Sitzungen beim Erstellen einer Clientbibliothek, mithilfe der REST- oder RPC APIs oder der Google-Clientbibliotheken.

Eine Sitzung stellt einen Kommunikationskanal mit dem Cloud Spanner-Datenbankdienst dar. In einer Sitzung werden Transaktionen ausgeführt, die Daten in einer Cloud Spanner-Datenbank lesen, schreiben oder ändern. Jede Sitzung gilt für eine einzige Datenbank.

Sitzungen können jeweils nur eine Transaktion ausführen. Eigenständige Lesevorgänge, Schreibvorgänge und Abfragen verwenden interne Transaktionen und werden auf die Transaktionsgrenze angerechnet.

Leistungsvorteile eines Sitzungscaches

Das Erstellen einer Sitzung ist teuer. Um zu vermeiden, dass für jeden Datenbankvorgang Leistungskosten anfallen, sollten Kunden einen Sitzungscache führen. Dabei handelt es sich um einen Pool verfügbarer Sitzungen, die sofort verwendet werden können. Der Cache sollte vorhandene Sitzungen speichern und auf Anfrage den entsprechenden Sitzungstyp zurückgeben sowie die Bereinigung nicht verwendeter Sitzungen vornehmen. Ein Beispiel für die Implementierung eines Sitzungscaches finden Sie im Quellcode für eine der Cloud Spanner-Clientbibliotheken, z. B. die Go-Clientbibliothek oder die Java-Clientbibliothek.

Sitzungen sind langlebig angelegt. Nachdem eine Sitzung für eine Datenbankoperation verwendet wurde, sollte der Client die Sitzung zur Wiederverwendung an den Cache zurückgeben.

Best Practices beim Erstellen einer Clientbibliothek oder bei Verwendung von REST/RPC

Im Folgenden werden Best Practices für die Implementierung von Sitzungen in einer Clientbibliothek für Cloud Spanner oder für die Verwendung von Sitzungen mit der REST API oder der RPC API beschrieben.

Sitzungscache erstellen und Größe festlegen

Um eine optimale Größe des Sitzungscaches für einen Clientprozess festzulegen, geben Sie als untere Grenze die Anzahl der erwarteten gleichzeitigen Transaktionen an und als obere Grenze eine anfängliche Testanzahl (z. B. 100). Wenn die obere Grenze nicht ausreicht, setzen Sie sie herauf. Wenn Sie die Anzahl der aktiven Sitzungen erhöhen, werden zusätzliche Ressourcen im Cloud Spanner-Datenbankdienst verwendet. Wenn Sie also nicht verwendete Sitzungen bereinigen, kann dies die Leistung beeinträchtigen. Für Nutzer, die mit der RPC API arbeiten, empfehlen wir, nicht mehr als 100 Sitzungen pro gRPC-Kanal zu haben.

Gelöschte Sitzungen

Es gibt drei Möglichkeiten, eine Sitzung zu löschen:

  • Ein Client kann eine Sitzung löschen.
  • Der Cloud Spanner-Datenbankdienst kann eine Sitzung löschen, wenn die Sitzung länger als eine Stunde inaktiv ist.
  • Der Cloud Spanner-Datenbankdienst kann eine Sitzung löschen, wenn die Sitzung mehr als 28 Tage alt ist.

Der Versuch, eine gelöschte Sitzung zu verwenden, führt zum Fehler NOT_FOUND. Wenn Sie auf diesen Fehler stoßen, erstellen Sie eine neue Sitzung und verwenden diese. Fügen Sie die neue Sitzung dem Cache hinzu und entfernen Sie die gelöschte Sitzung aus dem Cache.

Inaktive Sitzung offen halten

Der Cloud Spanner-Datenbankdienst behält sich das Recht vor, eine nicht verwendete Sitzung zu löschen. Wenn Sie eine inaktive Sitzung unbedingt offen halten müssen, wenn z. B. eine signifikante Erhöhung der Datenbanknutzung in naher Zukunft erwartet wird, können Sie verhindern, dass die Sitzung gelöscht wird. Führen Sie einen kostengünstigen Vorgang wie das Ausführen der SQL-Abfrage SELECT 1 durch, um die Sitzung aktiv zu halten. Wenn Sie über eine inaktive Sitzung verfügen, die nicht in naher Zukunft verwendet werden soll, erlauben Sie, dass sie von Cloud Spanner gelöscht wird. Erstellen Sie eine neue Sitzung, wenn das nächste Mal eine Sitzung benötigt wird.

Ein Szenario, in dem Sitzungen offen gehalten werden, ist der Umgang mit regulärer Spitzennachfrage der Datenbank. Wenn eine starke Datenbanknutzung täglich von 9:00 Uhr bis 18:00 Uhr stattfindet, sollten Sie während dieser Zeit einige inaktive Sitzungen offen halten, da diese wahrscheinlich zu Spitzenzeiten erforderlich sind. Nach 18:00 Uhr kann Cloud Spanner inaktive Sitzungen wieder löschen. Erstellen Sie jeden Tag vor 9:00 Uhr einige neue Sitzungen, damit sie für die erwartete Nachfrage bereitstehen.

Ein anderes Szenario wäre, dass Sie eine Anwendung haben, die Cloud Spanner verwendet, aber den Verbindungsaufwand dabei vermeiden muss. Sie können eine Gruppe von Sitzungen offen halten, um den Verbindungsaufwand zu vermeiden.

Sitzungsdetails vom Clientbibliotheksbenutzer ausblenden

Wenn Sie eine Clientbibliothek erstellen, sollten Sie dem Clientbibliotheksbenutzer keine Sitzungen anzeigen. Stellen Sie die Möglichkeit für den Client bereit, Datenbankaufrufe ohne den Aufwand der Erstellung und Verwaltung von Sitzungen durchzuführen. Ein Beispiel für eine Clientbibliothek, in der die Sitzungsdetails vor dem Clientbibliothekbenutzer ausgeblendet werden, finden Sie in der Cloud Spanner-Clientbibliothek für Java.

Fehler bei Schreibtransaktionen bearbeiten, die nicht idempotent sind

Schreibtransaktionen ohne Wiederholungsschutz können Mutationen mehr als einmal anwenden. Wenn eine Mutation nicht idempotent ist, kann eine Mutation, die mehrmals angewendet wird, zu einem Fehler führen. Beispiel: Eine Einfügung (Insert) kann den Fehler ALREADY_EXISTS verursachen, obwohl die Zeile vor dem Schreibversuch nicht vorhanden war. Dies kann auftreten, wenn der Back-End-Server die Mutation festgeschrieben hat, dies aber dem Client nicht mitteilen konnte. In diesem Fall könnte die Mutation wiederholt werden, was aber zu dem Fehler ALREADY_EXISTS führen würde.

Im Folgenden sind einige Möglichkeiten aufgelistet, wie Sie mit diesem Szenario bei der Bereitstellung Ihrer eigenen Clientbibliothek oder bei der Verwendung der REST API verfahren können:

  • Strukturieren Sie Ihre Schreibvorgänge so, dass sie idempotent sind.
  • Verwenden Sie Schreibvorgänge mit Wiederholungsschutz.
  • Implementieren Sie eine Methode mit der Logik "upsert", d. h. einfügen, wenn neu, oder aktualisieren, wenn bereits vorhanden.
  • Bearbeiten Sie den Fehler für den Client.

Für stabile Verbindungen sorgen

Für eine optimale Leistung sollte die Verbindung, die Sie zum Hosten einer Sitzung verwenden, stabil sein. Wenn sich die Hostingverbindung für eine Sitzung ändert, bricht Cloud Spanner möglicherweise die aktive Transaktion in der Sitzung ab. Dies führt während der Aktualisierung der Sitzungsmetadaten zu einer geringfügigen Mehrbelastung Ihrer Datenbank. Wenn sich einige Verbindungen gelegentlich ändern, ist das kein Problem, aber Sie sollten Situationen vermeiden, in denen sich eine große Anzahl von Verbindungen gleichzeitig ändert. Falls Sie einen Proxy zwischen dem Client und Cloud Spanner einsetzen, sollten Sie bei jeder Sitzung für eine stabile Verbindung sorgen.

Aktive Sitzungen überwachen

Mit dem Befehl "ListSessions" können Sie aktive Sitzungen in Ihrer Datenbank über die Befehlszeile, mit der REST API oder mit der RPC API überwachen. "ListSessions" zeigt die aktiven Sitzungen für eine bestimmte Datenbank an. Dies ist sinnvoll, wenn Sie die Ursache für ein Sitzungsleck finden möchten. Ein Sitzungsleck ist ein Vorfall, bei dem Sitzungen erstellt, aber nicht zur Wiederverwendung an einen Sitzungscache zurückgegeben werden.

Mit ListSessions können Sie Metadaten zu Ihren aktiven Sitzungen abrufen, z. B. wann eine Sitzung erstellt wurde und wann eine Sitzung zuletzt verwendet wurde. Die Analyse dieser Daten wird Ihnen bei der Fehlersuche die richtige Richtung weisen. Wenn für die meisten aktiven Sitzungen kein aktueller Wert für approximate_last_use_time vorhanden ist, deutet dies eventuell darauf hin, dass Sitzungen von Ihrer Anwendung nicht ordnungsgemäß wiederverwendet werden. Weitere Informationen zum Feld approximate_last_use_time finden Sie in der RPC API-Referenz.

Weitere Informationen zur Verwendung von ListSessions finden Sie in der REST API-Referenz, der RPC API-Referenz oder der Referenz zum gcloud-Befehlszeilentool.

Best Practices für die Verwendung von Google-Clientbibliotheken

Im Folgenden werden Best Practices für die Verwendung der Google-Clientbibliotheken für Cloud Spanner beschrieben.

Konfigurieren der Anzahl der Sitzungen

Im Allgemeinen wird davon abgeraten, die Standardanzahl der Sitzungen zu ändern, die von den Clientbibliotheken verwendet werden.

Wenn Sie eine spezielle Arbeitslast haben, empfehlen wir, die Untergrenze auf die Anzahl der erwarteten gleichzeitigen Transaktionen und die Obergrenze auf eine anfängliche Testzahl wie 100 festzulegen. Wenn die obere Grenze nicht ausreicht, setzen Sie sie herauf. Wenn Sie die Anzahl der aktiven Sitzungen erhöhen, werden zusätzliche Ressourcen im Cloud Spanner-Datenbankdienst verwendet. Wenn Sie also nicht verwendete Sitzungen bereinigen, kann dies die Leistung beeinträchtigen. Wir empfehlen außerdem, nicht mehr als 100 Sitzungen pro gRPC-Kanal zu haben.

Anteil der Schreibsitzungen verwalten

Bei den meisten Clientbibliotheken reserviert Cloud Spanner einen Teil der Sitzungen für nicht schreibgeschützte Transaktionen. Dies wird als Anteil der Schreibsitzungen bezeichnet. Wenn Ihre Anwendung alle Lesesitzungen genutzt hat, verwendet Cloud Spanner die nicht schreibgeschützten Sitzungen auch für schreibgeschützte Transaktionen. Für Lese-/Schreibvorgänge ist spanner.databases.beginOrRollbackReadWriteTransaction erforderlich. Wenn der Nutzer die IAM-Rolle spanner.databaseReader hat, schlägt der Aufruf fehl und Cloud Spanner gibt die folgende Fehlermeldung zurück:

generic::permission_denied: Resource %resource% is missing IAM permission:
spanner.databases.beginOrRollbackReadWriteTransaction

Bei Clientbibliotheken, die einen Anteil an Schreibsitzungen haben, können Sie diesen festlegen.

C++

Alle C ++-Sitzungen sind identisch. Es gibt weder schreibgeschützte noch nicht schreibgeschützte Sitzungen.

C#

Die C#-Clientbibliothek verfolgt zwar, ob eine Sitzung zuletzt für eine schreibgeschützte oder nicht schreibgeschützte Transaktion verwendet wurde, aber deren Zahl ist nicht festgelegt. Da der Sitzungspool keinen Anteil an Schreibsitzungen beinhaltet, gibt es keine API, um einen solchen zu ändern.

Go

Bei Go gilt standardmäßig ein Anteil an Schreibsitzungen von 0,2. Sie können den Anteil im Feld "WriteSessions" von SessionPoolConfig ändern.

Java

Alle Java-Sitzungen sind identisch. Es gibt weder schreibgeschützte noch nicht schreibgeschützte Sitzungen.

Node.js

Der Standardanteil der Schreibsitzungen bei Node.js ist 0 (null). Über das Feld writes können Sie diesen ändern.

PHP

Alle PHP-Sitzungen sind gleich. Es gibt keine schreibgeschützten bzw. nicht schreibgeschützten Sitzungen.

Python

Python unterstützt vier verschiedene Sitzungspooltypen, die Sie zum Verwalten von schreibgeschützten und nicht schreibgeschützten Sitzungen verwenden können.

Ruby

Der Standardanteil der Schreibsitzungen bei Ruby ist 0,3. Sie können ihn mit der client initialize-Methode ändern.