Instâncias, clusters e nós

Para usar o Bigtable, crie instâncias com 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 nó.

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

Na maioria dos casos, é necessário ativar o escalonamento automático para um cluster, para que o Bigtable adicione e remova nós conforme necessário para processar as cargas de trabalho do cluster.

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 as métricas excederem as recomendações em Planejar sua capacidade.

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

Nós para clusters replicados

Quando a instância tem mais de um cluster, o failover se torna uma consideração ao configurar o número máximo de nós para o escalonamento automático ou alocar os nós manualmente.

  • Se você usar o roteamento de vários clusters em qualquer um dos seus perfis de app, o failover automático poderá ocorrer caso um ou mais clusters estejam indisponíveis.

  • Quando você faz failover manualmente de um cluster para outro ou quando ocorre um failover automático, o cluster receptor precisa ter capacidade suficiente para suportar a carga. Você pode sempre alocar nós suficientes para oferecer suporte ao failover, o que pode ser caro, ou pode usar o escalonamento automático para adicionar nós quando o tráfego falhar, mas há um breve impacto no desempenho enquanto o cluster é escalonado.

  • 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