Sesiones

En esta página, se describe el concepto avanzado de las sesiones en Spanner, incluidas las prácticas recomendadas para las sesiones cuando se crea una biblioteca cliente, con las APIs de REST o RPC, o las bibliotecas cliente de Google.

Descripción general de las sesiones

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

Las sesiones pueden ejecutar una o varias transacciones a la vez. Cuándo cuando realizan varias transacciones, esta sesión se denomina sesión multiplexada.

Las operaciones de lectura, escritura y consultas independientes usan una transacción internamente.

Beneficios de rendimiento de un grupo de sesiones

Crear una sesión es costoso. Para evitar el costo de rendimiento cada vez que base de datos, los clientes deben mantener un grupo de sesión, que es un grupo de sesiones disponibles que están listas para usar. El grupo debe almacenar las sesiones existentes y mostrar el tipo adecuado de sesión cuando se solicite, así como controlar la limpieza de sesiones sin usar. Para ver un ejemplo de cómo implementar un grupo de sesiones, consulta el código fuente para una de las bibliotecas cliente de Spanner, como la La biblioteca cliente de Go o la biblioteca cliente de Java.

Las sesiones están pensadas para ser de larga duración, por lo que después de una sesión se usa durante un base de datos, el cliente debe devolver la sesión al grupo para que la reutilice.

Descripción general de los canales de gRPC

El cliente de Spanner usa los canales de gRPC para la comunicación. Un gRPC es más o menos equivalente a una conexión TCP. Un canal de gRPC puede controlar hasta 100 solicitudes simultáneas. Esto significa que una aplicación necesitará al menos tantos canales de gRPC como la cantidad de solicitudes simultáneas que la aplicación ejecutar, dividido por 100.

El cliente de Spanner crea un grupo de canales gRPC cuando crearla.

Prácticas recomendadas para usar bibliotecas cliente de Google

A continuación, se describen las prácticas recomendadas al utilizar el cliente de Google bibliotecas para Spanner.

Configura la cantidad de sesiones y canales de gRPC en los grupos

Las bibliotecas cliente tienen un número predeterminado de sesiones en el grupo de sesiones y, una cantidad predeterminada de canales gRPC en el grupo de canales. Ambos valores predeterminados son adecuados en la mayoría de los casos. A continuación, se muestran las sesiones mínimas y máximas predeterminadas, y la cantidad predeterminada de canales gRPC para cada lenguaje de programación.

C++

MinSessions: 100
MaxSessions: 400
NumChannels: 4

C#

MinSessions: 100
MaxSessions: 400
NumChannels: 4

Go

MinSessions: 100
MaxSessions: 400
NumChannels: 4

Java

MinSessions: 100
MaxSessions: 400
NumChannels: 4

Node.js

El cliente de Node.js no admite varios canales de gRPC. Por lo tanto, es se recomienda crear varios clientes en lugar de aumentar el tamaño de un grupo de sesiones más allá de 100 sesiones para un solo cliente.

MinSessions: 25
MaxSessions: 100

PHP

El cliente PHP no admite una cantidad configurable de canales gRPC.

MinSessions: 1
MaxSessions: 500

Python

Python admite cuatro tipos de grupos de sesiones diferentes que puedes usar para administrar las sesiones.

Ruby

El cliente Ruby no admite varios canales de gRPC. Por lo tanto, es se recomienda crear varios clientes en lugar de aumentar el tamaño de un grupo de sesiones más allá de 100 sesiones para un solo cliente.

MinSessions: 10
MaxSessions: 100

La cantidad de sesiones que usa tu aplicación es igual a la cantidad de transacciones simultáneas que ejecuta tu aplicación. Deberías modificar el configuración predeterminada del grupo de sesiones solo si esperas que haya una sola instancia de la aplicación para ejecutar más transacciones simultáneas de las que puede manejar el grupo de sesiones predeterminado.

Para aplicaciones de alta simultaneidad, se recomienda lo siguiente:

