Vista geral da replicação

A replicação para o Bigtable permite aumentar a disponibilidade e a durabilidade dos seus dados copiando-os em várias regiões ou várias zonas na mesma região. Também pode isolar cargas de trabalho encaminhando diferentes tipos de pedidos para diferentes clusters.

Esta página explica como funciona a replicação no Bigtable e descreve alguns exemplos de utilização comuns para a replicação. Também explica o modelo de consistência que o Bigtable usa quando a replicação está ativada e descreve o que acontece quando um cluster muda para outro em caso de falha.

  • Para ver exemplos de definições que pode usar para implementar exemplos de utilização comuns, consulte o artigo Exemplos de configurações de replicação.
  • Para saber como criar uma instância que use a replicação, consulte o artigo Crie uma instância.
  • Para saber como ativar a replicação para uma instância existente, consulte o artigo Adicione um cluster.
  • Para compreender os custos associados à replicação, consulte a secção Preços.

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

Como funciona a replicação

Para usar a replicação numa instância do Bigtable, crie uma nova instância com mais do que um cluster ou adicione clusters a uma instância existente.

As instâncias do Bigtable podem ter clusters localizados em até 8 regiões do Bigtable e, em cada uma dessas 8 regiões, a instância só pode conter um cluster por zona. Por exemplo, se criar uma instância em 8 regiões que tenham 3 zonas cada, a sua instância pode ter até 24 clusters.

Cada zona numa região só pode conter um cluster. Ter clusters em diferentes zonas ou regiões permite-lhe aceder aos dados da sua instância mesmo que uma zona ou uma região fique indisponível. Google Cloud

Quando cria uma instância com mais do que um cluster, o Bigtable começa imediatamente a sincronizar os seus dados entre os clusters, criando uma cópia separada e independente dos seus dados em cada zona onde a sua instância tem um cluster. Da mesma forma, quando adiciona um novo cluster a uma instância existente, o Bigtable copia os dados existentes da zona do cluster original para a zona do novo cluster e, em seguida, sincroniza as alterações aos dados entre as zonas.

O Bigtable replica todas as alterações aos seus dados, incluindo todos os seguintes tipos de alterações:

  • Atualizações aos dados em tabelas existentes
  • Tabelas novas e eliminadas
  • Famílias de colunas adicionadas e removidas
  • Alterações à política de recolha de lixo de uma família de colunas

A replicação tem alguma latência e a consistência entre clusters é eventual.

O Bigtable trata cada cluster na sua instância como um cluster principal, pelo que pode fazer leituras e escritas em cada cluster. Também pode configurar a sua instância para que os pedidos de diferentes tipos de aplicações sejam encaminhados para diferentes clusters.

Antes de adicionar clusters a uma instância, deve ter em atenção as restrições que se aplicam quando altera as políticas de recolha de lixo para tabelas replicadas.

Desempenho

A utilização da replicação tem implicações no desempenho que deve planear quando criar uma instância replicada ou ativar a replicação adicionando um cluster a uma instância de cluster único. Por exemplo, os clusters replicados em diferentes regiões têm normalmente uma latência de replicação mais elevada do que os clusters replicados na mesma região. Além disso, os clusters em instâncias com mais de um cluster precisam frequentemente de mais nós para processar o trabalho adicional de processamento da replicação. Para saber mais, consulte o artigo Compreenda o desempenho.

Exemplos de utilização

Esta secção descreve alguns exemplos de utilização comuns da replicação do Bigtable. Para encontrar as melhores definições de configuração para cada exemplo de utilização, bem como sugestões de implementação para outros exemplos de utilização, consulte o artigo Exemplos de definições de replicação.

Isole as aplicações de publicação de leituras em lote

Quando usa um único cluster para executar uma tarefa de estatísticas em lote que realiza inúmeras leituras grandes, juntamente com uma aplicação que realiza uma combinação de leituras e escritas, a tarefa em lote grande pode tornar as coisas mais lentas para os utilizadores da aplicação. Com a replicação, pode usar perfis de apps com o encaminhamento de cluster único para encaminhar tarefas de estatísticas em lote e tráfego de aplicações para diferentes clusters, de modo que as tarefas em lote não afetem os utilizadores das suas aplicações. Saiba mais sobre a implementação deste exemplo de utilização.

