Noções básicas de desempenho do Cloud Bigtable

Nesta página, descrevemos o desempenho aproximado que o Cloud Bigtable pode alcançar em condições ideais, os fatores que podem afetar esse desempenho e dicas para testar e solucionar problemas de desempenho do Cloud Bigtable.

Desempenho em cargas de trabalho típicas

O Cloud Bigtable fornece um desempenho altamente previsível que pode ser escalonado linearmente. Ao evitar as causas de desempenho mais lento descritas abaixo, cada nó do Cloud Bigtable pode fornecer a seguinte capacidade aproximada, dependendo do tipo de armazenamento usado pelo cluster:

Tipo de armazenamento Leituras   Gravações   Verificações
SSD até 10.000 linhas por segundo ou até 10.000 linhas por segundo ou até 220 MB/s
HDD até 500 linhas por segundo ou até 10.000 linhas por segundo ou até 180 MB/s

Essas estimativas pressupõem que tenha 1 KB de dados em cada linha.

Em geral, o desempenho de um cluster aumenta linearmente à medida que nós são adicionados ao cluster. Por exemplo, se você criar um cluster SSD com 10 nós, ele aceitará até 100.000 linhas por segundo para uma carga de trabalho típica somente leitura ou somente gravação.

Como planejar a capacidade do Cloud Bigtable

O equilíbrio entre alta capacidade e baixa latência

Ao planejar os clusters do Cloud Bigtable, é importante pensar sobre o equilíbrio entre capacidade e latência. O Cloud Bigtable é usado em um amplo espectro de aplicativos, e diferentes casos de uso podem ter metas de otimização distintas. Por exemplo, para um job de processamento de dados em lote, normalmente a capacidade tem prioridade sobre a latência. Por outro lado, um serviço on-line que atende solicitações de usuários pode priorizar uma latência mais baixa em relação à capacidade. Assim, é importante planejar a capacidade caso a caso.

É possível atingir os números da seção Desempenho para cargas de trabalho típicas priorizando a capacidade, mas a latência de cauda do Cloud Bigtable sob essa carga pode ser alta demais para aplicativos sensíveis à latência. Em geral, o Cloud Bigtable oferece latência ideal quando a carga da CPU para um cluster fica abaixo de 70%. No entanto, para aplicativos sensíveis à latência, recomendamos que você planeje pelo menos duas vezes a capacidade máxima de QPS do Cloud Bigtable do aplicativo. Essa capacidade garante que seu cluster do Cloud Bigtable seja executado com menos de 50% da carga da CPU, oferecendo baixa latência aos serviços de front-end. Ela também fornece um buffer para picos de tráfego ou de pontos de acesso a chaves, que poderiam causar um desequilíbrio no tráfego entre os nós do cluster.

Execute suas cargas de trabalho típicas no Cloud Bigtable

Sempre execute suas próprias cargas de trabalho típicas em um cluster do Cloud Bigtable ao planejar a capacidade. Assim, você descobrirá a melhor alocação de recursos para seus aplicativos.

O PerfKit Benchmarker do Google usa o YCSB para comparar serviços de nuvem. Siga o tutorial do PerfKitBenchmarker para o Cloud Bigtable (em inglês) e crie testes para suas próprias cargas de trabalho. Ao fazer isso, ajuste os parâmetros nos arquivos de configuração de comparativo de mercado yaml para garantir que o comparativo de mercado gerado reflita as seguintes características na sua produção:

Consulte Como testar o desempenho com o Cloud Bigtable para conhecer mais práticas recomendadas.

Causas para um desempenho mais lento

