Sessions

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Présentation des sessions

Cette page décrit le concept avancé de session dans Spanner, y compris les bonnes pratiques relatives aux sessions 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.

Une session représente un canal de communication avec le service de base de données Spanner. Une session permet d'effectuer des transactions de lecture, d'écriture ou de modification de données dans une base de données 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 Spanner, telles que 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 concernant l'utilisation des bibliothèques clientes Google

La section suivante décrit les bonnes pratiques d'utilisation des bibliothèques clientes Google pour Spanner.

Configurer le nombre de sessions

En général, nous vous déconseillons de 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 une valeur initiale de test, par exemple 100. Si la limite supérieure n'est pas suffisante, augmentez-la. L'augmentation du nombre de sessions actives utilise des ressources supplémentaires sur le service de base de données Spanner. Par conséquent, le fait de ne pas nettoyer 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, Spanner réserve une partie des sessions aux transactions en lecture-écriture. Il s'agit de la fraction des sessions d'écriture. Si votre application utilise toutes les sessions de lecture, Spanner utilise les sessions en lecture/écriture, même pour les transactions en lecture seule. Les sessions en lecture/écriture nécessitent spanner.databases.beginOrRollbackReadWriteTransaction. Si l'utilisateur dispose du rôle IAM spanner.databaseReader, l'appel échoue et 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#

La fraction des sessions d'écriture par défaut pour C# est de 0,2. Vous pouvez la modifier dans le champ "WriteSessionsFraction" de SessionPoolOptions.

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

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

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.

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

Vous trouverez ci-dessous les bonnes pratiques à suivre pour implémenter des sessions dans une bibliothèque cliente pour Spanner, ou pour utiliser des sessions avec les API REST ou RPC.

Ces bonnes pratiques ne s'appliquent que si vous développez une bibliothèque cliente ou si vous utilisez des API REST/RPC. Si vous utilisez l'une des bibliothèques clientes Google pour Cloud Spanner, reportez-vous à la page Bonnes pratiques concernant l'utilisation des bibliothèques clientes Google.

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 sur le service de base de données Spanner. Par conséquent, le fait de ne pas nettoyer les sessions inutilisées peut dégrader les performances. Pour les utilisateurs qui se servent de l'API RPC, nous vous recommandons 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 Spanner peut supprimer une session lorsqu'elle est inactive pendant plus d'une heure.
  • Le service de base de données 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, puis supprimez la session supprimée du cache.

Gérer l'activation d'une session inactive

Le service de base de données 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 une session inactive n'est pas nécessaire pour une utilisation à court terme, laissez Spanner supprimer la session, puis en créer une autre la prochaine fois qu'une session sera nécessaire.

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 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 à utiliser une application qui utilise Spanner, mais à éviter les coûts de connexion lorsque cela se produit. 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 qui masque les détails de la session pour le consommateur de la bibliothèque cliente, consultez la bibliothèque cliente 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, Spanner peut annuler la transaction active sur la session et provoquer 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 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.