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 app padrão.

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 Aumento de dados (Pré-lançamento). É possível configurá-los em 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 transações de linha única com roteamento de vários clusters porque elas podem causar conflitos de dados quando você usa esse recurso. 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.

Roteamento de afinidade de linha

O roteamento de afinidade de linha encaminha automaticamente 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.

Se você quiser que o roteamento de vários clusters alcance uma taxa mais alta de consistência na leitura das gravações e a maioria das suas solicitações forem operações de linha única, use o roteamento de afinidade de linha (roteamento fixo). Para ativar o roteamento de afinidade de linha, use um perfil de app personalizado com a flag --row-affinity ativada. O Bigtable usa a chave de linha da solicitação para determinar automaticamente para qual cluster encaminhar a solicitação. Não é possível definir manualmente o mapeamento entre a chave de linha e o cluster.

O roteamento de afinidade de linha só pode ser usado para solicitações de leitura ou gravação de uma única linha. Isso inclui solicitações que chamam ReadRows com uma chave especificada, MutateRow, MutateRows com uma chave especificada e BulkMutateRow com uma chave especificada.

A consistência na leitura das gravações não é totalmente alcançada com o roteamento de afinidade de linha nos seguintes casos:

  • Adição de um cluster à instância: o roteamento de afinidade de linha determina qual cluster será roteado com base na chave de linha. Se um novo cluster for adicionado ou removido da instância enquanto o roteamento de afinidade de linha estiver ativado, a atribuição da chave de linha poderá mudar. Para garantir que a ordem de failover do cluster permaneça a mesma, apesar das mudanças na lista de clusters da instância, recomendamos usar grupos de clusters definindo a flag --restrict-to.

    Com os grupos de clusters, não é possível excluir um cluster em uma instância enquanto ele está em uso por um perfil de app. Além disso, qualquer novo cluster adicionado à instância não começa a receber solicitações, a menos que seja adicionado explicitamente ao grupo de cluster do perfil do app.

  • Failover: se um cluster estiver indisponível ou não estiver em bom estado, as solicitações para o cluster afetado serão direcionadas para o próximo cluster de acordo com a ordem de failover. Essa alteração pode afetar a consistência.

Para mais informações sobre failovers, consulte Failovers. Para saber como concluir um failover, consulte Como gerenciar failovers.

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 para 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 Agrupar valores 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. Use um contador de números inteiros para armazenar o número de ingressos vendidos. Cada vez que você vende um ingresso, o app envia uma operação 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