Existem vários fatores que podem fazer com que o Cloud Bigtable apresente um desempenho mais lento do que o estimado acima:

  • O esquema da tabela não foi criado corretamente. Para conseguir um bom desempenho do Cloud Bigtable, é essencial projetar um esquema que possibilite distribuir leituras e gravações igualmente entre todas as tabelas. Para saber mais, veja Como projetar seu esquema.
  • As linhas na tabela do Cloud Bigtable contêm grande quantidade de dados. As estimativas de desempenho mostradas acima pressupõem que tenha 1 KB de dados em cada linha. É possível ler e gravar grandes quantidades de dados por linha, mas aumentar essa quantidade também reduzirá o número de linhas por segundo.
  • As linhas na tabela do Cloud Bigtable contêm um grande número de células. Leva tempo para que o Cloud Bigtable processe cada célula de uma linha. Além disso, cada célula adiciona uma sobrecarga à quantidade de dados armazenados em sua tabela e enviados pela rede. Por exemplo, se você estiver armazenando 1 KB (1.024 bytes) de dados, será muito mais eficiente armazenar esses dados em uma única célula em vez de distribuí-los por 1.024 células, cada uma contendo 1 byte. Se você utilizar mais células que o necessário para armazenar seus dados, talvez não consiga atingir o melhor desempenho possível. Se as linhas tiverem um grande número de células por existirem várias versões de dados com carimbo de data/hora nas colunas, pense em manter apenas o valor mais recente. Outra opção para uma tabela que já existe é enviar uma exclusão de todas as versões anteriores a cada regravação.
  • O cluster do Cloud Bigtable não tem nós suficientes. Se o cluster do Cloud Bigtable estiver sobrecarregado, adicionar mais nós poderá melhorar o desempenho. Use as ferramentas de monitoramento para verificar se o cluster está sobrecarregado.
  • O cluster do Cloud Bigtable foi ampliado ou reduzido recentemente. Após aumentar o número de nós do cluster, pode levar até 20 minutos sob carga até haver uma melhoria significativa no desempenho do cluster. Ao diminuir o número de nós de um cluster para reduzir o escalonamento, tente não diminuir o tamanho do cluster em mais de 10% em um período de 10 minutos para minimizar os picos de latência.
  • O cluster do Cloud Bigtable usa discos HDD. Na maioria dos casos, o cluster precisa usar discos SSD, porque eles apresentam um desempenho significativamente melhor do que os discos HDD. Para saber mais, consulte Como escolher entre armazenamento SSD e HDD.
  • A conexão com a rede apresenta problemas. Problemas na rede podem reduzir a capacidade e fazer com que as leituras e gravações demorem mais que o normal. Podem surgir problemas se os clientes estiverem executando em uma zona diferente daquela do cluster do Cloud Bigtable ou se executarem fora do Google Cloud.

Como cargas de trabalho diferentes podem provocar variações no desempenho, faça alguns testes com suas próprias cargas de trabalho para conseguir parâmetros de comparação mais precisos.

Replicação e desempenho

Ativar a replicação afetará o desempenho de uma instância do Cloud Bigtable. O efeito é positivo para algumas métricas e negativo para outras. É preciso entender os possíveis impactos no desempenho antes de decidir ativar a replicação.

Capacidade de leitura

A replicação pode melhorar a capacidade de leitura, especialmente ao usar o roteamento de vários clusters. Além disso, a replicação pode reduzir a latência de leitura, colocando os dados do Cloud Bigtable mais próximos geograficamente aos usuários do aplicativo.

Capacidade de gravação

Embora a replicação possa melhorar a disponibilidade e o desempenho de leitura, ela não aumenta a capacidade da gravação. Uma gravação em um cluster precisa ser replicada para todos os outros clusters na instância. Como resultado, cada cluster gasta recursos da CPU para receber alterações dos outros clusters. Na verdade, a capacidade da gravação pode diminuir porque a replicação requer que cada cluster faça um trabalho adicional.

Imagine, por exemplo, que você tenha uma instância de cluster único de três nós:

Instância de cluster único de três nós

Se você adicionar nós ao cluster, o efeito na capacidade de gravação será diferente do que se ativar a replicação adicionando um segundo cluster de três nós à instância.

Adicionar nós ao cluster original: é possível adicionar três nós ao cluster para ter um total de seis nós. A capacidade de gravação da instância duplica, mas os dados dela ficam disponíveis em apenas uma zona:

Instância de cluster único de seis nós

Com replicação: outra opção é adicionar um segundo cluster com três nós, totalizando seis nós. A instância agora grava cada parte dos dados duas vezes: quando a gravação é recebida pela primeira vez e novamente quando é replicada para o outro cluster. A capacidade de gravação não aumenta e pode até diminuir, mas você contará com a vantagem de ter os dados disponíveis em duas zonas diferentes:

Instância de dois clusters de seis nós

