Opções de encaminhamento

Quando envia pedidos de uma aplicação para o Bigtable, usa um perfil da app que indica ao Bigtable como processar os pedidos. Um perfil de app especifica a política de encaminhamento para os pedidos. Para instâncias que usam a replicação, a política de encaminhamento controla que clusters recebem os pedidos e como são processadas as comutações por falha.

Este documento descreve as políticas de encaminhamento disponíveis para um perfil de app padrão.

As políticas de encaminhamento são especialmente importantes para exemplos de utilização de isolamento de cargas de trabalho, quando não pode usar o Aumento de dados. Pode configurá-los em conjunto com as prioridades de pedidos.

As políticas de encaminhamento não afetam a replicação, mas deve saber como funciona a replicação do Bigtable antes de ler esta página. Também deve ler o artigo Failovers.

Encaminhamento de cluster único

Uma política de encaminhamento de cluster único encaminha todos os pedidos para um cluster na sua instância. Se esse cluster ficar indisponível, tem de fazer manualmente a comutação por falha para outro cluster.

Esta é a única política de encaminhamento que lhe permite ativar transações de uma única linha.

Normalmente, uma instância replicada oferece consistência eventual. No entanto, pode alcançar a consistência de leitura das suas escritas para uma carga de trabalho numa instância replicada se configurar um perfil da app para que essa carga de trabalho use o encaminhamento de cluster único para enviar pedidos de leitura e escrita para o mesmo cluster. Pode encaminhar o tráfego para cargas de trabalho adicionais na instância replicada para outros clusters na instância, consoante os requisitos da carga de trabalho.

Encaminhamento em vários clusters

Uma política de encaminhamento de vários clusters encaminha os pedidos que envia para uma instância para a região mais próxima na qual a instância tem um cluster. Se o cluster ficar indisponível, o tráfego é automaticamente transferido para o cluster disponível mais próximo.

Esta configuração oferece consistência eventual. Não pode ativar transações de linha única com o encaminhamento de vários clusters, porque as transações de linha única podem causar conflitos de dados quando usa o encaminhamento de vários clusters. Para obter detalhes, consulte o artigo Transações de uma única linha.

Use o encaminhamento de vários clusters se quiser alta disponibilidade (HA). Para ver configurações de instâncias recomendadas e mais detalhes, consulte o artigo Crie alta disponibilidade (HA).

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

Para mais informações sobre considerações de encaminhamento relacionadas com SQL, consulte a secção Encaminhamento com SQL deste documento.

Qualquer encaminhamento de cluster

A encaminhamento de clusters torna todos os clusters na instância disponíveis para receber pedidos e para a comutação por falha.

Encaminhamento de grupos de clusters

Se quiser excluir um ou mais clusters de uma instância da possível comutação por falha, pode usar o encaminhamento de grupos de clusters. Esta forma de encaminhamento de vários clusters permite especificar um subconjunto de clusters para os quais um perfil de app pode enviar tráfego. Isto pode ser útil se quiser reservar um cluster para uma carga de trabalho separada.

Encaminhamento de afinidade de linhas

O encaminhamento de afinidade de linhas encaminha automaticamente pedidos de leitura e escrita de linha única para um cluster específico com base na chave de linha do pedido.

Se quiser o encaminhamento de vários clusters para alcançar uma taxa mais elevada de consistência de leitura das suas escritas e a maioria dos seus pedidos forem operações de linha única, pode usar o encaminhamento de afinidade de linhas (encaminhamento persistente). Para ativar o encaminhamento de afinidade de linhas, use um perfil de app personalizado com a flag --row-affinity ativada. O Bigtable usa a chave da linha do pedido para determinar automaticamente para que cluster encaminhar o pedido. Não pode definir manualmente o mapeamento entre a chave da linha e o cluster.

O encaminhamento de afinidade de linhas só pode ser usado para pedidos de leitura ou escrita de linha única. Isto inclui pedidos que chamam ReadRows com uma chave especificada, MutateRow, e MutateRows com uma chave especificada, e BulkMutateRow com uma chave especificada.

A consistência de leitura das suas escritas não é totalmente alcançada com o encaminhamento de afinidade de linhas nos seguintes casos:

  • Adicionar um cluster à instância: o encaminhamento de afinidade de linhas determina para que cluster encaminhar com base na chave de linha. Se for adicionado ou removido um novo cluster à instância enquanto o encaminhamento de afinidade de linhas estiver ativado, a atribuição de chave de linha pode mudar. Para garantir que a ordem de comutação por falha do cluster permanece a mesma, apesar das alterações à lista de clusters da instância, recomendamos que use grupos de clusters definindo a flag --restrict-to.

    Com os grupos de clusters, não pode eliminar um cluster numa instância enquanto estiver a ser usado por um perfil de app. Além disso, qualquer novo cluster adicionado à instância não começa a receber pedidos, a menos que seja adicionado explicitamente ao grupo de clusters do perfil da app.

  • Failover: se um cluster estiver indisponível ou em mau estado, os pedidos para o cluster afetado são direcionados para o cluster seguinte de acordo com a ordem de failover. Este reencaminhamento pode afetar a consistência.