1. Establece MinSessions en la cantidad esperada de transacciones simultáneas que un se ejecutará un solo cliente.
2. Establece MaxSessions en la cantidad máxima de transacciones simultáneas que un que un solo cliente pueda ejecutar.
3. Configura MinSessions=MaxSessions si la simultaneidad esperada no cambia. mucho durante el ciclo de vida de la aplicación. Esto evita que el grupo de sesiones o reducir la escala verticalmente. Aumentar o disminuir la escala del grupo de sesiones también consume algo de Google Cloud.
4. Establece NumChannels en MaxSessions / 100. Un canal de gRPC puede manejar hasta 100 solicitudes en simultáneo Aumenta este valor si observas una cola alta latencia p95/p99), ya que esto podría ser un indicador de gRPC la congestión de los canales.

El aumento de la cantidad de sesiones activas consume recursos adicionales de la Servicio de base de datos de Spanner y en la biblioteca cliente. Aumentar el la cantidad de sesiones más allá de la necesidad real de la aplicación podría disminuir la el rendimiento del sistema.

Aumentar el grupo de sesiones en lugar de aumentar la cantidad de clientes

El tamaño del grupo de sesiones de una aplicación determina la cantidad de transacciones que puede ejecutar una sola instancia de aplicación. Aumenta la sesión tamaño del grupo superior a la simultaneidad máxima que una única instancia de aplicación puede no se recomienda el identificador. Si la aplicación recibe un aumento de solicitudes que va más allá de la cantidad de sesiones en el grupo, las solicitudes se ponen en cola mientras esperas a que haya una sesión disponible.

Los recursos que consume la biblioteca cliente son los siguientes:

1. Cada canal de gRPC usa una conexión TCP.
2. Cada invocación de gRPC requiere un subproceso. El número máximo de de subprocesos que utiliza la biblioteca cliente equivale a la cantidad máxima de consultas simultáneas que ejecuta la aplicación. Estas conversaciones aparecen primero de cualquier subproceso que la aplicación use para su propia lógica empresarial.

Aumenta el tamaño del grupo de sesiones más allá de la cantidad máxima de subprocesos que una sola instancia de aplicación puede controlar. En cambio, aumentar la cantidad de instancias de la aplicación.

Administra la fracción de sesiones de escritura

Para algunas bibliotecas cliente, Spanner reserva una parte de las sesiones para las transacciones de lectura y escritura, llamada fracción de sesiones de escritura. Si su aplicación usa todas las sesiones de lectura, Spanner usa la capa de lectura y escritura incluso para las transacciones de solo lectura. Las sesiones de lectura y escritura requieren una spanner.databases.beginOrRollbackReadWriteTransaction. Si el usuario se encuentra en el spanner.databaseReader rol de IAM, la llamada falla y Spanner devuelve este mensaje de error:

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

Para las bibliotecas cliente que mantienen una fracción de las sesiones de escritura, puedes establecer la fracción de las sesiones de escritura.

C++

Todas las sesiones de C++ son iguales. No hay sesiones de solo lectura o lectura y escritura.

C#

La fracción de sesiones de escritura predeterminada para C# es 0.2. Puedes cambiar el fracción con el campo WriteSessionsFraction de SessionPoolOptions.

Go

Todas las sesiones de Go son iguales. No hay sesiones de solo lectura o lectura y escritura.

Java

Todas las sesiones de Java son iguales. No hay sesiones de solo lectura o lectura y escritura.

Node.js

Todas las sesiones de Node.js son iguales. No hay sesiones de solo lectura o lectura y escritura.

PHP

Todas las sesiones de PHP son iguales. No hay sesiones de solo lectura o lectura y escritura.

Python

Python admite cuatro tipos de conjuntos de sesiones diferentes que puedes usar para administrar las sesiones de lectura y de lectura y escritura.

Ruby

La fracción de sesiones de escritura predeterminada para Ruby es 0.3. Puedes cambiar la fracción con el método de inicialización client.

Prácticas recomendadas para crear una biblioteca cliente o usar REST/RPC

A continuación, se describen las prácticas recomendadas para implementar sesiones en un cliente para Spanner o para usar sesiones con la API de REST o APIs de RPC.

Estas prácticas recomendadas solo se aplican si desarrollas una biblioteca cliente o si estás usando APIs de REST/RPC. Si usas uno de los servicios para Spanner, consulta Prácticas recomendadas para usar las bibliotecas cliente de Google.

