Sessions

Présentation des sessions

Cette page décrit le concept avancé de "session" dans Cloud Spanner, et présente différentes bonnes pratiques liées à cette notion lors de la création d'une bibliothèque cliente, de l'utilisation des API REST ou RPC, ou de l'utilisation des bibliothèques clientes Google.

Les sessions représentent un canal de communication avec le service de base de données Cloud Spanner. Elles servent à effectuer des transactions qui lisent, écrivent ou modifient des données dans une base de données Cloud Spanner. Chaque session s'applique à une base de données unique.

Les sessions ne peuvent exécuter qu'une transaction à la fois. Les lectures, écritures et requêtes autonomes utilisent une transaction en interne, et chacune est comptabilisée comme une transaction.

Avantages en termes de performance de la mise en cache des sessions

Créer une session coûte cher. Pour éviter les coûts de performance chaque fois qu'une opération de base de données est effectuée, les clients doivent conserver un cache de session, qui est un pool de sessions disponibles prêtes à l'emploi. Le cache doit stocker les sessions existantes et renvoyer le type de session approprié en cas de demande, puis effectuer un nettoyage visant à éliminer les sessions inutilisées. Pour obtenir un exemple de mise en œuvre d'un cache de session, consultez le code source de l'une des bibliothèques clientes Cloud Spanner, comme la bibliothèque cliente Go ou la bibliothèque cliente Java.

Les sessions sont destinées à durer longtemps. Ainsi, une fois qu'une session a été utilisée pour une opération de base de données, le client doit la renvoyer dans le cache pour qu'elle puisse être réutilisée.

Bonnes pratiques lors de la création d'une bibliothèque cliente ou de l'utilisation des API REST ou RPC

La section suivante décrit les bonnes pratiques relatives à la mise en œuvre de sessions dans une bibliothèque cliente pour Cloud Spanner, ou à l'utilisation de sessions avec les API REST ou RPC.

Créer et dimensionner le cache de session

Pour déterminer la taille optimale du cache de session pour un processus client, définissez la limite inférieure sur le nombre de transactions simultanées attendues, et la limite supérieure sur un numéro test initial, tel que 100. Si la limite supérieure n'est pas suffisante, augmentez-la. L'augmentation du nombre de sessions actives utilise des ressources supplémentaires dans le service de base de données Cloud Spanner. Ainsi, le fait de ne pas éliminer les sessions inutilisées peut dégrader les performances. Pour les utilisateurs qui se servent de l'API RPC, il est recommandé de ne pas avoir plus de 100 sessions par canal gRPC.

Gérer les sessions supprimées

Pour supprimer une session, trois méthodes s'offrent à vous :

  • Un client peut supprimer une session.
  • Le service de base de données Cloud Spanner peut supprimer une session lorsque celle-ci est inactive pendant plus d'une heure.
  • Le service de base de données Cloud Spanner peut supprimer une session si celle-ci date de plus de 28 jours.

Les tentatives d'utilisation d'une session supprimée ont pour résultat NOT_FOUND. Si vous rencontrez cette erreur, créez et utilisez une nouvelle session, ajoutez-la au cache et éliminez la session supprimée du cache.

Gérer l'activation d'une session inactive

Le service de base de données Cloud Spanner se réserve le droit de supprimer une session inutilisée. Si vous souhaitez absolument avoir la possibilité de réactiver une session inactive, par exemple, si vous prévoyez une augmentation importante de l'utilisation de la base de données à court terme, vous pouvez empêcher la suppression de la session. Effectuez une opération peu coûteuse telle que l'exécution de la requête SQL SELECT 1 pour maintenir la session active. Si vous disposez d'une session inactive qui n'est pas utile dans le court terme, autorisez sa suppression dans Cloud Spanner, puis créez une nouvelle session en fonction de vos nouveaux besoins.

Un scénario efficace pour garder les sessions actives consiste à gérer les pics de demande réguliers dans la base de données. Si la base de données est utilisée de façon intensive quotidiennement de 9h à 18h, faites en sorte de pouvoir activer certaines sessions inactives pendant ce laps de temps, car elles seront probablement utiles lors des pics d'activité. Après 18h, vous pouvez laisser Cloud Spanner supprimer les sessions inactives. Avant 9h chaque jour, créez de nouvelles sessions afin qu'elles soient prêtes en fonction de la demande attendue.

Un autre scénario consiste à tirer parti d'une application qui utilise Cloud Spanner tout en évitant le surcoût de la connexion. Pour ce faire, gardez un ensemble de sessions actif.

Masquer les détails de la session vis-à-vis de l'utilisateur de la bibliothèque cliente

Si vous créez une bibliothèque cliente, n'exposez pas les sessions aux yeux de l'utilisateur de la bibliothèque cliente. Donnez au client la possibilité d'exécuter des appels de base de données sans la complexité liée à la création et à la gestion de sessions. Pour obtenir un exemple de bibliothèque cliente masquant les détails de la session vis-à-vis de ses utilisateurs, consultez la bibliothèque cliente Cloud Spanner pour Java.

Traiter les erreurs pour les transactions d'écriture qui ne sont pas idempotentes

Les transactions d'écriture sans protection de réexécution peuvent appliquer des mutations plusieurs fois. Si une mutation n'est pas idempotente, une mutation appliquée plusieurs fois peut entraîner un échec. Par exemple, une insertion peut échouer et générer une erreur ALREADY_EXISTS, même si la ligne n'existait pas avant la tentative d'écriture. Cette erreur peut se produire si le serveur backend a validé la mutation, mais est incapable de communiquer la réussite de l'opération au client. Dans ce cas, une nouvelle tentative d'exécution de la mutation sera effectuée, ce qui entraînera l'erreur ALREADY_EXISTS.