Melhore a disponibilidade

Se uma instância tiver apenas um cluster, a durabilidade e a disponibilidade dos seus dados estão limitadas à zona onde esse cluster está localizado. A replicação pode melhorar a durabilidade e a disponibilidade armazenando cópias separadas dos seus dados em várias zonas ou regiões e fazendo automaticamente a comutação por falha entre clusters, se necessário. Saiba mais sobre a implementação deste exemplo de utilização.

Ofereça uma cópia de segurança quase em tempo real

Em alguns casos, por exemplo, se não puder dar-se ao luxo de ler dados desatualizados, tem sempre de encaminhar pedidos para um único cluster. No entanto, pode continuar a usar a replicação processando pedidos com um cluster e mantendo outro cluster como uma cópia de segurança quase em tempo real. Se o cluster de publicação ficar indisponível, pode minimizar o tempo de inatividade fazendo manualmente a comutação por falha para o cluster de cópia de segurança. Saiba mais sobre a implementação deste exemplo de utilização.

Certifique-se de que os seus dados têm uma presença global

Pode configurar a replicação em localizações em todo o mundo para colocar os seus dados mais perto dos seus clientes. Por exemplo, pode criar uma instância com clusters replicados nos EUA, na Europa e na Ásia, e configurar perfis de apps para encaminhar o tráfego de aplicações para o cluster mais próximo. Saiba mais sobre a implementação deste exemplo de utilização.

Modelos de consistência

Esta secção explica os modelos de consistência que o Bigtable pode fornecer para a replicação, consoante a política de encaminhamento que usar.

Consistência eventual

Por predefinição, a replicação do Bigtable é eventualmente consistente. Este termo significa que, quando escreve uma alteração num cluster, pode eventualmente ler essa alteração nos outros clusters na instância, mas apenas depois de a alteração ser replicada entre os clusters.

Se a sua instância for reativa, a latência da replicação é normalmente de alguns segundos ou minutos, e não horas. No entanto, se estiver a escrever uma grande quantidade de dados num cluster ou se um cluster estiver sobrecarregado ou temporariamente indisponível, a replicação pode demorar algum tempo a ficar atualizada. Além disso, a replicação pode demorar mais tempo se os seus clusters estiverem distantes. Como resultado, normalmente, não é seguro assumir que está sempre a ler o valor mais recente que foi escrito ou que aguardar alguns segundos após uma escrita dá ao Bigtable tempo suficiente para replicar a alteração.

Consistência de leitura/escrita

Pode alcançar a consistência de leitura das suas escritas com o encaminhamento de cluster único e pode alcançar uma taxa elevada de consistência de leitura das suas escritas usando o encaminhamento de vários clusters com o encaminhamento de afinidade de linhas ou quando os clusters da sua instância estão cada um numa região diferente.

Encaminhamento de cluster único

Se usar o encaminhamento de cluster único, o Bigtable pode oferecer uma consistência de leitura das suas gravações quando a replicação está ativada. Este modelo de consistência garante que uma aplicação nunca lê dados mais antigos do que as suas escritas mais recentes.

Cada perfil de app que usar tem de estar configurado para o encaminhamento de cluster único e todos os perfis de app têm de encaminhar pedidos para o mesmo cluster. Pode usar os clusters adicionais da instância ao mesmo tempo para outros fins.

Encaminhamento de vários clusters com um cluster por região

Com o encaminhamento de vários clusters, o Bigtable encaminha sempre os pedidos para o cluster mais próximo. Se cada cluster na sua instância estiver numa região do Bigtable diferente e usar um perfil de app configurado para o encaminhamento de vários clusters, os seus dados têm consistência de leitura das suas escritas na região de origem, a menos que ocorra uma comutação por falha.

Encaminhamento de afinidade de linhas

