Esta página foi traduzida pela API Cloud Translation.

Instâncias, clusters e nós

Para usar o Bigtable, cria instâncias, que contêm clusters aos quais as suas aplicações se podem ligar. Cada cluster contém nós, as unidades de computação que gerem os seus dados e realizam tarefas de manutenção.

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

Para saber como criar uma instância, consulte o artigo Crie uma instância.
Para saber como adicionar ou eliminar clusters, consulte o artigo Modifique uma instância.
Para saber como monitorizar uma instância e os respetivos clusters, consulte o artigo Monitorizar uma instância.
Para saber como atualizar o número de nós num cluster, consulte o artigo Adicione ou remova nós.

Antes de ler esta página, deve conhecer a vista geral do Bigtable.

Instâncias

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

Uma tabela pertence a uma instância e não a um cluster ou um nó. Se tiver uma instância com mais do que um cluster, está a usar a replicação. Isto significa que não pode atribuir uma tabela a um cluster individual nem criar políticas de recolha de lixo exclusivas para cada cluster numa instância. Também não pode fazer com que cada cluster armazene um conjunto diferente de dados na mesma tabela.

Uma instância tem algumas propriedades importantes que deve conhecer:

O tipo de armazenamento (SSD ou HDD)
Os perfis de aplicações, que se destinam principalmente a instâncias que usam a replicação

As secções seguintes descrevem estas propriedades.

Tipos de armazenamento

Quando cria uma instância, tem de escolher se os clusters da instância vão armazenar dados em unidades de estado sólido (SSD) ou unidades de discos rígidos (HDD). Muitas vezes, mas nem sempre, o SSD é a escolha mais eficiente e económica.

A escolha entre SSD e HDD é permanente e todos os clusters na sua instância têm de usar o mesmo tipo de armazenamento. Por isso, certifique-se de que escolhe o tipo de armazenamento certo para o seu exemplo de utilização. Consulte o artigo Escolher entre o armazenamento SSD e HDD para ver mais informações que lhe podem ajudar a decidir.

Se precisar de armazenar dados do histórico por motivos como requisitos regulamentares, use o armazenamento de acesso pouco frequente do Bigtable como parte do armazenamento hierárquico (pré-visualização). Esta opção está disponível para instâncias de SSD.

Perfis de aplicações

Depois de criar uma instância, o Bigtable usa a instância para armazenar perfis de aplicações, ou perfis de apps. Para instâncias que usam a replicação, os perfis de apps controlam a forma como as suas aplicações se ligam aos clusters da instância.

Se a sua instância não usar a replicação, pode continuar a usar perfis de apps para fornecer identificadores separados para cada uma das suas aplicações ou cada função numa aplicação. Em seguida, pode ver gráficos separados para cada perfil de app na Google Cloud consola.

Para saber mais sobre os perfis de apps, consulte os perfis de aplicações. Para saber como configurar os perfis de apps da sua instância, consulte o artigo Configurar perfis de apps.

Clusters

Um cluster representa o serviço Bigtable numa localização específica. Cada cluster pertence a uma única instância do Bigtable e uma instância pode ter clusters em até 8 regiões. Quando a sua aplicação envia pedidos para uma instância do Bigtable, esses pedidos são processados por um dos clusters na instância.

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

O número de clusters que pode criar numa instância depende do número de zonas disponíveis nas regiões que escolher. Por exemplo, se criar clusters em 8 regiões com 3 zonas cada, o número máximo de clusters que a instância pode ter é 24. Para ver uma lista de zonas e regiões onde o Bigtable está disponível, consulte as localizações do Bigtable.

As instâncias do Bigtable que têm apenas 1 cluster não usam a replicação. Se adicionar um segundo cluster a uma instância, o Bigtable inicia automaticamente a replicação dos seus dados, mantendo cópias separadas dos dados nas zonas de cada cluster e sincronizando as atualizações entre as cópias. Pode escolher a que cluster as suas aplicações se ligam, o que permite isolar diferentes tipos de tráfego uns dos outros. Também pode permitir que o Bigtable equilibre o tráfego entre clusters. Se um cluster ficar indisponível, pode fazer a comutação por falha de um cluster para outro. Para saber como funciona a replicação, consulte a vista geral da replicação.

Na maioria dos casos, deve ativar o dimensionamento 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.

Quando cria um cluster, pode ativar o dimensionamento de nós 2x, uma configuração que define o cluster para ser sempre dimensionado em incrementos de dois nós. Para mais informações, consulte o artigo Fator de escala do nó.

Nós

Cada cluster numa instância tem 1 ou mais nós, que são recursos de computação que o Bigtable usa para gerir os seus dados.

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

Cada nó é responsável por:

Manter o controlo de tablets específicos no disco.
Processar leituras e escritas recebidas para os respetivos tablets.
Executar tarefas de manutenção nos respetivos tablets, como compactações periódicas.

Um cluster tem de ter nós suficientes para suportar a respetiva carga de trabalho atual e a quantidade de dados que armazena. Caso contrário, o cluster pode não conseguir processar os pedidos recebidos e a latência pode aumentar. Monitorize a utilização de CPU e disco dos seus clusters e adicione nós a uma instância quando as respetivas métricas excederem as recomendações em Planeie a sua capacidade.

Para mais detalhes sobre como o Bigtable armazena e gere dados, consulte o artigo Arquitetura do Bigtable.

Para tarefas de leitura de elevado débito, pode usar o Data Boost para o Bigtable para computação em vez dos nós do cluster. O Data Boost permite-lhe enviar grandes tarefas de leitura e consultas usando a computação sem servidor, enquanto a sua aplicação principal continua a usar nós de cluster para computação. Para mais informações, consulte a vista geral do aumento de dados.

Para cargas de trabalho de dados do histórico aos quais não precisa de aceder com frequência, pode usar o nível de acesso pouco frequente em instâncias de SSD.

Nós para clusters replicados

Quando a sua instância tem mais do que um cluster, a comutação por falha torna-se uma consideração quando configura o número máximo de nós para o dimensionamento automático ou atribui os nós manualmente.

Se usar o encaminhamento de vários clusters em qualquer um dos seus perfis de apps, a comutação por falha automática pode ocorrer caso um ou mais clusters estejam indisponíveis.
Quando faz a comutação por falha manual de um cluster para outro ou quando ocorre a comutação por falha automática, o cluster de receção deve ter, idealmente, capacidade suficiente para suportar a carga. Pode sempre atribuir nós suficientes para suportar a comutação por falha, o que pode ser dispendioso, ou pode confiar no dimensionamento automático para adicionar nós quando o tráfego comuta por falha. No entanto, tenha em atenção que pode haver um breve impacto no desempenho enquanto o cluster é dimensionado.
Se todos os seus perfis de apps usarem o encaminhamento de cluster único, cada cluster pode ter um número diferente de nós. Redimensione cada cluster conforme necessário com base na carga de trabalho do cluster.

Uma vez que o Bigtable armazena uma cópia separada dos seus dados com cada cluster, cada cluster tem de ter sempre nós suficientes para suportar a sua utilização de disco e replicar as gravações entre clusters.

Ainda pode fazer a comutação por falha manualmente de um cluster para outro, se necessário. No entanto, se um cluster tiver muito mais nós do que outro e precisar de fazer failover para o cluster com menos nós, pode ter de adicionar nós primeiro. Não existe qualquer garantia de que os nós adicionais estejam disponíveis quando precisar de fazer failover. A única forma de reservar nós antecipadamente é adicioná-los ao seu cluster.