Crea y ajusta el tamaño del grupo de sesiones

Si deseas determinar un tamaño óptimo del grupo de sesiones para un proceso de cliente, configura la para la cantidad de transacciones simultáneas esperadas y vinculadas a un número de prueba inicial, como 100. Si el límite superior no es adecuado, auméntalo. El aumento de la cantidad de sesiones activas consume recursos adicionales en el servicio de base de datos de Spanner, por lo que no se pueden limpiar las sesiones que no se usan puede disminuir el rendimiento. Para los usuarios que trabajan con la API de RPC, recomendamos tener un máximo de 100 sesiones por canal de gRPC.

Administra sesiones borradas

Hay tres formas de borrar una sesión:

• Un cliente puede borrar una sesión.
• El servicio de base de datos de Spanner puede borrar una sesión cuando esta inactivo por más de 1 hora.
• El servicio de base de datos de Spanner puede borrar una sesión si esta hace más de 28 días.

Los intentos de usar una sesión borrada darán como resultado NOT_FOUND. Si encuentras este error, crear y usar una nueva sesión, agregarla al grupo y quitar la sesión borrada del grupo.

Mantén en funcionamiento una sesión inactiva

El servicio de base de datos de Spanner se reserva el derecho de descartar sesión. Si necesitas sí o sí mantener en funcionamiento una sesión inactiva, por ejemplo, si se espera un aumento significativo en el uso de la base de datos a corto plazo, entonces puedes evitar que se descarte la sesión. Realiza una operación poco costosa, como la ejecución de la consulta de SQL SELECT 1 para mantener en funcionamiento la sesión. Si tienes un inactiva que no es necesaria para un uso a corto plazo, deja que Spanner descarte sesión y, luego, crea una nueva la próxima vez que necesites una.

Un caso para mantener en funcionamiento las sesiones es controlar la demanda máxima normal en la base de datos. Si el uso intensivo de bases de datos ocurre todos los días de 9:00 a.m. a 6:00 p.m., debes mantener algunas sesiones inactivas en funcionamiento durante ese tiempo, ya que es probable que sean necesarias durante el uso máximo. Después de las 6:00 p.m., podrás dejar que Spanner descarte sesiones inactivas. Antes de las 9:00 a.m. todos los días, crea algunas sesiones nuevas a fin de que estén listas para la demanda esperada.

Otra situación es si tienes una aplicación que usa Spanner, pero debe evitar la sobrecarga de conexión cuando lo hace. Puedes mantener un conjunto de sesiones en funcionamiento para evitar la sobrecarga de conexión.

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

Si creas una biblioteca cliente, no expongas las sesiones al cliente consumidor de la biblioteca. Proporciona al cliente la posibilidad de realizar llamadas a la base de datos sin la complejidad de crear y mantener sesiones. Por ejemplo, que oculta los detalles de la sesión al consumidor de la biblioteca cliente consulta la biblioteca cliente de Spanner para Java.

Soluciona errores para escribir transacciones que no son idempotentes

Las transacciones de escritura sin protección de reproducción pueden aplicar mutaciones más de una vez. Si una mutación no es idempotente, una mutación que se aplica más de una vez podría provocar un error. Por ejemplo, una inserción puede fallar con ALREADY_EXISTS, incluso si la fila no existía antes del intento de escritura. Esto podría ocurrir si el servidor de backend confirmó la mutación, pero no pudo comunicar el resultado exitoso al cliente. En ese caso, se podría intentar otra vez la mutación, lo que provocaría el error ALREADY_EXISTS.

A continuación, se indican algunas formas posibles de solucionar esta situación cuando implementas tu propia biblioteca cliente o usas la API de REST:

• Estructura las escrituras para que sean idempotentes.
• Usa escrituras con protección de reproducción.
• Implementa un método que ejecute la lógica “upsert”: inserta una nueva o actualiza la existente.
• Soluciona el error en nombre del cliente.

Mantén conexiones estables