Nesses exemplos, a instância de cluster único pode processar o dobro da capacidade de gravação que a instância replicada, mesmo que os clusters de cada uma tenham um total de seis nós.

Latência de replicação

Ao usar o roteamento de vários clusters, a replicação do Cloud Bigtable tem consistência posterior. Como regra geral, leva mais tempo para replicar dados em uma distância maior. Os clusters replicados em diferentes regiões geralmente terão uma latência de replicação maior do que os replicados na mesma região.

Perfis de app e roteamento de tráfego

Dependendo do caso de uso, um ou mais perfis de app serão usados para direcionar o tráfego do Cloud Bigtable. Cada perfil usa roteamento de vários clusters ou de cluster único. A escolha do roteamento pode afetar o desempenho.

O roteamento de vários clusters pode minimizar a latência. Um perfil de app com roteamento de vários clusters encaminha automaticamente as solicitações para o cluster mais próximo em uma instância a partir da perspectiva do aplicativo, e as gravações são replicadas para os outros clusters na instância. Essa escolha automática da menor distância resulta na menor latência possível.

Um perfil de app que usa roteamento de cluster único pode ser ideal para determinados casos de uso, como separar cargas de trabalho ou ter semântica de leitura após gravação em um único cluster, mas não reduzirá a latência como no roteamento de vários clusters.

Para entender como configurar os perfis de app para esses e outros casos de uso, consulte Exemplos de configurações de replicação.

Como o Cloud Bigtable otimiza os dados ao longo do tempo

Para armazenar os dados subjacentes de cada tabela, o Cloud Bigtable fragmenta os dados em vários blocos, que podem ser movidos entre os nós do cluster do Cloud Bigtable. Com esse método de armazenamento, o Cloud Bigtable pode usar duas estratégias diferentes para otimizar os dados ao longo do tempo:

  1. O Cloud Bigtable tenta armazenar aproximadamente a mesma quantidade de dados em cada nó do Cloud Bigtable.
  2. O Cloud Bigtable tenta distribuir igualmente as leituras e gravações em todos os nós do Cloud Bigtable.

Às vezes, essas estratégias entram em conflito. Por exemplo, se as linhas de um bloco são lidas com uma frequência muito grande, talvez o Cloud Bigtable armazene esse bloco em um nó próprio, mesmo que alguns nós armazenem mais dados do que outros.

Como parte desse processo, também há a possibilidade de o Cloud Bigtable dividir um bloco em dois ou mais nós menores, seja para reduzir o tamanho do bloco, seja para isolar as linhas com muito acesso dentro de um bloco existente.

As seções a seguir explicam cada uma das estratégias com mais detalhes.

Distribuição da quantidade de dados pelos nós

À medida que você realiza gravações de dados em uma tabela do Cloud Bigtable, ele fragmenta os dados dessa tabela em blocos. Cada bloco contém um intervalo contíguo de filas na tabela.

Quando você grava apenas uma quantidade pequena de dados na tabela, o Cloud Bigtable armazena todos os blocos em um único nó dentro do cluster:

Um cluster com quatro blocos em um único nó

À medida que os blocos vão se acumulando, o Cloud Bigtable move alguns para outros nós no cluster. Assim, a quantidade de dados é balanceada de forma uniforme no cluster:

Outros blocos são distribuídos por vários nós.

Distribuição uniforme de leituras e gravações nos nós

Se você criar o esquema corretamente, as leituras e gravações serão distribuídas de maneira uniforme em toda a tabela. No entanto, em alguns casos, não é possível evitar que algumas filas sejam acessadas com mais frequência que outras. O Cloud Bigtable ajuda você a lidar com esses casos ao considerar as leituras e gravações quando faz o balanceamento dos blocos pelos nós.

Por exemplo, vamos supor que 25% das leituras têm como destino um número pequeno de blocos dentro de um cluster e o restante está espalhado de forma uniforme nos outros blocos:

Dentre 48 blocos, somente 3 recebem 25% das leituras.

O Cloud Bigtable redistribuirá os blocos existentes para que as leituras sejam espalhadas da maneira mais uniforme possível por todo o cluster:

Os três blocos mais usados são isolados em um nó próprio.

Como testar o desempenho com o Cloud Bigtable