Para mais informações sobre as comutações por falha, consulte o artigo Comutações por falha. Para saber como concluir uma comutação por falha, consulte o artigo Gerir comutações por falha.

Encaminhamento com SQL

Quando usa o SQL para consultar o Bigtable, existem considerações especiais sobre a forma como os seus pedidos são encaminhados. O comportamento de encaminhamento das consultas SQL difere de outros tipos de pedidos do Bigtable das seguintes formas:

  • Embora uma política de encaminhamento de vários clusters ofereça elevada disponibilidade através da comutação por falha automática para a maioria dos pedidos, este comportamento não se aplica às consultas SQL. Se um pedido SQL falhar, não é transferido para outro cluster, mesmo que o perfil da sua app esteja configurado para o encaminhamento de vários clusters.
  • O encaminhamento de afinidade de linhas direciona as leituras e as escritas de linhas únicas automaticamente para um cluster específico com base na chave de linha. No entanto, o Bigtable não suporta esta política de encaminhamento para consultas SQL. Esta limitação significa que não pode usar o encaminhamento de afinidade de linhas com o método ExecuteQuery, mesmo que a consulta seja concebida para ler uma única linha. Se enviar um pedido ExecuteQuery usando um perfil de app com a flag --row-affinity ativada, o pedido é bem-sucedido, mas a afinidade de linhas não é aplicada.

Transações de linha única

Nas mutações do Bigtable, como pedidos de leitura, escrita e eliminação, são sempre atómicas ao nível da linha. Isto inclui mutações em várias colunas numa única linha, desde que estejam incluídas na mesma operação de mutação. O Bigtable não suporta transações que atualizam atomicamente mais do que uma linha.

No entanto, o Bigtable suporta algumas operações de escrita que requerem uma transação noutras bases de dados. Na prática, o Bigtable usa transações de linha única para concluir estas operações. Estas operações incluem leituras e escritas, e todas as leituras e escritas são executadas atomicamente, mas as operações continuam a ser atómicas apenas ao nível da linha:

  • Operações de leitura-modificação-escrita, incluindo incrementos e anexos. Uma operação de leitura-modificação-escrita lê um valor existente, incrementa ou acrescenta ao valor existente e escreve o valor atualizado na tabela.
  • Operações de verificação e alteração, também conhecidas como mutações condicionais ou gravações condicionais. Numa operação de verificação e modificação, o Bigtable verifica se uma linha cumpre uma condição especificada. Se a condição for cumprida, o Bigtable escreve novos valores na linha.

Conflitos entre transações de linha única

Cada cluster numa instância do Bigtable é um cluster principal que aceita leituras e escritas. Como resultado, as operações que requerem transações de linha única podem causar problemas em instâncias replicadas.

Se o seu exemplo de utilização o permitir, pode evitar estes conflitos através da utilização de agregados. Quando envia um pedido de adição a um campo agregado, o novo valor é unido ao valor existente. As agregações permitem-lhe manter uma soma ou um contador contínuo. Para mais informações, consulte o artigo Agregue valores no momento da gravação.

Para ilustrar o problema que pode surgir quando não usa agregações, suponha que tem uma tabela que usa para armazenar dados para um sistema de emissão de bilhetes. Usa um contador de números inteiros para armazenar o número de bilhetes que foram vendidos. Sempre que vende um bilhete, a sua app envia uma operação de leitura-modificação-escrita para aumentar o contador em 1.

Se a sua instância tiver um cluster, as apps cliente podem vender bilhetes em simultâneo e incrementar os contadores sem perda de dados, porque os pedidos são processados atomicamente pela ordem em que são recebidos por esse único cluster.

Por outro lado, se a sua instância tiver vários clusters e o perfil da app permitisse o encaminhamento de vários clusters, os pedidos simultâneos para incrementar o contador poderiam ser enviados para diferentes clusters e, em seguida, replicados para os outros clusters na instância. Se enviar dois pedidos de incremento ao mesmo tempo que são encaminhados para clusters diferentes, cada um conclui a respetiva 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 não tem forma de saber que pretendia incrementá-los em 2.

Para ajudar a evitar resultados não intencionais, o Bigtable faz o seguinte:

  • Requer que cada perfil de app especifique se permite transações de linha única.
  • Impede a ativação de transações de linha única num perfil de app que use o encaminhamento de vários clusters, porque não existe uma forma segura de ativar ambas as funcionalidades em simultâneo.
  • Avisa se ativar transações de linha única em dois ou mais perfis de apps diferentes que usam o encaminhamento de cluster único e apontam para clusters diferentes. Se optar por criar este tipo de configuração, tem de garantir que não envia pedidos de leitura-modificação-gravação ou de verificação e mutação em conflito para diferentes clusters.

O que se segue?