Conjuntos de ligações

Este tópico descreve como funcionam os conjuntos de ligações no Bigtable, os impactos que o tamanho do conjunto de ligações pode ter numa aplicação que usa o Bigtable e quando pode querer alterar as predefinições do conjunto de ligações.

Depois de ler esta página, se determinar que deve alterar o tamanho do conjunto de ligações, consulte o artigo Configurar conjuntos de ligações para saber como determinar o tamanho ideal e como alterá-lo. O número de ligações em cada conjunto é configurável no seu código apenas quando usa as bibliotecas de cliente Go, C++ ou Java para o Cloud Bigtable.

Como funcionam os conjuntos de ligações

Um conjunto de ligações, também conhecido como conjunto de canais, é uma cache de ligações à base de dados que são partilhadas e reutilizadas para melhorar a latência e o desempenho das ligações. As ligações são usadas num sistema de round robin.

Quando usa o Bigtable, cria um único cliente de dados por processo de aplicação. Cada cliente tem um conjunto de ligações. Cada conjunto de ligações contém um determinado número de ligações gRPC, que podem processar até 100 streams simultâneas. Os pedidos enviados através destas ligações passam pelo middleware da Google, que os encaminha para a sua tabela. A camada de middleware é composta por muitas instâncias com equilíbrio de carga, e cada pedido é encaminhado através da instância de middleware com a maior disponibilidade.

Pode pensar numa ligação (ou canal) como uma autoestrada com até 100 faixas e cada faixa (stream) só pode conter um carro (pedido) em qualquer altura. O limite de 100 streams simultâneas por ligação gRPC é aplicado na camada de middleware da Google e não é possível reconfigurar este número.

Uma associação é atualizada automaticamente a cada hora. Além disso, se uma ligação não receber um pedido em cinco minutos, o middleware elimina automaticamente a ligação e não a recria até ser necessária uma ligação adicional.

Nos bastidores, cada canal tem um único subcanal. Cada subcanal tem uma ligação HTTP2 que usa TCP para converter pedidos em bytes e enviá-los através do middleware e, em seguida, para a sua tabela. Este processo é processado de forma integrada pelo serviço Bigtable, e não tem de configurar nada para que aconteça.

Conjuntos de ligações e tráfego

Como os conjuntos de ligações afetam o desempenho

Idealmente, deve ter ligações gRPC suficientes para processar os seus pedidos sem armazenamento em buffer. No entanto, não deve ter tantas associações que sejam frequentemente eliminadas por falta de utilização.

Não existem associações suficientes

Se um conjunto de ligações não tiver ligações suficientes para processar o seu tráfego, o middleware começa a armazenar em buffer e a colocar pedidos em fila. Esta colocação no buffer abranda o tráfego, reduzindo o número de pedidos por segundo e aumentando a latência à medida que os pedidos ficam em espera.

Demasiadas ligações

Se um conjunto tiver demasiadas ligações, o que significa que algumas das ligações estão inativas, o middleware desliga as ligações inativas. Em seguida, quando chegam novos pedidos que os requerem, estas associações são restabelecidas. Isto significa que, quando o tráfego aumenta, os pedidos podem encontrar uma falha na cache do lado do servidor, o que causa trabalho e latência adicionais. Se isto acontecer com frequência devido a níveis de tráfego variáveis, esta atividade pode manifestar-se como um aumento percetível na latência final do lado do cliente.

Quando alterar as predefinições

O tamanho predefinido do conjunto de ligações é adequado para a maioria das aplicações e, na maioria dos casos, não é necessário alterá-lo. Consoante a biblioteca de cliente que usar na sua aplicação, pode não conseguir alterar o tamanho do conjunto de ligações. O número de ligações em cada conjunto é configurável no seu código apenas quando usa as bibliotecas de cliente Go, C++ ou Java para o Cloud Bigtable.

Geralmente, um conjunto de ligações ideal tem, pelo menos, o dobro do número de ligações necessárias para a saturação máxima. Isto deixa espaço para flutuações no tráfego. Por exemplo, se tiver 4 ligações e cada uma estiver a processar o número máximo de pedidos possível (100), quer reduzir o número de pedidos por ligação para um número entre 10 e 50, pelo que o tamanho ideal do conjunto de ligações é, pelo menos, o dobro, ou um mínimo de 8 ligações.

Os sinais que deve considerar para alterar o número de ligações no conjunto incluem o seguinte:

Débito baixo combinado com picos na latência final do lado do cliente

Se o seu débito típico for relativamente baixo, como menos de um pedido por segundo por ligação, e observar uma latência de cauda periodicamente elevada para a sua aplicação, pode não estar a enviar tráfego suficiente para manter as ligações ativas. Neste caso, pode ter de diminuir o número de ligações no conjunto. Consulte o artigo Configurar conjuntos de ligações para saber como determinar o número certo.

Pedidos na memória intermédia

Se observar que os pedidos se acumulam no lado do cliente, isto pode indicar que está a enviar mais pedidos simultâneos do que o conjunto de ligações consegue processar. Calcule o número ideal e, em seguida, altere o código, se necessário.

Para determinar se os pedidos estão a acumular-se, pode usar o OpenCensus para analisar a diferença entre as métricas grpc.io/client/started_rpcs e grpc.io/client/completed_rpcs.

Ambiente virtual

Em alguns casos raros, o cliente do Bigtable não consegue determinar o número de CPUs em que a aplicação está a ser executada e atribui ligações como se apenas uma CPU estivesse em utilização. Por exemplo, isto pode acontecer quando usa instâncias de CPU virtual no Kubernetes ou no Docker. Se isto for evidente, deve configurar o número de pools de acordo com as diretrizes com base no QPS e na latência da sua aplicação.

O que se segue