Voici différentes manières de résoudre ce scénario lorsque vous mettez en œuvre votre propre bibliothèque cliente ou utilisez l'API REST :

  • Structurez votre écriture pour qu'elle soit idempotente.
  • Utilisez les écritures avec protection de réexécution.
  • Mettez en œuvre une méthode qui exécute la logique "upsert" : insérer en cas de nouveauté ou mettre à jour l'existant.
  • Traitez l'erreur pour le compte du client.

Maintenir des connexions stables

Pour des performances optimales, la connexion que vous utilisez pour héberger une session doit rester stable. Lorsque la connexion qui héberge une session change, Cloud Spanner peut supprimer la transaction active sur la session et entraîner une légère charge supplémentaire sur votre base de données pendant la mise à jour des métadonnées de la session. Pas de problème si certaines connexions changent de façon sporadique, mais évitez les situations qui entraîneraient la modification d'un grand nombre de connexions simultanément. Si vous utilisez un proxy entre le client et Cloud Spanner, vous devez maintenir la stabilité de la connexion pour chaque session.

Surveiller les sessions actives

Vous pouvez utiliser la commande ListSessions pour surveiller les sessions actives dans votre base de données à l'aide de la ligne de commande, de l'API REST ou de l'API RPC. ListSessions affiche les sessions actives d'une base de données spécifique. Cette fonction est utile si vous avez besoin de trouver la cause d'une fuite de session. (Une fuite de session est un incident au cours duquel des sessions sont en cours de création, mais ne sont pas renvoyées dans un cache pour être réutilisées.)

ListSessions vous permet d'afficher des métadonnées sur vos sessions actives, y compris l'heure de création et de dernière utilisation. L'analyse de ces données vous orientera dans la bonne direction lors du dépannage des sessions. Si la plupart des sessions actives ne comportent pas d'indication approximate_last_use_time récente, cela peut vouloir dire que les sessions ne sont pas réutilisées correctement par votre application. Pour en savoir plus sur le champ approximate_last_use_time, consultez la documentation de référence de l'API RPC.

Pour en savoir plus sur l'utilisation de ListSessions, consultez la documentation de référence de l'API REST, de l'API RPC ou de l'outil de ligne de commande gcloud.

Bonnes pratiques concernant l'utilisation des bibliothèques clientes Google

Vous trouverez ci-dessous les bonnes pratiques concernant l'utilisation des bibliothèques clientes Google pour Cloud Spanner.

Configurer le nombre de sessions

En général, nous vous recommandons de ne pas modifier le nombre de sessions par défaut utilisé par les bibliothèques clientes.

Si vous avez une charge de travail spéciale, nous vous recommandons de définir la limite inférieure sur le nombre de transactions simultanées attendues, et de définir la limite supérieure sur un numéro test initial, tel que 100. Si la limite supérieure n'est pas suffisante, augmentez-la. L'augmentation du nombre de sessions actives utilise des ressources supplémentaires dans le service de base de données Cloud Spanner. Ainsi, le fait de ne pas éliminer les sessions inutilisées peut dégrader les performances. Nous vous recommandons également de ne pas avoir plus de 100 sessions par canal gRPC.

Gérer la fraction des sessions d'écriture

Pour la plupart des bibliothèques clientes, Cloud Spanner réserve une partie des sessions pour les transactions en lecture-écriture, appelée fraction des sessions d'écriture. Si votre application consomme toutes les sessions de lecture, Cloud Spanner va utiliser les sessions de lecture-écriture, même pour les transactions en lecture seule. Les sessions en lecture/écriture nécessitent spanner.databases.beginOrRollbackReadWriteTransaction. Si l'utilisateur possède un rôle IAM spanner.databaseReader, l'appel échoue et Cloud Spanner renvoie le message d'erreur suivant :

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

Vous pouvez définir la fraction de sessions d'écriture pour les bibliothèques clientes qui gèrent une fraction des sessions d'écriture.

C++

Les sessions C++ sont toutes similaires. Il n'existe pas de sessions en lecture seule ou en lecture-écriture.

C#

Bien que la bibliothèque cliente C# vérifie si une session a été utilisée pour la dernière fois pour une transaction en lecture seule ou en lecture-écriture, l'ensemble des sessions en lecture seule et en lecture-écriture n'est pas défini. Une fraction de sessions d'écriture n'est pas appliquée au pool de sessions et, par conséquent, aucune API ne permet de la modifier.

Go

La fraction des sessions d'écriture par défaut pour Java est de 0,2. Vous pouvez modifier la fraction à l'aide du champ WriteSessions de SessionPoolConfig.

Java

La fraction des sessions d'écriture par défaut pour Java est de 0,2. Vous pouvez la modifier à l'aide de la méthode setWriteSessionsFraction. L'exemple de code suivant montre comment définir la fraction :

SpannerOptions.Builder builder = SpannerOptions.newBuilder();
builder.setWriteSessionsFraction(0);
SpannerOptions options = builder.build();
spanner = options.getService();

Lorsque vous utilisez Java, Cloud Spanner renvoie l'erreur lorsque vous appelez singleUseReadOnlyTransaction() et qu'aucune session de lecture n'est disponible.

Node.js

La fraction des sessions d'écriture par défaut pour Node.js est de 0 (zéro). Vous pouvez la changer dans le champ writes.

PHP

Les sessions PHP sont toutes similaires. Il n'existe pas de sessions en lecture seule ou en lecture-écriture.

Python

Python accepte quatre types de pools de sessions différents que vous pouvez utiliser pour gérer les sessions de lecture seule et de lecture-écriture.

Ruby

La fraction des sessions d'écriture par défaut pour Ruby est de 0,3. Vous pouvez la modifier à l'aide de la méthode d'initialisation du client.