Sessões

Visão geral das sessões

Nesta página, é descrito o conceito avançado de sessões no Cloud Spanner, incluindo práticas recomendadas para sessões quando você criar uma biblioteca de cliente ou quando usar as APIs REST ou RPC.

Uma sessão representa um canal de comunicação com o serviço de banco de dados do Cloud Spanner. Ela é usada para executar transações que leem, gravam ou modificam dados em um banco de dados do Cloud 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 um exemplo de como implementar um cache de sessão, consulte o código-fonte de uma das bibliotecas de cliente do Cloud Spanner, como a biblioteca de cliente Go ou a biblioteca de 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

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

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. Para usuários que trabalham com a API RPC, recomendamos que o cache não armazene mais de 100 sessões porque 100 é o número máximo de sessões simultâneas por canal gRPC. Se o limite superior não for adequado, aumente-o. Ao aumentar o número de sessões ativas, você usa recursos adicionais no serviço de banco de dados do Cloud Spanner. Portanto, a falta de limpeza de sessões não utilizadas pode degradar o desempenho ou impedir que você use o banco de dados do Cloud Spanner por até uma hora.

Há um limite de 10.000 sessões por banco de dados por nó. Saiba mais sobre os limites do Cloud Spanner em Limites.

Lidar com sessões excluídas

Há duas maneiras de excluir uma sessão:

  • Um cliente pode excluir uma sessão.
  • O serviço de banco de dados do Cloud Spanner pode excluir uma sessão quando a sessão estiver inativa por mais de uma hora.

As tentativas de usar uma sessão excluída resultam no erro NOT_FOUND. Nesse caso, crie e use uma nova sessão, adicione-a ao cache e remova a sessão excluída dele.

Manter uma sessão inativa operante

O serviço de banco de dados do Cloud Spanner reserva-se o direito de encerrar 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. Para manter a sessão ativa, realize uma operação de baixo custo, como executar a consulta SQL SELECT 1. Se você tiver uma sessão inativa que não precisará usar em curto prazo, deixe o Cloud Spanner encerrar a sessão e crie uma sessão nova na próxima vez em 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, deixe o Cloud Spanner encerrar as sessões inativas. 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 Cloud 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 um exemplo de uma biblioteca de cliente que oculta os detalhes da sessão do consumidor, consulte a biblioteca de cliente do Cloud 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 uma sessão é alterada, o Cloud Spanner pode anular 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. Quando você usar um proxy entre o cliente e o Cloud Spanner, a estabilidade da conexão deverá ser mantida em todas as sessões.

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 a API RPC. ListSessions mostra as sessões ativas para um determinado banco de dados. Isso é útil se você atingir frequentemente o limite da sessão e precisar identificar sessões para excluir ou descobrir 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 tiverem um approximate_last_use_time recente, isso pode indicar que as sessões não estão sendo reutilizadas corretamente pelo aplicativo. Para mais informações sobre o campo approximate_last_use_time, consulte a referência da API RPC.

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.

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

Para a maioria das bibliotecas de cliente, o Cloud 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 seu aplicativo usar todas as sessões de leitura, o Cloud Spanner usará as sessões de leitura e gravação, mesmo para transações somente leitura. As sessões de leitura e gravação requerem spanner.databases.beginOrRollbackReadWriteTransaction. Se o usuário estiver no papel spanner.databaseReader do IAM, a chamada falhará e o Cloud Spanner retornará a seguinte 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#

Embora a biblioteca de cliente C# controle se uma sessão foi usada na última vez para uma transação de leitura ou para uma transação de leitura e gravação, o conjunto de sessões de leitura e das sessões de leitura e gravação não é fixo. Uma fração de sessões de gravação não é aplicada ao conjunto de sessões e, portanto, não há API para alterá-las.

Go

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

Java

A fração padrão de sessões de gravação para Java é 0.2. Você pode alterar a fração usando o método setWriteSessionsFraction. O exemplo de código a seguir mostra como definir a fração:

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

Ao usar Java, o Cloud Spanner retorna o erro quando você chama singleUseReadOnlyTransaction() e não há sessões de leitura disponíveis.

Node.js

A fração padrão de sessões de gravação para o Node.js é 0 (zero). Você pode 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.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Cloud Spanner