A fin de obtener el mejor rendimiento, la conexión que usas para alojar una sesión debe permanecer estable. Cuando cambia la conexión que aloja una sesión, Spanner podría anular la transacción activa en la sesión y causar carga adicional en tu base de datos mientras actualiza los metadatos de la sesión. No hay problema si algunas conexiones cambian de forma esporádica, pero debes evitar situaciones que podrían cambiar una gran cantidad de conexiones al mismo tiempo. Si usas un proxy entre el cliente y Spanner, debes mantener la estabilidad de la conexión para cada sesión.

Supervisa las sesiones activas

Puedes usar el comando ListSessions para supervisar las sesiones activas en tu base de datos desde la línea de comandos, con la API de REST o con la API de RPC. ListSessions muestra las sesiones activas de una base de datos determinada. Esto es útil si necesitas buscar la causa de una pérdida de sesión. (Una fuga de sesión es un incidente en el que las sesiones pero no se devuelven a un grupo de sesiones para reutilizarlo).

ListSessions te permite ver los metadatos de tus sesiones activas, lo que incluye cuándo se creó una sesión y cuándo se usó por última vez. Si analizas estos datos, te guiarán en la dirección correcta para solucionar problemas de sesiones. Si la mayoría las sesiones activas no tienen un approximate_last_use_time reciente, esto podría indicar que tu aplicación no está reutilizando correctamente las sesiones. Consulta la Referencia de la API de RPC para obtener más información sobre el campo approximate_last_use_time.

Consulta la referencia de la API de REST, la referencia de la API de RPC o el comando de gcloud referencia de la herramienta de línea de comandos para obtener más información sobre el uso de ListSessions.

Limpieza automática de filtraciones de sesión

Vista previa — Automatic cleanup of session leaks

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Cuando usas todas las sesiones en tu grupo de sesiones, cada transacción nueva Espera hasta que una sesión regrese al grupo. Cuándo se crean las sesiones pero no se devuelve al grupo de sesiones para que se reutilice, lo que se denomina fuga de sesión. Cuando se produce una fuga de sesión, las transacciones que esperan una sesión abierta se detienen de manera indefinida y bloquear la aplicación. Las fugas de sesiones suelen deberse a transacciones problemáticas que se ejecutan durante un tiempo extremadamente largo y no están comprometidos.

Puedes configurar tu grupo de sesiones para resolver automáticamente estos problemas transacciones inactivas. Cuando habilitas tu biblioteca cliente para que resuelve la transición inactiva, identifica las transacciones problemáticas que podría causar una fuga de sesión, quitarla del grupo de sesiones los reemplaza por una nueva sesión.

Los registros también pueden ayudar a identificar estas transacciones problemáticas. Si el registro está habilitado, los registros de advertencia se comparten de forma predeterminada cuando hay más de El 95% de tu grupo de sesiones está en uso. Si el uso de tu sesión supera el 95%, debe aumentar la cantidad máxima de sesiones permitidas en su grupo de sesiones o una pérdida de sesión. Los registros de advertencia contienen una pila registros de transacciones que se ejecutan por más tiempo del esperado y pueden a identificar la causa del alto uso del grupo de sesiones. Los registros de advertencia se envían según la configuración del exportador de registros.

Habilitar la biblioteca cliente para resolver automáticamente las transacciones inactivas

Puedes habilitar la biblioteca cliente para que envíe registros de advertencia y resuelve las transacciones inactivas o habilita la biblioteca cliente para que solo reciba advertencias los registros del sistema operativo.

Java

Para recibir registros de advertencia y quitar transacciones inactivas, usa setWarnAndCloseIfInactiveTransactions.

 final SessionPoolOptions sessionPoolOptions = SessionPoolOptions.newBuilder().setWarnAndCloseIfInactiveTransactions().build()

 final Spanner spanner =
         SpannerOptions.newBuilder()
             .setSessionPoolOption(sessionPoolOptions)
             .build()
             .getService();
 final DatabaseClient client = spanner.getDatabaseClient(databaseId);

Para recibir solo los registros de advertencia, usa setWarnIfInactiveTransactions.

 final SessionPoolOptions sessionPoolOptions = SessionPoolOptions.newBuilder().setWarnIfInactiveTransactions().build()

 final Spanner spanner =
         SpannerOptions.newBuilder()
             .setSessionPoolOption(sessionPoolOptions)
             .build()
             .getService();
 final DatabaseClient client = spanner.getDatabaseClient(databaseId);

