Opções de roteamento

Ao enviar solicitações de um aplicativo para o Bigtable, você usa um perfil de app que informa ao Bigtable como processar as solicitações. Um perfil de app especifica a política de roteamento das solicitações. Para instâncias que usam replicação, a política de roteamento controla quais clusters recebem as solicitações e como os failovers são processados.

Este documento descreve as políticas de roteamento disponíveis para um perfil de aplicativo.

As políticas de roteamento são especialmente importantes para casos de uso de isolamento de cargas de trabalho, quando não é possível usar o Boost de dados (pré-lançamento). É possível configurá-las no conjunto com as prioridades de solicitação.

As políticas de roteamento não afetam a replicação, mas você precisa estar familiarizado com como a replicação do Bigtable funciona antes de ler esta página. Leia também sobre Failovers.

Roteamento de cluster único

Uma política de roteamento de cluster único encaminha todas as solicitações para um cluster na instância. Caso esse cluster fique indisponível, será preciso fazer failover manualmente para outro cluster.

Essa é a única política de roteamento que permite ativar transações de linha única.

Uma instância replicada normalmente fornece consistência eventual. No entanto, é possível atingir uma consistência de leitura de gravações para uma carga de trabalho em uma instância replicada se você configurar um perfil de app para que ela use o roteamento de cluster único para enviar solicitações de leitura e gravação para o mesmo cluster. É possível rotear o tráfego de cargas de trabalho adicionais na instância replicada para outros clusters na instância, dependendo dos requisitos da carga de trabalho.

Roteamento de vários clusters

Uma política de roteamento de vários clusters encaminha as solicitações enviadas para uma instância para a região mais próxima em que a instância tem um cluster. Se o cluster ficar indisponível, o tráfego realizará automaticamente o failover para o cluster disponível mais próximo.

Essa configuração oferece consistência posterior. Não é possível ativar com roteamento de vários clusters, já que as transações de linha única podem fazer com que os dados conflitos ao usar roteamento de vários clusters. Para mais detalhes, consulte Transações de linha única.

Use o roteamento de vários clusters se quiser alta disponibilidade (HA, na sigla em inglês). Para ver as configurações de instância recomendadas e mais detalhes, consulte Criar alta disponibilidade (HA, na sigla em inglês).

Os dois tipos de roteamento de vários clusters são qualquer cluster e grupo de clusters.

Qualquer roteamento de cluster

Qualquer roteamento de cluster disponibiliza todos os clusters na instância para receber solicitações e para failover.

Roteamento do grupo de clusters

Para excluir um ou mais clusters de uma instância de um possível failover, use o roteamento do grupo de clusters. Essa forma de roteamento de vários clusters permite especificar um subconjunto de clusters para os quais um perfil de app pode enviar tráfego. Isso pode ser útil se você quiser reservar um cluster para uma carga de trabalho separada.

Transações de linha única

Mutações do Bigtable, como solicitações de leitura, gravação e exclusão, são sempre atômicas no nível da linha. Isso inclui mutações para várias colunas em uma única linha, desde que elas estejam contidas na mesma operação de mutação. O Bigtable não é compatível com transações que atualizam atomicamente mais de uma linha.

Porém, o Bigtable também aceita algumas operações de gravação que exigiriam uma transação em outros bancos de dados: Na verdade, o Bigtable usa transações de linha única para concluir essas operações. Entre essas operações estão leituras e gravações, e todas as leituras e gravações são executadas de maneira atômica, mas as operações ainda continuam atômicas apenas no nível da linha:

  • Operações de leitura/modificação/gravação, inclusive incrementos e acréscimos. Uma operação de leitura/modificação/gravação lê um valor, incrementa ou acrescenta ao valor, além de gravar o valor atualizado na tabela.
  • Operações de verificação/mutação, também conhecidas como mutações ou gravações condicionais. Em uma operação de verificação e mutação, o Bigtable verifica uma linha para saber se atende a uma condição especificada. Caso a condição seja atendida, o Bigtable gravará novos valores na linha.

Conflitos entre transações de linha única

Cada cluster em uma instância do Bigtable é um cluster principal que aceita leituras e gravações. Consequentemente, operações que exigem transações de linha única podem causar problemas em instâncias replicadas.

Se o caso de uso permitir, use agregados para evitar esses conflitos. Quando você envia uma solicitação de adição a um campo agregado, o novo valor é mesclado com o valor atual. Os agregados permitem manter uma soma ou um contador em execução. Para mais informações, consulte Valores agregados no momento da gravação.

Para ilustrar o problema que pode surgir quando você não usa agregados, suponha que você tenha uma tabela para armazenar dados de um sistema de venda de ingressos. Você usa uma contador inteiro para armazenar o número de ingressos que foram vendidos. Cada vez você vende uma passagem, seu app envia um comando read-modify-write. para incrementar o contador em 1.

Se a instância tiver um cluster, os apps clientes poderão vender ingressos ao mesmo tempo e incrementar os contadores sem perda de dados, já que as solicitações serão processadas atomicamente na ordem em que forem recebidas por esse único cluster.

Por outro lado, se a instância tiver vários clusters e o perfil do app permitir o roteamento de vários clusters, solicitações simultâneas para incrementar o contador poderão ser enviadas a clusters diferentes e replicadas para os outros clusters na instância. Se você enviar duas solicitações de incremento ao mesmo tempo que são roteadas para clusters diferentes, cada uma concluirá a transação sem "saber" sobre o outro. O contador em cada cluster é incrementado em um. Quando os dados são replicados para o outro cluster, o Bigtable talvez não saiba que quer aumentar para 2.

Para ajudar a evitar resultados não pretendidos, o Bigtable:

  • Exige que cada perfil de app especifique se ele permite transações de linha única
  • Evita que você ative transações de linha única em um perfil de app que usa roteamento multicluster, porque não há maneira segura de ativar esses recursos de uma só vez
  • Avisa se você ativa transações de linha única em dois ou mais perfis de app diferentes que usam roteamento de cluster único e apontam para clusters diferentes. Caso opte por criar esse tipo de configuração, você precisará garantir que não esteja enviando solicitações de leitura/modificação/gravação conflitantes ou de verificação/mutação para dois clusters diferentes.

A seguir