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 em até oito regiões do Bigtable, e em cada uma delas oito regiões, a instância pode conter apenas um cluster por zona. Para exemplo, se você criar uma instância em 8 com três zonas, a instância pode ter até 24 clusters.

Cada zona em uma região pode conter apenas um cluster. Clusters em zonas ou regiões diferentes permite que você acesse os dados da sua instância quando uma zona ou região do Google Cloud fica 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 dados estarão limitadas à zona onde o cluster está localizado. 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á 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.

Modelo de consistência

Por padrão, a replicação do 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 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.

Se você precisar de uma garantia de consistência diferente, o 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 leia 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 aplicativo configurado para o encaminhamento de cluster único e todos os perfis de aplicativo precisam encaminhar pedidos para o mesmo cluster. É possível usar outros clusters da instância simultaneamente para outras finalidades.

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 obter uma consistência forte, use o configuração de perfil de aplicativo de roteamento de cluster único para leitura das gravações consistência descrita anteriormente, mas você não deve usar o clusters extras, a menos que você precise fazer failover para um cluster. 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 ver 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 de vários clusters para qualquer cluster: envia solicitações para o cluster disponível mais próximo na instância.
  • Roteamento do grupo de clusters: envia solicitações para o cluster disponível mais próximo em um grupo de clusters especificado nas configurações do perfil de aplicativo.

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 detalhes, consulte Failovers.

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

A API Cloud Bigtable Admin permite eliminar um intervalo contíguo de linhas de uma tabela com base nas chaves de linha. 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