Go

Para recibir registros de advertencia y quitar transacciones inactivas, usa SessionPoolConfig con InactiveTransactionRemovalOptions.

 client, err := spanner.NewClientWithConfig(
     ctx, database, spanner.ClientConfig{SessionPoolConfig: spanner.SessionPoolConfig{
         InactiveTransactionRemovalOptions: spanner.InactiveTransactionRemovalOptions{
         ActionOnInactiveTransaction: spanner.WarnAndClose,
         }
     }},
 )
 if err != nil {
     return err
 }
 defer client.Close()

Para recibir solo los registros de advertencias, usa customLogger.

 customLogger := log.New(os.Stdout, "spanner-client: ", log.Lshortfile)
 // Create a logger instance using the golang log package
 cfg := spanner.ClientConfig{
         Logger: customLogger,
     }
 client, err := spanner.NewClientWithConfig(ctx, db, cfg)

Sesiones multiplexadas

Las sesiones multiplexadas te permiten crear una cantidad ilimitada de solicitudes simultáneas de una vez. Las sesiones multiplexadas tienen las siguientes ventajas:

• Se redujeron los requisitos de recursos de backend. Por ejemplo, evitan las sesiones de mantenimiento asociadas con el mantenimiento de la propiedad de la sesión la recolección de elementos no utilizados.
• Sesión de larga duración que no requiere solicitudes de keep-alive cuando está inactiva
• Las bibliotecas cliente típicas pueden usar una sesión multiplexada para cada cliente. El la cantidad de sesiones regulares en uso es menor para los clientes que utilizan multiplexados para algunas operaciones en comparación con clientes que solo usan sesiones.
• No es necesario tener afinidad con un solo canal de gRPC. Los clientes pueden enviar solicitudes en varios canales para la misma sesión multiplexada.

Las sesiones multiplexadas admiten lo siguiente:

• La biblioteca cliente de Java
• Herramientas del ecosistema de Spanner que dependen de la biblioteca cliente de Java, como PGAdapter, JDBC y Hibernate
• APIs de Spanner para transacciones de solo lectura

Usa las métricas de OpenTelemetry para ver cómo se divide el tráfico. entre el grupo de sesiones existente y la sesión multiplexada. OpenTelemetry tiene un filtro de métrica, is_multiplexed, que muestra las sesiones multiplexadas cuando se establece en true

Las sesiones multiplexadas están habilitadas de forma predeterminada para el adaptador de JDBC y PG. Para Java está inhabilitada de forma predeterminada. Se usa el Biblioteca cliente de Java para habilitar las sesiones multiplexadas. Para habilitar una sesión multiplexada con Java, consulta Habilita las sesiones multiplexadas.

Habilitar sesiones multiplexadas

Para habilitar las sesiones multiplexadas con el cliente Java, configura De GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS a true.

export GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS=TRUE

Consulta el tráfico de las sesiones regulares y multiplexadas

Opentelemetry tiene el filtro is_multiplexed para mostrar el tráfico de las sesiones multiplexadas. Establece este filtro en true to view multiplexed sessions andfalse` para ver las sesiones regulares.

1. Configura OpenTelemetry para Spanner con los procedimientos de la OpenTelemetry de Spanner Antes de comenzar sección.

2. Navega al Explorador de métricas.

   Ir al Explorador de métricas

3. En el menú desplegable Métrica, filtra por generic.

4. Haz clic en Tarea genérica y navega a Spanner > Spanner/num_acquired_sessions.

5. En el campo Filtro, selecciona una de las siguientes opciones:

   a. is_multiplexed = false para ver las sesiones regulares. b. is_multiplexed = true para ver las sesiones multiplexadas.

   En la siguiente imagen, se muestra la opción Filtrar con sesiones multiplexadas seleccionado.

Para obtener más información sobre el uso de OpenTelemetry con Spanner, consulta Aprovecha OpenTelemetry para democratizar la observabilidad de Spanner y Examinar la latencia en un componente de Spanner con OpenTelemetry