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

Imagine que você queira visitar um amigo. Você vai de avião? Depende do destino. Se o seu amigo morar perto, haverá maneiras melhores de ir a casa dele. Mas, se ele morar muito longe, viajar de avião, provavelmente, será a maneira mais rápida de chegar lá.

Usar o Cloud Bigtable é parecido com viajar de avião. O Cloud Bigtable é excelente para processar grandes quantidades de dados (terabytes ou petabytes) durante um período de tempo relativamente longo (horas ou dias). No entanto, ele não foi criado para trabalhar com quantidades pequenas de dados em bursts breves. Se você testar o Cloud Bigtable por 30 segundos com poucos GB de dados, você não terá uma imagem precisa do desempenho dele.

Continue lendo para saber mais sobre o desempenho que você pode esperar do Cloud Bigtable.

Desempenho em cargas de trabalho típicas

No processamento de cargas de trabalho típicas, o Cloud Bigtable tem um desempenho altamente previsível. Quando tudo está funcionando perfeitamente, uma carga de trabalho típica pode alcançar o seguinte desempenho para cada node no cluster do Cloud Bigtable, dependendo do tipo de armazenamento usado pelo cluster:

Tipo de armazenamento Leituras   Gravações Verificações
SSD 10.000 linhas por segundo a 6 ms ou 10.000 linhas por segundo a 6 ms 220 MB/s
HDD 500 linhas por segundo a 200 ms ou 10.000 linhas por segundo a 50 ms 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 de leitura ou de gravação, com latência de 6 ms em cada operação de leitura ou gravação.

Essas estimativas de desempenho são diretrizes, e não regras rígidas. A variação do desempenho por node será baseada na carga de trabalho e no tamanho típico de cada linha da tabela.

Além disso, essas estimativas de desempenho refletem uma carga de trabalho somente leitura ou somente gravação. O desempenho de uma carga de trabalho mista de leituras e gravações varia. Dependendo da carga de trabalho, a capacidade geral pode ser menor que o número típico de linhas por segundo para cargas de trabalho somente de leitura ou de 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 por igual entre todas as tabelas. Veja Projeto do seu esquema para mais informações.
  • 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 de tempo 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 nodes no cluster.
  • As linhas na tabela do Cloud Bigtable contêm uma 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 do 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 nodes suficientes. Se o cluster do Cloud Bigtable estiver sobrecarregado, adicionar mais nodes 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 nodes em um cluster, for alterado, pode ser que demore até 20 minutos sob carga para que você perceba uma 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 detalhes, veja 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 único node. Dessa maneira, ela não terá um desempenho tão bom quanto uma instância de produção. Talvez você observa 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 do que o normal. Talvez você tenha problemas, principalmente se seus clientes não estiverem sendo executados na mesma zona do cluster do Cloud Bigtable ou se os seus clientes estiverem sendo executados fora do Google Cloud Platform.

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 habilitar a replicação.

Leituras e digitalizações

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 deve 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 com três nós:

Instância de cluster único com 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 com 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ê se beneficia de ter os dados disponíveis em duas zonas diferentes:

Instância de dois clusters com seis nós

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

Latência de replicação

Ao usar o roteamento de vários clusters, a replicação do Cloud Bigtable tem consistência eventual. 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 nodes 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 node do Cloud Bigtable.
  2. O Cloud Bigtable tenta distribuir igualmente as leituras e gravações em todos os nodes 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 node próprio, mesmo que alguns nodes 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 nodes 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 nodes

À 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 node 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 deles para outros nodes no cluster. Assim, a quantidade de dados é balanceada de forma uniforme pelo cluster:

Blocos adicionais são distribuídos por vários nodes.

Distribuição uniforme de leituras e gravações pelos nodes

Se você criou o esquema corretamente, as leituras e gravações serão distribuídas de forma uniforme por 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 nodes.

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 pelos outros blocos:

Dentre 48 blocos, somente três recebem 25% das leituras.

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

Os três blocos mais usados são isolados em um node 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ó. Para detalhes, consulte Utilização de armazenamento por node.
  4. Antes de iniciar o teste, execute um teste preliminar intenso por vários minutos. Esta etapa dá ao Cloud Bigtable uma oportunidade de balancear os dados por todos os nodes, 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, além disso ajuda a garantir que serão testadas tanto as leituras do disco quanto as leituras contidas em caches da memória.

É possível usar a ferramenta de teste loadtest do Cloud Bigtable, escrita em Go, como ponto de partida para desenvolver seu próprio teste de desempenho. A ferramenta loadtest executa uma carga de trabalho simples composta por 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. Com a ferramenta Key Visualizer do Cloud Bigtable são fornecidas verificações diárias que mostram os padrões de uso de cada tabela em um cluster. 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. Veja os primeiros passos do 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, você crie o menor número possível de clientes:

    • Caso você use replicação ou perfis de aplicativo para identificar diferentes tipos de tráfego para sua instância, crie um cliente por perfil de aplicativo e compartilhe-os 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 você estiver usando o cliente HBase para Java, crie um objeto Connection em vez de um cliente. Portanto, crie 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 nodes do cluster. Se não for possível espalhar as leituras e gravações por todos os nodes do Cloud Bigtable, o desempenho será prejudicado.

    Se você perceber que está sendo lido e gravado apenas um número pequeno de linhas, será necessário reprojetar o esquema. Dessa maneira, as leituras e as gravações serão distribuídas igualitariamente.

  • Verifique se as leituras e gravações têm aproximadamente o mesmo desempenho. Caso perceba que leituras sejam mais rápidas do que gravações, você tenta 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 existir.

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

A seguir

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

Enviar comentários sobre…

Documentação do Cloud Bigtable