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 Pico de leituras   Pico de gravações   Pico de verificações
SSD 10.000 linhas por segundo ou 10.000 linhas por segundo ou 220 MB/s
HDD 500 linhas por segundo ou 10.000 linhas por segundo ou 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. 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.

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.
  • A carga de trabalho não é adequada para o Cloud Bigtable. Se você testar o Cloud Bigtable com uma quantidade pequena de dados (menos de 300 GB) ou por um período muito curto (segundos em vez de minutos ou horas), ele não conseguirá balancear os dados de forma a render um bom desempenho. O Cloud Bigtable precisa de tempo para aprender os padrões de acesso. Ele também precisa de fragmentos de dados grandes o suficiente para utilizar todos os nós no cluster.
  • 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.
  • 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. Depois que o número de nós em um cluster for alterado, pode ser que demore até 20 minutos sob carga para que você perceba melhoria significativa no desempenho do cluster.
  • 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 instância do Cloud Bigtable é uma instância de desenvolvimento. O desempenho de uma instância de desenvolvimento equivale a uma instância com um cluster de nó único. Dessa maneira, ela não terá um desempenho tão bom quanto uma instância de produção. Talvez você veja uma grande quantidade de erros, principalmente se a instância estiver sob carga pesada.
  • 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ê quiser executar um teste de desempenho que dependa do Cloud Bigtable, siga as etapas abaixo durante o planejamento e realização do teste:

  1. Use uma instância de produção. Uma instância de desenvolvimento não dará a ideia exata do desempenho de uma instância de produção sob carga.
  2. Use no mínimo 300 GB de dados. O Cloud Bigtable apresenta um melhor desempenho com um volume de dados de 1 TB ou mais. No entanto, 300 GB de dados são suficientes para fornecer resultados aceitáveis em um teste de desempenho de um cluster com três nós. Em clusters maiores, use pelo menos 100 GB de dados por nó. Para simplificar, teste com uma única tabela.
  3. Permaneça abaixo da utilização de armazenamento recomendada por nó. Veja mais detalhes em Uso do armazenamento por nó.
  4. 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.
  5. 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.

Use a ferramenta loadtest do Cloud Bigtable, escrita em Go, como ponto de partida para desenvolver seu próprio teste de desempenho. A ferramenta loadtest realiza uma carga de trabalho simples em que há 50% de leituras e 50% de gravações.

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 é mais fácil 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