Visão geral da replicação

Com a replicação do Bigtable, é possível aumentar a disponibilidade e a durabilidade dos dados, copiando-os em várias regiões ou zonas na mesma região. Também é possível isolar cargas de trabalho encaminhando tipos diferentes de solicitações para clusters distintos.

Nesta página, explicaremos como a replicação funciona no Bigtable e alguns casos de uso comuns de replicação. Também explicaremos o modelo de consistência usado pelo Bigtable quando a replicação está ativada e descreveremos o que acontece quando ocorre um failover de um cluster para outro.

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

Como a replicação funciona

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

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 pode conter apenas um cluster por zona. Por exemplo, se você criar uma instância em oito regiões com três zonas cada, ela poderá ter até 24 clusters.

Cada zona em uma região pode conter apenas um cluster. Ter clusters em zonas ou regiões diferentes permite acessar os dados da instância, mesmo que uma zona ou região do Google Cloud fique indisponível.

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

O Bigtable replica todas as alterações nos dados, incluindo todos os tipos de alterações a seguir:

  • 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 do grupo de colunas

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

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

Antes de adicionar clusters a uma instância, conheça as restrições que se aplicam quando você altera as políticas de coleta de lixo para tabelas replicadas.

Desempenho

O uso da replicação tem implicações de desempenho que você precisa planejar ao 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 várias regiões geralmente têm uma latência de replicação maior do que os replicados na mesma região. Além disso, os clusters em instâncias que têm mais de um cluster geralmente precisam de mais nós para processar o trabalho extra de manipulação da replicação. Para mais informações, consulte Entender o desempenho.

Casos de uso

Nesta seção, descrevemos casos de uso comuns para a replicação do 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 dos 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á rotear 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.

Modelos de consistência

Esta seção explica os modelos de consistência que o Bigtable pode fornecer para a replicação, dependendo da política de roteamento usada.

Consistência eventual

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

Caso a instância seja responsiva, a latência 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, pode demorar algum tempo para a replicação acompanhar. Além disso, a replicação poderá levar mais tempo se os clusters estiverem distantes. Como resultado, normalmente não é seguro presumir que você esteja sempre lendo o valor mais recente gravado ou que aguardar alguns segundos após a gravação dá ao Bigtable tempo suficiente para replicar a alteração.

Consistência na leitura das gravações

É possível alcançar a consistência na leitura das gravações com o roteamento de cluster único e atingir uma alta taxa de consistência na leitura das gravações usando o roteamento de vários clusters com o roteamento de afinidade de linha ou quando os clusters da sua instância estão em regiões diferentes.

Roteamento de cluster único

Se você usar o roteamento de cluster único, o Bigtable poderá fornecer consistência de leitura de gravações quando a replicação estiver ativada. Esse modelo de consistência garante que um aplicativo nunca leia dados anteriores às gravações mais recentes.

Cada perfil de app usado precisa ser configurado para roteamento de cluster único e todos os perfis de app precisam encaminhar solicitações para o mesmo cluster. É possível usar outros clusters da instância simultaneamente para outras finalidades.

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

Com o roteamento de vários clusters, o Bigtable sempre encaminha as solicitações para o cluster mais próximo. Se cada cluster na sua instância estiver em uma região do Bigtable diferente e você usar um perfil de app configurado para o roteamento de vários clusters, os dados terão consistência na leitura das gravações na região de origem, a menos que ocorra um failover.

Roteamento de afinidade de linha

Para alcançar uma taxa mais alta de consistência na leitura das gravações com o roteamento de vários clusters para uma instância com mais de um cluster em uma região, use um perfil de aplicativo configurado para o roteamento de afinidade de linha (roteamento fixo).

Com o roteamento de afinidade de linha, o Bigtable encaminha automaticamente as solicitações de leitura e gravação de uma única linha para um cluster específico com base na chave de linha da solicitação. Não é possível definir manualmente o mapeamento entre a chave de linha e o cluster. A consistência não é garantida porque as solicitações ainda podem falhar por vários motivos, incluindo quando um cluster está com problemas, há problemas de rede ou o cluster recebeu muitas solicitações.

Consistência forte

Em alguns casos de uso de replicação, o Bigtable também pode fornecer consistência forte, 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 app 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. Analise os exemplos de configurações de replicação para ver se isso é possível no seu caso de uso.

Resolução de conflitos

Cada valor de célula em uma tabela do Bigtable é identificado exclusivamente por quatro tuplas (chave de linha, grupo de colunas, qualificador de coluna, carimbo de data/hora). Consulte Modelo de armazenamento do Bigtable para mais detalhes sobre esses identificadores. No caso raro em que duas gravações com as mesmas quatro tuplas são enviadas para dois clusters diferentes, o Bigtable resolve automaticamente o conflito usando um algoritmo interno de última gravação ganha com base no tempo do lado do servidor. A implementação "última gravação ganha" do Bigtable é determinista e, quando a replicação alcança, todos os clusters têm o mesmo valor para as quatro tuplas.

Perfis de aplicativos

Se uma instância usar a replicação, use perfis de aplicativo ou perfis de app para especificar políticas de roteamento. 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 conferir exemplos de configurações que podem ser usadas para implementar casos de uso comuns, consulte Exemplos de configurações de replicação.

Políticas de roteamento

Cada perfil tem uma política de roteamento que controla quais clusters processam as solicitações recebidas dos aplicativos. As opções para políticas de roteamento incluem o seguinte:

  • Roteamento de cluster único: envia todas as solicitações para um único cluster especificado por você.
  • Roteamento em vários clusters:
    • Roteamento de qualquer cluster: envia solicitações para o cluster mais próximo na instância.
    • Roteamento do grupo de clusters: restringe todas as solicitações a clusters especificados por você.
    • Roteamento de afinidade de linha: envia uma solicitação de leitura ou gravação de uma única linha para um cluster específico com base na chave de linha da solicitação. Para mais informações, consulte Roteamento de afinidade de linha.

Failovers

Se um cluster do Bigtable parar de responder, a replicação vai 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 mais 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 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