Sessões

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Visão geral das sessões

Nesta página, descrevemos o conceito avançado de sessões no Spanner, incluindo práticas recomendadas para sessões ao criar uma biblioteca de cliente, usando as APIs REST ou RPC ou usando as bibliotecas de cliente do Google.

Uma sessão representa um canal de comunicação com o serviço de banco de dados do Spanner. Uma sessão é usada para executar transações que leiam, gravem ou modifiquem dados em um banco de dados do Spanner. Cada sessão aplica-se a um único banco de dados.

Com as sessões é possível executar apenas uma transação por vez. Leituras, gravações e consultas independentes usam uma transação internamente e contam para o limite de uma transação.

Benefícios de desempenho de um cache de sessão

Criar uma sessão é algo caro. Para evitar o custo de desempenho sempre que uma operação de banco de dados for realizada, os clientes podem manter um cache de sessão, que é um conjunto de sessões disponíveis, prontas para serem usadas. O cache armazena as sessões existentes e retorna o tipo de sessão apropriado quando solicitado, além de lidar com a limpeza das sessões não utilizadas. Para ver um exemplo de como implementar um cache de sessão, consulte o código-fonte de uma das bibliotecas de cliente do Spanner, como a biblioteca de cliente Go ou a biblioteca cliente Java.

Pretende-se que as sessões tenham duração longa. Portanto, após o uso de uma sessão em uma operação de banco de dados, o cliente deve retornar a sessão ao cache para reutilização.

Práticas recomendadas ao usar bibliotecas de cliente do Google

Veja a seguir as práticas recomendadas ao usar as bibliotecas de cliente do Google para o Spanner.

Como configurar o número de sessões

Em geral, não recomendamos modificar o número padrão de sessões usadas pelas bibliotecas de cliente.

Se você tiver uma carga de trabalho especial, recomendamos definir o limite inferior para o número de transações simultâneas esperadas e definir o limite superior para um número de teste inicial, como 100. Se o limite superior não for adequado, aumente-o. Aumentar o número de sessões ativas usa recursos extras no serviço de banco de dados do Spanner. Portanto, não limpar sessões não utilizadas pode prejudicar o desempenho. Também recomendamos que você não tenha mais de 100 sessões por canal gRPC.

Gerenciar a fração de sessões de gravação

Para a maioria das bibliotecas de cliente, o Spanner reserva uma parte das sessões para transações de leitura e gravação, chamada de fração de sessões de gravação. Se o aplicativo usa todas as sessões de leitura, o Spanner usa as sessões de leitura/gravação, mesmo para transações somente leitura. As sessões de leitura e gravação exigem spanner.databases.beginOrRollbackReadWriteTransaction. Se o usuário estiver no papel do IAM spanner.databaseReader, a chamada falhará e o Spanner retornará esta mensagem de erro:

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

É possível definir a fração de sessões de gravação para as bibliotecas de cliente que mantêm uma fração de sessões de gravação.

C++

Todas as sessões em C ++ são iguais. Não há sessões somente de leitura ou sessões de leitura e gravação.

C#

A fração padrão de sessões de gravação para C# é 0,2. É possível alterar a fração usando o campo "WriteSessionsFraction" de SessionPoolOptions.

Go

A fração de sessões de gravação padrão para Go é de 0,2. É possível alterar a fração usando o campo WriteSessions de SessionPoolConfig.

Java

Todas as sessões do Java são iguais. Não há sessões somente de leitura ou sessões de leitura e gravação.

Node.js

A fração padrão de sessões de gravação para o Node.js é 0 (zero). É possível alterar a fração usando o campo de gravações.

PHP

Todas as sessões do PHP são as mesmas. Não há sessões somente de leitura ou sessões de leitura e gravação.

Python

O Python é compatível com quatro tipos diferentes de tipos de pool de sessões, que podem ser usados para gerenciar sessões de leitura e sessões de leitura e gravação.

Ruby

A fração padrão de sessões de gravação para Ruby é 0.3. Para alterar a fração, use o método de inicialização do cliente.

Práticas recomendadas ao criar uma biblioteca de cliente ou usar REST/RPC

Veja a seguir as práticas recomendadas para implementar sessões em uma biblioteca de cliente do Spanner ou para usar sessões com as APIs REST ou RPC.

Essas práticas recomendadas se aplicam somente se você estiver desenvolvendo uma biblioteca de cliente ou se estiver usando APIs REST/RPC. Se você estiver usando uma das bibliotecas de cliente do Google para o Cloud Spanner, consulte Práticas recomendadas ao usar bibliotecas de cliente do Google.

Criar e dimensionar o cache da sessão

Para determinar um tamanho ideal do cache da sessão para um processo do cliente, defina o limite inferior para o número de transações simultâneas esperadas e defina o limite superior para um número de teste inicial, como 100. Se o limite superior não for adequado, aumente-o. Aumentar o número de sessões ativas usa recursos extras no serviço de banco de dados do Spanner. Portanto, não limpar sessões não utilizadas pode prejudicar o desempenho. Para usuários que trabalham com a API RPC, recomendamos não ter mais de 100 sessões por canal gRPC.