Se você estiver executando um teste de desempenho para um aplicativo que depende do Cloud Bigtable, siga estas diretrizes ao planejar e executar o teste:

  • Teste com dados suficientes.
    • Se as tabelas na instância de produção contiverem um total de 100 GB de dados ou menos por nó, teste com uma tabela da mesma quantidade de dados.
    • Se as tabelas contiverem mais de 100 GB de dados por nó, teste com uma tabela que contenha pelo menos 100 GB de dados por nó. Por exemplo, se a instância de produção tiver um cluster de quatro nós e as tabelas contiverem um total de 1 TB de dados, execute o teste usando uma tabela de pelo menos 400 GB.
  • Teste com uma única tabela.
  • Permaneça abaixo da utilização de armazenamento recomendada por nó. Veja mais detalhes em Uso do armazenamento por nó.
  • Antes de iniciar o teste, execute um teste preliminar intenso por vários minutos. Essa etapa dá ao Cloud Bigtable uma oportunidade de balancear os dados por todos os nós, com base nos padrões de acesso observados.
  • Execute o teste por pelo menos 10 minutos. Essa etapa permite que o Cloud Bigtable otimize ainda mais os dados e ajuda a garantir que serão testadas tanto as leituras do disco quanto as leituras contidas em caches da memória.

Solução de problemas de desempenho

Se você achar que o Cloud Bigtable pode criar um afunilamento de desempenho no aplicativo, realize estas verificações:

  • Observe os verificações do Key Visualizer para sua tabela. É possível visualizar os padrões de uso de cada tabela em um cluster, basta usar a ferramenta Key Visualizer do Cloud Bigtable para fazer verificações diárias. Com o Key Visualizer é possível verificar se os padrões de uso estão causando resultados indesejáveis, como pontos de acesso em linhas específicas ou uso excessivo da CPU. Dê os primeiros passos com o Key Visualizer.
  • Converta em comentário o código que realiza as leituras e gravações no Cloud Bigtable. Se o problema de desempenho desaparecer, isso significa que a forma como você usa o Cloud Bigtable resulta em um desempenho abaixo do ideal. Se o problema de desempenho persistir, é porque o problema provavelmente não tem relação com o Cloud Bigtable.
  • Verifique se você está criando o menor número de clientes possível. Criar um cliente para o Cloud Bigtable é uma operação relativamente cara. Portanto, crie o menor número possível de clientes:

    • Se você usa replicação ou perfis de aplicativo para identificar diferentes tipos de tráfego para sua instância, crie um cliente por perfil de app e compartilhe os clientes em todo o aplicativo.
    • Caso você não use replicação ou perfis de aplicativo, crie um único cliente e compartilhe-o em todo o aplicativo.

    Se estiver usando o cliente HBase para Java, crie um objeto Connection em vez de um cliente, dessa forma, você criará o menor número de conexões possível.

  • Verifique se as leituras e gravações são realizadas em várias linhas diferentes da tabela. O Cloud Bigtable tem um desempenho melhor quando as leituras e gravações são distribuídas de forma uniforme por toda a tabela. Isso ajuda o Cloud Bigtable a distribuir a carga de trabalho por todos os nós do cluster. Se não for possível espalhar as leituras e gravações por todos os nós do Cloud Bigtable, o desempenho será prejudicado.

    Se você perceber que está lendo e gravando um número pequeno de linhas, será preciso reprojetar o esquema para que haja mais uniformidade na distribuição das leituras e gravações.

  • Verifique se as leituras e gravações têm aproximadamente o mesmo desempenho. Caso perceba que as leituras são mais rápidas que as gravações, é possível que você esteja tentando ler chaves de linha inexistentes ou um grande intervalo de chaves de linha que contêm apenas um pequeno número de linhas.

    Para fazer uma comparação válida entre leituras e gravações, é necessário que pelo menos 90% das leituras retornem resultados válidos. Além disso, se você estiver realizando a leitura de um intervalo grande de chaves de linha, meça o desempenho com base no número real de linhas no intervalo, em vez de usar o número máximo de linhas que podem estar presentes.

  • Use o tipo certo de solicitação de gravação para seus dados. A escolha da melhor forma de gravar seus dados ajuda a manter um alto desempenho.

A seguir