Sessões

Visão geral das sessões

Esta página descreve 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 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 realizar transações que leem, gravam ou modificam 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 do desempenho de um pool de sessões

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

As sessões devem ser de longa duração. Portanto, depois que uma sessão é usada para uma operação de banco de dados, o cliente deve retornar a sessão ao pool para reutilização.

Visão geral dos canais gRPC

Os canais gRPC são usados pelo cliente do Cloud Spanner para comunicação. Um canal gRPC é aproximadamente equivalente a uma conexão TCP. Um canal gRPC pode lidar com até 100 solicitações simultâneas. Isso significa que um aplicativo precisará de pelo menos tantos canais gRPC quanto o número de solicitações simultâneas que o aplicativo executará, dividido por 100.

O cliente do Cloud Spanner criará um pool de canais gRPC quando ele for criado.

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 e canais gRPC nos pools

As bibliotecas de cliente têm um número padrão de sessões no pool de sessões e um número padrão de canais gRPC no pool de canais. Ambos os padrões são adequados para a maioria dos casos. Veja a seguir as sessões mínima e máxima padrão e o número padrão de canais gRPC para cada linguagem de programação.

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

O cliente Node.js não é compatível com vários canais gRPC. Portanto, é recomendável criar vários clientes em vez de aumentar o tamanho do pool de sessões para mais de 100 sessões para um único cliente.

MinSessions: 25
MaxSessions: 100

PHP

O cliente PHP não aceita um número configurável de canais gRPC.

MinSessions: 1
MaxSessions: 500

Python

O Python é compatível com quatro diferentes tipos de pool de sessões que podem ser usados para gerenciar sessões.

Ruby

O cliente Ruby não é compatível com vários canais gRPC. Portanto, é recomendável criar vários clientes em vez de aumentar o tamanho do pool de sessões para mais de 100 sessões para um único cliente.

MinSessions: 10
MaxSessions: 100

O número de sessões que seu aplicativo usa é igual ao número de transações simultâneas que ele executa. Modifique as configurações padrão do pool de sessões somente se você espera que uma única instância do aplicativo execute mais transações simultâneas do que o pool de sessões padrão pode processar.

Para aplicativos de alta simultaneidade, o seguinte é recomendado:

  1. Defina MinSessions com o número esperado de transações simultâneas que um único cliente executará.
  2. Defina MaxSessions como o número máximo de transações simultâneas que um único cliente pode executar.
  3. Defina MinSessions=MaxSessions se a simultaneidade esperada não mudar muito durante a vida útil do aplicativo. Isso impede que o pool de sessões seja escalonado para mais ou para menos. O escalonamento do pool de sessões para mais ou para menos também consome alguns recursos.
  4. Defina NumChannels como MaxSessions / 100. Um canal gRPC pode processar até 100 solicitações simultaneamente. Aumente esse valor se você observar uma latência de cauda alta (latência p95/p99), porque isso pode ser uma indicação de congestionamento do canal gRPC.

Aumentar o número de sessões ativas usa recursos adicionais no serviço de banco de dados do Spanner e na biblioteca de cliente. Aumentar o número de sessões além da necessidade real do aplicativo pode prejudicar o desempenho do sistema.

Aumentar o pool de sessões x aumentar o número de clientes

O tamanho do pool de sessões de um aplicativo determina quantas transações simultâneas uma única instância de aplicativo pode executar. Não é recomendável aumentar o tamanho do pool de sessões além da simultaneidade máxima que uma única instância de aplicativo pode processar. Se o aplicativo receber um burst de solicitações que vai além do número de sessões no pool, as solicitações são enfileiradas enquanto aguardam a disponibilização de uma sessão.

Os recursos consumidos pela biblioteca de cliente são os seguintes:

  1. Cada canal gRPC usa uma conexão TCP.
  2. Cada invocação do gRPC requer uma linha de execução. O número máximo de linhas de execução usado pela biblioteca de cliente é igual ao número máximo de consultas simultâneas que o aplicativo executa. Essas linhas de execução vêm sobre todas as linhas de execução que o aplicativo usa para sua própria lógica de negócios.

Não é recomendável aumentar o tamanho do pool de sessões além do número máximo de linhas de execução que uma única instância de aplicativo pode processar. Em vez disso, aumente o número de instâncias do aplicativo.

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

Para algumas 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 seu aplicativo usar todas as sessões de leitura, o Spanner usará as sessões de leitura e 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 spanner.databaseReader do IAM, 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

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

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

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

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 pool de sessões

Para determinar o tamanho ideal do pool de sessões para um processo do cliente, defina o limite inferior como o número esperado de transações simultâneas e o limite superior como 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 adicionais no serviço de banco de dados do Spanner. Portanto, não limpar as sessões não usadas 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 ficar 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 no erro NOT_FOUND. Se você encontrar esse erro, crie e use uma nova sessão, adicione-a ao pool e remova a sessão excluída do pool.

Manter uma sessão inativa operante

O serviço de banco de dados do Spanner reserva-se o direito de descartar 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 é necessária em curto prazo, deixe o Spanner descartá-la e crie uma 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 Spanner cair em 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 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 uma sessão muda, o Spanner pode cancelar a transação ativa na sessão e causar uma pequena quantidade de 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, mantenha 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 pool de sessões 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.