Sesiones

Visión general sobre las sesiones

En esta página se describe el concepto avanzado de sesiones en Cloud Spanner, entre las que se incluyen prácticas recomendadas sobre sesiones cuando se crea una biblioteca cliente o cuando se usan las API REST o RPC.

Una sesión representa un canal de comunicación con el servicio de base de datos de Cloud Spanner. Una sesión se usa para realizar transacciones que leen, escriben o modifican datos en una base de datos de Cloud Spanner. Cada sesión se aplica a una única base de datos.

Las sesiones no pueden ejecutar más de una transacción a la vez. Las lecturas, escrituras y consultas independientes usan una transacción de forma interna y se suman al recuento del límite de una transacción.

Ventajas de rendimiento de una caché de sesión

Crear una sesión resulta caro. Si quieren evitar los costes de rendimiento cada vez que se realiza una operación de base de datos, los clientes deben mantener una caché de sesión, que es un grupo de sesiones disponibles preparadas para usarlas. La memoria caché debe almacenar las sesiones ya creadas y devolver el tipo de sesión apropiado cuando se solicite, así como gestionar la limpieza de las sesiones no utilizadas. Puedes ver un ejemplo del despliegue de una memoria caché de sesión, si consultas el código fuente de una de las bibliotecas cliente de Cloud Spanner, como la biblioteca cliente Go o la biblioteca cliente Java.

Las sesiones están pensadas para durar mucho tiempo, por lo tanto, después de que una sesión se use para realizar una operación de base de datos, el cliente debe devolver la sesión a la caché para que se pueda volver a utilizar.

Prácticas recomendadas

A continuación se describen las mejores prácticas para desplegar sesiones en una biblioteca cliente para Cloud Spanner o para usar sesiones con las API REST o RPC.

Crear la caché de la sesión y determinar su tamaño

Si quieres determinar un tamaño óptimo de caché de sesión para un proceso de cliente, establece el límite inferior en el número de transacciones simultáneas esperadas y el límite superior en un número de prueba inicial, como 100 (en el caso de los usuarios que trabajan con la API RPC, recomendamos no tener más de 100 sesiones en la memoria caché, ya que 100 es la cantidad máxima de sesiones simultáneas por canal gRPC). Si el límite superior no es adecuado, auméntalo. Al aumentar el número de sesiones activas, se usan más recursos en el servicio de base de datos de Cloud Spanner, por lo que, si no limpias las sesiones no utilizadas, se puede reducir el rendimiento o impedir que se use la base de datos de Cloud Spanner durante un máximo de una hora.

Existe un límite de 10.000 sesiones por base de datos por nodo. Obtén más información acerca de los límites de Cloud Spanner en el apartado sobre límites.

Gestionar sesiones eliminadas

Existen dos formas de eliminar una sesión:

  • Un cliente puede eliminar una sesión.
  • El servicio de base de datos de Cloud Spanner puede eliminar una sesión cuando esta permanezca inactiva durante más de una hora.

Intenta usar una sesión eliminada con resultado NOT_FOUND. Si surge este error, crea y usa una sesión, añádela a la memoria caché y borra la sesión eliminada de dicha memoria.

Conservar una sesión inactiva

El servicio de base de datos de Cloud Spanner se reserva el derecho de eliminar una sesión no utilizada. Si definitivamente necesitas conservar una sesión inactiva, por ejemplo, si se espera un aumento significativo en el uso de la base de datos a corto plazo, podrás evitar que la sesión se elimine. Realiza una operación de bajo coste, como ejecutar la consulta SQL SELECT 1 para conservar la sesión. Si dispones de una sesión inactiva que no se va a usar a corto plazo, deja que Cloud Spanner elimine la sesión y crea una nueva la próxima vez que la necesites.

Se requerirá conservar todas las sesiones en casos como la gestión de una la demanda máxima habitual en la base de datos. Si el uso intensivo de la base de datos se produce todos los días de 9:00 a 18:00, deberás conservar algunas sesiones inactivas durante ese periodo, ya que es probable que se necesiten para alcanzar el uso máximo. Después de las 18:00, puedes dejar que Cloud Spanner elimine sesiones inactivas. Crea algunas sesiones nuevas todos los días antes de las 9:00 para que estén listas para afrontar la demanda esperada.

Si cuentas con una aplicación que usa Cloud Spanner, pero debes evitar la sobrecarga de la conexión cuando lo hace, también tendrás que conservar sesiones inactivas. Puedes conservar un conjunto de sesiones para evitar la sobrecarga de la conexión.

Ocultar detalles de la sesión del usuario de la biblioteca cliente

Si estás creando una biblioteca cliente, no expongas las sesiones ante el consumidor de dicha biblioteca. Permite que el cliente realice llamadas a bases de datos sin la dificultad de tener que crear y mantener sesiones. Si quieres obtener un ejemplo de una biblioteca cliente que oculta los detalles de la sesión del cliente de dicha biblioteca, consulta la biblioteca cliente de Cloud Spanner para Java.

Gestionar errores de transacciones de escritura que no son idempotentes

Las transacciones de escritura sin protección de reproducción pueden dar lugar a mutaciones en más de una ocasión. Si una mutación no es idempotente, aplicarla en más de una ocasión podría provocar un fallo. Por ejemplo, una inserción podría causar el error ALREADY_EXISTS aunque la fila no existiera antes del intento de escritura. Esto podría ocurrir si el servidor backend aplica la mutación, pero no puede informar de la realización correcta al cliente. En ese caso, se podría volver a intentar aplicar la mutación, lo que da como resultado un error ALREADY_EXISTS.

Estas son algunas formas posibles de afrontar esta situación cuando despliegas tu propia biblioteca cliente o usas la API REST:

  • Estructura tus escrituras para que sean idempotentes.
  • Usa escrituras con protección de reproducción.
  • Despliega un método que pueda desempeñar la lógica de "recuperación": insertar si es nuevo, actualizar si ya existe.
  • Gestionar el error en nombre del cliente.

Supervisión de sesiones activas

Puedes usar el comando ListSessions para supervisar sesiones activas en la base de datos desde la línea de comandos, con la API REST o con la API RPC. ListSessions muestra las sesiones activas de una base de datos determinada. Esto resulta útil si se alcanza con frecuencia el límite de la sesión y se necesita identificar las sesiones para eliminarlas o determinar la causa de una pérdida de sesión (una pérdida de sesión es un incidente por el que se crean sesiones, pero no se devuelven a una caché de sesión para que se vuelvan a utilizar).

ListSessions te permite ver los metadatos de las sesiones activas, entre ellos, cuándo se creó una sesión y cuándo se utilizó por última vez. El análisis de esta información te permitirá orientarte en la dirección correcta a la hora de solucionar problemas sobre sesiones. Si la mayoría de las sesiones activas no cuentan con un approximate_last_use_time reciente, esto podría indicar que la aplicación no reutiliza correctamente las sesiones. Consulta el apartado sobre referencia de la API RPC para obtener más información sobre el campo approximate_last_use_time.

Consulta los apartados sobre referencia de la API REST, referencia de la API RPC o referencia de CLI para obtener más información sobre el uso de ListSessions.

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…

Cloud Spanner Documentation