Para alcançar uma taxa mais elevada de consistência de leitura/escrita com o encaminhamento de vários clusters para uma instância que tenha mais do que um cluster numa região, pode usar um perfil de app configurado para encaminhamento de afinidade de linhas (encaminhamento persistente).

Com o encaminhamento de afinidade de linhas, o Bigtable encaminha automaticamente os seus pedidos de leitura e escrita de linha única para um cluster específico com base na chave de linha do pedido. Não é possível definir manualmente o mapeamento entre a chave da linha e o cluster. A consistência não é garantida porque os pedidos podem continuar a falhar por vários motivos, incluindo quando um cluster não está em bom estado, existem problemas de rede ou o cluster recebeu demasiados pedidos.

Consistência forte

Para alguns exemplos de utilização da replicação, o Bigtable também pode fornecer consistência forte, o que garante que todas as suas aplicações veem os seus dados no mesmo estado. Para obter uma forte consistência, usa a configuração do perfil da app de encaminhamento de cluster único para a consistência de leitura das suas escritas descrita anteriormente, mas não deve usar os clusters adicionais da instância, a menos que precise de fazer failover para um cluster diferente. Reveja os exemplos de definições de replicação para ver se isto é possível para o seu caso de utilização.

Resolução de conflitos

Cada valor de célula numa tabela do Bigtable é identificado exclusivamente pela tupla de quatro elementos (chave da linha, família de colunas, qualificador da coluna e data/hora). Consulte o artigo Modelo de armazenamento do Bigtable para ver mais detalhes sobre estes identificadores. No caso de serem enviadas duas escritas com a mesma tupla de quatro elementos exata para dois clusters diferentes, o Bigtable resolve automaticamente o conflito através de um algoritmo interno last write wins com base na hora do servidor. A implementação "last write wins" do Bigtable é determinística e, quando a replicação é atualizada, todos os clusters têm o mesmo valor para a tupla de quatro elementos.

Perfis de aplicações

Se uma instância usar a replicação, usa perfis de aplicações ou perfis de apps para especificar políticas de encaminhamento. Os perfis de apps também determinam se pode realizar transações de linha única, que incluem operações de leitura-modificação-escrita (incluindo incrementos e anexos) e operações de verificação e mutação (também conhecidas como mutações condicionais ou escritas condicionais).

Para ver detalhes, consulte o artigo Perfis de candidatura. Para ver exemplos de definições que pode usar para implementar exemplos de utilização comuns, consulte o artigo Exemplos de configurações de replicação.

Políticas de encaminhamento

Cada perfil de app tem uma política de encaminhamento que controla que clusters processam pedidos recebidos das suas aplicações. As opções para políticas de encaminhamento incluem o seguinte:

  • Encaminhamento de cluster único: envia todos os pedidos para um único cluster que especificar.
  • Encaminhamento de vários clusters:
    • Qualquer encaminhamento de cluster: envia pedidos para o cluster mais próximo na instância.
    • Encaminhamento do grupo de clusters: restringe todos os pedidos aos clusters que especificar.
    • Encaminhamento de afinidade de linhas: envia um pedido de leitura ou escrita de linha única para um cluster específico com base na chave da linha do pedido. Para mais informações, consulte o artigo Encaminhamento por afinidade de linhas.

Comutações por falha

Se um cluster do Bigtable deixar de responder, a replicação permite que o tráfego recebido seja transferido para outro cluster na mesma instância. As comutações por falha podem ser manuais ou automáticas, consoante o perfil da app que uma aplicação está a usar e como o perfil da app está configurado. Para obter detalhes, consulte a secção Failovers.

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

A Cloud Bigtable Admin API permite-lhe eliminar um intervalo contíguo de linhas de uma tabela com base nas respetivas chaves de linhas. Em instâncias que não usam a replicação, o Bigtable pode eliminar um intervalo de linhas de forma rápida e eficiente. No entanto, quando a replicação está ativada, a eliminação de um intervalo de linhas é significativamente mais lenta e muito menos eficiente.

O que se segue?