Instâncias, clusters e nós

Para usar o Bigtable, crie instâncias que contêm clusters aos quais seus aplicativos podem se conectar. Cada cluster contém nós, as unidades de computação que gerenciam os dados e realizam as tarefas de manutenção.

Nesta página, você encontra mais informações sobre instâncias, clusters e nós do Bigtable.

Antes de ler esta página, familiarize-se com a visão geral do Bigtable.

Instâncias

Uma instância do Bigtable é um contêiner para seus dados. As instâncias têm um ou mais clusters, localizados em zonas diferentes. Cada cluster tem pelo menos um .

Uma tabela pertence a uma instância, não a um cluster ou nó. Se você tiver uma instância com mais de um cluster, está usando a replicação. Isso significa que não é possível atribuir uma tabela a um cluster individual ou criar políticas de coleta de lixo exclusivas para cada cluster em uma instância. Também não é possível fazer com que cada cluster armazene um conjunto diferente de dados na mesma tabela.

Uma instância tem algumas propriedades importantes que você precisa conhecer:

  • O tipo de armazenamento (SSD ou HDD)
  • Os perfis de aplicativo, que são principalmente para instâncias que usam replicação

As seções a seguir descrevem essas propriedades.

Tipos de armazenamento

Ao criar uma instância, você precisa escolher se os clusters da instância armazenarão dados em unidades de estado sólido (SSD) ou unidades de disco rígido (HDD). SSD costuma ser a opção mais eficiente e econômica.

A escolha entre SSD e HDD é permanente, e todo cluster na instância precisa usar o mesmo tipo de armazenamento. Dessa maneira, não se esqueça de escolher o tipo de armazenamento certo para o caso de uso. Consulte Como escolher entre armazenamento SSD e HDD antes de decidir.

Perfis de aplicativos

Depois de criar uma instância, o Bigtable usa a instância para armazenar perfis de aplicativo, ou perfis de app. Para instâncias que usam replicação, os perfis de aplicativo controlam como os aplicativos se conectam aos clusters da instância.

Caso sua instância não use replicação, ainda será possível usar perfis de app para fornecer identificadores separados a cada um dos aplicativos ou a cada função em um aplicativo. Em seguida, é possível visualizar gráficos separados para cada perfil de app no console do Google Cloud.

Clique aqui para saber mais sobre perfis de aplicativos. Para saber como configurar os perfis de aplicativos da sua instância, acesse este artigo.

Clusters

Um cluster representa o serviço do Bigtable em um local específico. Cada cluster pertence a uma única instância do Bigtable, e uma instância pode ter clusters em até oito regiões. Quando o aplicativo envia solicitações para uma instância do Bigtable, essas solicitações são processadas por um dos clusters na instância.

Cada cluster está localizado em uma única zona. Uma instância pode ter clusters em até oito regiões em que o Bigtable está disponível. Cada zona em uma região pode conter apenas um cluster. Por exemplo, se uma instância tiver um cluster em us-east1-b, será possível adicionar um cluster em uma zona diferente na mesma região, como us-east1-c, ou em uma zona em uma região separada como europe-west2-a.

O número de clusters que podem ser criados em uma instância depende do número de zonas disponíveis nas regiões escolhidas. Por exemplo, se você criar clusters em oito regiões com três zonas cada, o número máximo de clusters que a instância pode ter é 24. Para uma lista de zonas e regiões em que o Bigtable está disponível, consulte Locais do Bigtable.

As instâncias do Bigtable que têm apenas um cluster não usam replicação. Se você adicionar um segundo cluster a uma instância, o Bigtable começará a replicar automaticamente os dados mantendo cópias separadas dos dados em cada zona dos clusters e sincronizando as atualizações entre as cópias. É possível escolher a qual cluster seus aplicativos se conectam, o que permite isolar diferentes tipos de tráfego. Também é possível permitir que o Bigtable equilibre o tráfego entre clusters. Caso um cluster fique indisponível, será possível usar o failover de um cluster para outro. Para saber mais sobre como funciona a replicação, consulte a visão geral.

Nós

Cada cluster em uma instância tem um ou mais nós, que são recursos de computação que o Bigtable usa para gerenciar seus dados.

Nos bastidores, o Bigtable divide todos os dados em uma tabela em blocos separados. Os blocos são armazenados em disco, separados dos nós, mas na mesma zona que eles. Um bloco está associado a um único nó.

Cada nó é responsável por:

  • Acompanhar blocos específicos no disco.
  • Lidar com leituras e gravações recebidas para seus blocos.
  • Executar tarefas de manutenção nos blocos, como compactação periódica.

Um cluster precisa ter nodes suficientes para aceitar a carga de trabalho atual e o valor de dados que armazena. Do contrário, o cluster talvez não consiga processar solicitações de entrada, e a latência poderá aumentar. Monitore o uso da CPU e do disco dos clusters e adicione nós a uma instância quando suas métricas excederem as recomendações e os limites listados abaixo.

Para saber mais detalhes sobre como o Bigtable armazena e gerencia dados, consulte Arquitetura do Bigtable.

Uso da CPU

O Bigtable informa as seguintes métricas de uso da CPU:

Métrica Descrição
Uso médio da CPU

O uso médio da CPU em todos os nós do cluster. Inclui atividade de fluxo de alterações quando um fluxo de alterações está ativado em uma tabela na instância.

Os valores máximos recomendados oferecem espaço para breves picos de uso.

Se um cluster exceder o valor máximo recomendado para sua configuração por mais de alguns minutos, adicione nós ao cluster.

Uso do melhor nó pela CPU

Uso da CPU no nó mais ocupado do cluster. Essa métrica continua a ser fornecida para manter a continuidade. No entanto, na maioria dos casos, é preciso usar a métrica mais precisa, Utilização de CPU de alta granularidade do nó mais quente.

