Instâncias, clusters e nós

Para usar o Cloud Bigtable, crie instâncias com até quatro clusters a que seus aplicativos podem se conectar. Cada cluster contém nós, as unidades de cálculo que gerenciam os dados e realizam as tarefas de manutenção.

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

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

Instâncias

Uma instância do Cloud Bigtable é basicamente um contêiner para os clusters e nós, que fazem todo o trabalho pesado.

Tabelas pertencem a instâncias, não a clusters ou nós. Se você tiver uma instância com mais de um cluster, não será possível atribuir tabelas a clusters individuais ou criar políticas exclusivas de coleta de lixo para cada cluster. 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 instância (produção ou desenvolvimento)
  • o tipo de armazenamento (SSD ou HDD)
  • os perfis de aplicativo, para instâncias que usam replicação

As seções a seguir descrevem essas propriedades.

Tipos de instância

Ao criar uma instância, você precisa escolher que tipo de instância criar:

  • Produção: uma instância padrão com um ou dois clusters, bem como três ou mais nodes em cada cluster. Não é possível fazer downgrade de uma instância de produção para uma instância de desenvolvimento.
  • Desenvolvimento: uma instância de baixo custo em desempenho e teste, com desempenho limitado ao equivalente de um cluster de um node. Não há garantia de monitoramento ou capacidade. A replicação não fica disponível, e o SLA não se aplica. Atualize uma instância de desenvolvimento para uma instância de produção a qualquer momento.

Tipos de armazenamento

Ao criar uma instância, você também precisa escolher se os clusters da instância armazenarão dados em unidades de estado sólido (SSD, na sigla em inglês) ou em unidades de disco rígido (HDD, na sigla em inglês). SSD costuma ser, mas não sempre, 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 para mais informações a fim de ajudar você a decidir.

Perfis de aplicativo

Depois de criar uma instância de produção, ela será usada no Cloud Bigtable para armazenar os perfis de aplicativos. Para instâncias que usam replicação, os perfis de app controlam como os aplicativos se conectam aos clusters da instância. Caso a instância não use replicação, ainda será possível usar perfis de app para fornecer identificadores separados para cada um dos aplicativos ou cada função dentro do aplicativo. Você poderá visualizar gráficos separados para cada perfil de app no console do GCP.

Para saber mais sobre perfis de app, veja Perfis de aplicativo. Para saber como configurar os perfis de aplicativos da sua instância, veja Como Configurar Perfis de Aplicativos.

Clusters

Um cluster representa o serviço real do Cloud Bigtable. Cada cluster pertence a uma única instância do Cloud Bigtable, e uma instância pode ter até quatro clusters. Quando o aplicativo envia solicitações para uma instância do Cloud Bigtable, elas são efetivamente processadas por um dos clusters na instância.

Cada cluster está localizado em uma única zona. Os clusters de uma instância precisam estar em zonas exclusivas. É possível criar um cluster adicional em qualquer zona em que o Cloud Bigtable esteja disponível. Por exemplo, se o primeiro cluster estiver em us-east1-b, será possível escolher uma zona diferente na mesma região, como us-east1-c, ou uma zona em uma região separada, como europe-west2-a. Para uma lista de zonas e regiões em que o Cloud Bigtable esteja disponível, consulte Locais do Cloud Bigtable.

As instâncias do Cloud Bigtable com apenas um cluster não usam replicação. Caso você adicione um segundo cluster a uma instância de produção, o Cloud Bigtable começará a replicar automaticamente os dados mantendo cópias separadas dos dados em cada uma das zonas do cluster e sincronizando atualizações entre as cópias. Escolha a que cluster os aplicativos se conectam, o que possibilita isolar tipos diferentes de tráfego uns dos outros, ou é possível permitir que o Cloud 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 Visão geral da replicação.

Nodes

Cada cluster em uma instância de produção tem três ou mais nós, que são recursos computacionais usados pelo Cloud Bigtable para gerenciar os dados.

Nos bastidores, o Cloud Bigtable divide todos os dados das suas tabelas em blocos menores. Os blocos são armazenados em disco, separados dos nós, mas na mesma zona que eles. Cada nó é responsável por acompanhar blocos específicos em disco, processar leituras de entrada e gravações nos próprios blocos, além de realizar tarefas de manutenção nos blocos, como compactações periódicas. Cada bloco está associado a um único nó. Para mais detalhes sobre como o Cloud Bigtable armazena e gerencia dados, consulte Arquitetura do Cloud Bigtable.

Um cluster precisa ter nós suficientes para aceitar a carga de trabalho atual e o valor de dados que ele armazena. Do contrário, o cluster talvez não consiga processar solicitações de entrada, e a latência poderá aumentar. Se você exceder as recomendações e os limites listados abaixo, precisará monitorar o uso do disco e da CPU do cluster e adicionar nós.

Uso da CPU

O Cloud 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.

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.

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.

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

Configuração Valores máximos recomendados
Cluster único

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

Qualquer número de clusters com roteamento de cluster único

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

Dois clusters com roteamento de vários clusters

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

Três ou mais clusters com roteamento de vários 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
Utilização do armazenamento (bytes)

O valor de dados armazenados no cluster.

Ele afeta os custos. Além disso, conforme descrito abaixo, convém adicionar nodes a cada cluster à medida que o valor de dados aumenta.

Utilização do armazenamento (% máx.)

A porcentagem da capacidade de armazenamento do cluster usado. A capacidade se baseia no número de nodes no cluster.

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. No entanto, os dados excluídos ocuparão mais espaço, não menos, até que ocorra uma compactação.

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

Carga do disco

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

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

Nodes 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 íntegro 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 Cloud Bigtable armazena uma cópia separada dos dados com cada cluster, cada um precisa ter sempre nodes suficientes para aceitar 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 nodes do que outro e você precise fazer failover para o cluster com menos nodes, talvez seja necessário adicionar nodes primeiro. Não há garantia de que nodes adicionais estarão disponíveis quando você precisar fazer failover. A única maneira de reservar nodes com antecedência é os adicionando ao cluster.

Próximas etapas

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

Enviar comentários sobre…

Documentação do Cloud Bigtable