Lidar com sessões excluídas

Há três maneiras de excluir uma sessão:

  • Um cliente pode excluir uma sessão.
  • O serviço de banco de dados do Spanner pode excluir uma sessão quando ela estiver inativa por mais de uma hora.
  • O serviço de banco de dados do Spanner poderá excluir uma sessão se ela tiver mais de 28 dias.

As tentativas de usar uma sessão excluída resultam em NOT_FOUND. Se você encontrar esse erro, crie e use uma nova sessão, adicione a nova sessão ao cache e remova a sessão excluída do cache.

Manter uma sessão inativa operante

O serviço de banco de dados do Spanner reserva-se o direito de remover uma sessão não utilizada. É possível impedir que a sessão seja encerrada, se você precisar mesmo manter uma sessão inativa operante, por exemplo, se for esperado um aumento significativo de curto prazo no uso do banco de dados. Realizar uma operação de baixo custo, como executar a consulta SQL SELECT 1 para manter a sessão ativa. Se você tiver uma sessão inativa que não seja necessária para o uso a curto prazo, deixe o Spanner eliminar a sessão e crie uma nova sessão na próxima vez que ela for necessária.

Um cenário para manter as sessões ativas é lidar com a demanda de pico regular no banco de dados. Se ocorre um uso intenso do banco de dados diariamente das 9h às 18h, mantenha algumas sessões inativas disponíveis durante esse período, uma vez que elas provavelmente serão necessárias para o uso no horário de pico. Após as 18h, você pode deixar o Spanner perder sessões de inatividade. Todos os dias, antes das 9h, crie algumas sessões novas para que elas estejam prontas para a demanda esperada.

Outro cenário é se você tem um aplicativo que usa o Spanner, mas precisa evitar a sobrecarga de conexão. Mantenha um conjunto de sessões ativas para evitar que a sobrecarga de conexão aconteça.

Ocultar detalhes da sessão do usuário da biblioteca de cliente

Se você estiver criando uma biblioteca de cliente, não exponha sessões ao consumidor da biblioteca de cliente. Permita que o cliente faça chamadas de banco de dados sem a complexidade de criar e manter sessões. Para ver um exemplo de uma biblioteca de cliente que oculta os detalhes da sessão do consumidor da biblioteca de cliente, consulte a biblioteca de cliente do Spanner para Java.

Lidar com erros de transações de gravação que não sejam idempotentes

As transações de gravação sem proteção de repetição podem aplicar mutações mais de uma vez. Se uma mutação não é idempotente, uma mutação que é aplicada mais de uma vez pode resultar em uma falha. Por exemplo, uma inserção pode apresentar falha com ALREADY_EXISTS mesmo que a linha não exista antes da tentativa de gravação. Isso pode ocorrer se o servidor de back-end confirmou a mutação, mas não conseguiu comunicar o sucesso ao cliente. Nesse caso, a mutação poderia ser tentada novamente, resultando na falha ALREADY_EXISTS.

Estas são as formas possíveis de abordar esse cenário quando você implementa sua própria biblioteca de cliente ou usa a API REST:

  • Estruturar suas gravações para que sejam idempotentes.
  • Usar gravações com proteção contra repetição.
  • Implementar um método que execute a lógica "upsert": inserir se for novo ou atualizar se existir.
  • Lidar com o erro em nome do cliente.

Manter conexões estáveis

Para melhor desempenho, a conexão utilizada para hospedar uma sessão deve permanecer estável. Quando a conexão que hospeda a sessão muda, o Spanner pode cancelar a transação ativa na sessão e causar uma pequena carga extra no banco de dados enquanto atualiza os metadados da sessão. Não há problema se algumas conexões mudarem esporadicamente, mas devem ser evitadas situações em que um grande número de conexões mudam ao mesmo tempo. Se você usa um proxy entre o cliente e o Spanner, é preciso manter a estabilidade da conexão para cada sessão.

Como monitorar sessões ativas

É possível usar o comando ListSessions para monitorar sessões ativas no banco de dados a partir da linha de comando, com a API REST ou com a API RPC. ListSessions mostra as sessões ativas de um determinado banco de dados. Isso é útil se você precisa encontrar a causa de um vazamento de sessão. (Um vazamento de sessão é um incidente em que as sessões estão sendo criadas, mas não retornadas para um cache de sessão para reutilização.)

Com o comando ListSessions, você visualiza metadados das sessões ativas, inclusive quando uma sessão foi criada e quando uma sessão foi usada pela última vez. Analisar esses dados vai lhe mostrar a direção certa na hora de solucionar problemas. Se a maioria das sessões ativas não tiver um approximate_last_use_time recente, isso pode indicar que as sessões não estão sendo reutilizadas corretamente pelo seu aplicativo. Veja a Referência da API RPC para mais informações sobre approximate_last_use_time campo.

Para mais informações sobre como usar ListSessions, consulte a referência da API REST, a referência da API RPC ou a referência da ferramenta de linha de comando gcloud.