Utilização de CPU de alta granularidade do nó mais quente

Uma medição detalhada da utilização da CPU para o nó mais ocupado no cluster. Recomendamos usar essa métrica em vez de uso da CPU do nó mais quente, porque essa métrica é mais precisa.

O nó mais quente não é necessariamente o mesmo nó ao longo do tempo e pode ser modificado rapidamente, especialmente durante grandes jobs em lote ou verificações de tabela.

Caso o melhor nó esteja frequentemente acima do valor recomendado, mesmo quando o uso médio da CPU for razoável, talvez você esteja acessando uma pequena parte dos dados com muito mais frequência do que o restante dos dados.

  • Use a ferramenta Key Visualizer para identificar pontos de acesso em sua tabela que podem estar causando picos no uso da CPU.
  • Verifique o design do esquema para se certificar de que ele aceita até mesmo a distribuição de leituras e gravações em cada tabela.
Utilização da CPU par o fluxo de alterações

A utilização média da CPU causada pela atividade de fluxo de alterações em todos os nós do cluster.

Uso da CPU por perfil, método e tabela do app

Utilização da CPU por perfil, método e tabela do app.

Se você observar um uso de CPU maior que o esperado para um cluster, use essa métrica para determinar se o uso de CPU de um determinado perfil de app, método de API ou tabela está impulsionando a carga da CPU.

Os valores dessas métricas não devem exceder o seguinte:

Configuração Valores máximos recomendados1
  1. Os máximos recomendados são para um cluster inteiro; não há valores máximos recomendados para a utilização da CPU por perfil, método ou tabela do app. Use essa métrica mais granular para observar as possíveis causas do alto uso de CPU de um cluster.
  2. Os valores máximos recomendados garantem que uma instância tenha capacidade suficiente para continuar funcionando em baixa latência em caso de failover. Por exemplo, em uma instância com dois clusters, cada um precisa ser capaz de processar todo o tráfego em 70%, caso o outro cluster fique indisponível.
Roteamento de cluster único, qualquer número de clusters

70% de uso médio da CPU
90% de uso do melhor nó pela CPU

Roteamento de vários clusters, escalonamento automático ativado, dois ou mais clusters

70% de uso médio da CPU
90% de uso do melhor nó pela CPU

Roteamento de vários clusters, escalonamento automático não ativado, dois clusters

35% de uso médio da CPU2
45% de uso do melhor nó pela CPU2

Roteamento de vários clusters, escalonamento automático ativado, três ou mais clusters

Depende da sua configuração. Veja os exemplos de configurações de replicação para casos de uso comuns.

Uso do disco

O Cloud Bigtable informa as seguintes métricas de uso do disco:

Métrica Descrição
Uso do armazenamento (bytes)

O valor de dados armazenados no cluster. O uso do fluxo de alterações não está incluso nessa métrica.

Ele afeta os custos. Além disso, conforme descrito abaixo, convém adicionar nós a cada cluster à medida que a quantidade de dados aumenta.

Uso do armazenamento (% máx.)

A porcentagem da capacidade de armazenamento do cluster usado. A capacidade se baseia no número de nodes no cluster. O uso do fluxo de alterações não está incluso nessa métrica.

Em geral, não use mais de 70% do limite máximo de armazenamento total, para que você tenha espaço para adicionar mais dados. Se você não planeja adicionar quantidades significativas de dados à sua instância, pode usar até 100% do limite máximo.

Se você estiver usando mais do que a porcentagem recomendada do limite de armazenamento, adicione nós ao cluster. Também é possível excluir dados atuais, mas dados excluídos ocupam mais espaço, e não menos, até que ocorra uma compactação.

Para detalhes sobre como esse valor é calculado, consulte Utilização do Storage por nó.

Uso do armazenamento do fluxo de alteração (bytes)

A quantidade de armazenamento consumida pelos registros de fluxo de alteração para tabelas na instância. Esse armazenamento não é contabilizado na utilização total do armazenamento. Há cobrança pelo armazenamento do fluxo de alterações, mas ele não está incluso no cálculo da utilização do armazenamento (% máxima).

Carga do disco

A porcentagem que o cluster está usando da largura de banda máxima possível para leituras HDD. Disponível apenas para clusters de HDD.

Caso esse valor esteja sempre em 100%, talvez haja mais latência. Adicione nós ao cluster para reduzir a porcentagem da carga de disco.

Nós para clusters replicados

Em uma instância que use replicação, verifique se cada cluster tem nodes suficientes para aceitar o caso de uso:

  • Caso você use a replicação para fornecer alta disponibilidade ou use o roteamento de vários clusters em alguns perfis de aplicativos, cada cluster precisará ter o mesmo número de nós. Além disso, conforme mostrado acima, em Uso da CPU, a utilização recomendada da CPU é reduzida pela metade.

    Essa configuração ajuda a garantir que, se um failover automático for necessário, o cluster responsivo terá capacidade suficiente para processar todo o tráfego.

  • Caso todos os perfis de app usem roteamento de cluster único, cada cluster poderá ter um número de nodes diferente. Redimensione cada cluster conforme necessário com base na carga de trabalho do cluster.

    Como o Bigtable armazena uma cópia separada dos dados com cada cluster, cada um precisa ter sempre nós suficientes para suportar o uso do disco e replicar gravações entre clusters.

    Ainda não é possível fazer failover manualmente de um cluster para outro, se necessário. Porém, caso um cluster tenha muito mais nós do que outro e você precise fazer failover para o cluster com menos nós, talvez seja necessário adicionar nós primeiro. Não há garantia de que nós adicionais estarão disponíveis quando você precisar fazer failover. A única maneira de reservar nós com antecedência é os adicionando ao cluster.

A seguir