Visão geral da replicação

Com a replicação do Cloud Bigtable, é possível aumentar a disponibilidade e a durabilidade dos dados com a respectiva cópia em várias regiões ou zonas. Também é possível isolar cargas de trabalho encaminhando tipos diferentes de solicitações para clusters distintos.

Nesta página, veja como a replicação funciona no Cloud Bigtable e alguns casos de uso para replicação. Você também conhecerá o modelo de consistência usado pelo Cloud Bigtable quando a replicação está ativada e saberá o que acontece quando ocorre um failover de um cluster para outro.

Antes de ler esta página, conheça a visão geral do Cloud Bigtable.

Como a replicação funciona

Para usar a replicação em uma instância do Cloud Bigtable, crie uma nova instância com, no máximo, um cluster ou adicione clusters a uma atual.

O Cloud Bigtable aceita até quatro clusters replicados localizados nas zonas do Google Cloud Platform em que o Cloud Bigtable esteja disponível. Os clusters de uma instância precisam estar em zonas exclusivas. É possível criar outro cluster em qualquer zona em que o Cloud Bigtable esteja disponível. Colocar clusters em zonas ou regiões diferentes permite que você acesse os dados, mesmo que uma zona ou região do GCP se torne indisponível.

Quando uma instância com mais de um cluster é criada, o Cloud Bigtable começa imediatamente a sincronizar os dados entre os clusters. Isso cria uma cópia separada e independente de seus dados em cada zona em que sua instância tem um cluster. Da mesma maneira, quando um cluster novo é adicionado a uma instância atual, o Cloud Bigtable copia os dados da zona do cluster original para a nova zona e sincroniza as alterações nos dados entre as zonas.

O Cloud Bigtable replica todas as alterações feitas nos dados automaticamente, inclusive todas dos seguintes tipos:

  • atualizações feitas nos dados em tabelas existentes
  • tabelas novas e excluídas
  • famílias de colunas adicionadas e removidas
  • alterações feitas na política de coleta de lixo da família de colunas

O Cloud Bigtable trata cada cluster na instância como um cluster principal. Dessa maneira, é possível realizar leituras e gravações em cada cluster. Também é possível configurar a instância. Dessa maneira, as solicitações de tipos diferentes de aplicativos são encaminhadas para clusters distintos.

Casos de uso

Nesta seção, há alguns casos de uso comuns para a replicação do Cloud Bigtable. Para encontrar as melhores configurações de cada caso de uso, bem como as dicas de implementação para outros casos de uso, consulte Exemplos de configurações de replicação.

Isolar aplicativos de serviço de leituras em lote

Quando você usa um único cluster para executar um job de análise em lote que desempenha várias leituras grandes ao lado de um aplicativo que realiza uma mescla de leituras e gravações, o job em lote grande pode atrasar as tarefas para os usuários do aplicativo. Com a replicação, é possível usar perfis de aplicativos com encaminhamento de cluster único para enviar jobs de análise em lote e tráfego de aplicativos até clusters diferentes. Assim, os jobs em lote não afetarão os usuários de seus aplicativos. Saiba mais sobre como implementar esse caso de uso.

Melhorar a disponibilidade

Se uma instância tiver apenas um cluster, a durabilidade e a disponibilidade dos seus dados estarão limitadas à zona em que o cluster estiver. A replicação pode melhorar a durabilidade e a disponibilidade armazenando cópias separadas de seus dados em várias zonas ou regiões e fazendo failover automático entre clusters se necessário. Saiba mais sobre como implementar esse caso de uso.

Criar backup quase em tempo real

Em alguns casos (por exemplo, se não puder ler dados desatualizados), você sempre precisará encaminhar solicitações para um único cluster. No entanto, você ainda pode usar a replicação processando as solicitações com um cluster e mantendo outro cluster como backup quase em tempo real. Se o cluster de serviço ficar indisponível, você poderá minimizar o tempo de inatividade realizando um failover manual no cluster de backup. Saiba mais sobre como implementar esse caso de uso.

Garantir que os dados tenham uma presença global

É possível configurar a replicação em locais em todo o mundo para que seus dados fiquem mais próximos dos seus clientes. Por exemplo, é possível criar uma instância com clusters replicados nos EUA, Europa e Ásia e configurar perfis de aplicativos para encaminhar o tráfego de aplicativos para o cluster mais próximo. Saiba mais sobre como implementar esse caso de uso.

Modelo de consistência

Por padrão, a replicação do Cloud Bigtable tem consistência eventual. Este termo significa que ao gravar uma alteração em um cluster, em algum momento, você conseguirá ler essa alteração de outro cluster na instância, mas só depois que a alteração for replicada entre os clusters.

Caso a instância seja íntegra, o atraso da replicação normalmente levará alguns segundos ou minutos, mas não horas. Porém, caso você esteja gravando um grande volume de dados em um cluster ou caso um cluster esteja sobrecarregado ou indisponível temporariamente, talvez leve algum tempo para que a replicação seja atualizada de acordo. Além disso, a replicação poderá levar mais tempo se os clusters estiverem distantes. Por isso, não pressuponha que você esteja sempre lendo o valor mais recente gravado ou que aguardar alguns segundos após a gravação dê ao Cloud Bigtable tempo suficiente para replicar a alteração.

Se você precisar de uma garantia de consistência diferente, o Cloud Bigtable também poderá oferecer consistência na leitura das gravações quando a replicação estiver ativada, o que garante que um aplicativo jamais lerá dados anteriores às gravações mais recentes. Para conseguir consistência na leitura das gravações para um grupo de aplicativos, cada aplicativo no grupo precisa usar um perfil de app configurado para o roteamento de cluster único e todos os perfis de app precisam encaminhar solicitações para o mesmo cluster. É possível usar os clusters adicionais da instância simultaneamente para outras finalidades.

O Cloud Bigtable também pode fornecer consistência forte quando a replicação está ativada, o que garante que todos os aplicativos vejam os dados no mesmo estado. Para conseguir uma consistência forte, use a configuração de perfil de aplicativo de roteamento de cluster único para consistência na leitura das gravações descrita acima. No entanto, não use os clusters adicionais da instância, a menos que seja necessário fazer failover para um cluster diferente.

Perfis de aplicativo

Caso uma instância use replicação, você usa perfis de aplicativo, ou perfis de app, para controlar quais clusters processam solicitações de entrada com base nos aplicativos. Os perfis de app também determinam se é possível realizar transações de linha única, que incluem operações de leitura/modificação/gravação (inclusive incrementos e acréscimos) e operações de verificação e mutação (também conhecidas como mutações ou gravações condicionais).

Para detalhes, consulte Perfis de aplicativo. Para exemplos de configurações que você pode usar para implementar casos de uso comuns, consulte Exemplos de configurações de replicação.

Failovers

Se um cluster do Cloud Bigtable parar de responder, a replicação possibilitará o failover do tráfego de entrada para outro cluster na mesma instância. Os failovers podem ser manuais ou automáticos, dependendo do perfil de app usado por um aplicativo e de como esse perfil está configurado.

Para detalhes, consulte Failovers.

Como descartar intervalos de linhas quando a replicação está ativada

A API Cloud Bigtable Admin permite descartar um intervalo contíguo de linhas de uma tabela com base nas chaves de linha delas. Em instâncias que não usam a replicação, o Cloud Bigtable pode descartar um intervalo de linhas de maneira rápida e eficiente. Porém, quando a replicação está ativada, descartar um intervalo de linhas é bem mais lento e muito menos eficiente.

A seguir

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

Enviar comentários sobre…

Documentação do Cloud Bigtable