Perfis de app

Um perfil de app armazena configurações que informam à instância do Cloud Bigtable como processar solicitações de entrada com base em um aplicativo. Quando um aplicativo se conecta a uma instância do Bigtable, ele pode especificar um perfil de app, e o Bigtable usará esse perfil para solicitações que o aplicativo envia por meio dessa conexão. Um perfil de aplicativo define a política de roteamento que o Bigtable usa e controla se transações de linha única são permitidas.

Perfis de aplicativo são especialmente úteis para instâncias que têm dois ou mais clusters. Mesmo que a instância tenha apenas um cluster, use um único perfil de app para cada aplicativo executado ou para componentes diferentes de um único aplicativo. Em seguida, é possível visualizar gráficos separados das métricas do Bigtable para cada perfil de app.

Nesta página, conheça as configurações controladas por um perfil de app e saiba como eles funcionam com o aplicativo.

Se você estiver usando perfis de aplicativo para configurar políticas de roteamento de cluster, familiarize-se com a visão geral da replicação do Bigtable antes de ler esta página.

Política de roteamento

Um perfil de app especifica a política de roteamento que o Bigtable precisa usar em cada solicitação.

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

  • O roteamento de vários clusters encaminha automaticamente as solicitações para o cluster mais próximo em uma instância. Se o cluster ficar indisponível, o tráfego realizará automaticamente o failover para o cluster disponível mais próximo. O Bigtable considera que os clusters em uma única região são equidistantes, mesmo que estejam em zonas diferentes. É possível configurar um perfil de aplicativo para rotear para qualquer cluster em uma instância ou especificar um grupo de clusters que informe ao perfil do aplicativo para rotear. apenas alguns dos clusters na instância.

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

Transações de linha única

No Bigtable, as leituras e as gravações são sempre atômicas no nível da linha. 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. Como resultado, operações que exigem transações de linha única podem causar problemas em instâncias de vários clusters.

Por exemplo, digamos 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, seu 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.

Como perfis de app funcionam

Um perfil de app especifica as configurações usadas pelo Bigtable para processar solicitações de entrada de uma instância.

Muitos usuários do Bigtable têm vários aplicativos que se conectam à mesma instância. Por exemplo, talvez haja um aplicativo que veicule dados para clientes mediante a solicitação e outro aplicativo que execute alguns jobs em lote para analisar os dados. Para processar esses aplicativos diferentes, você precisa criar vários perfis de app, pelo menos um para cada aplicativo, e configurar cada perfil de app com as configurações certas para esse aplicativo. Essa configuração possibilita a alteração das definições de um aplicativo, mas não de outros.

Você também pode ter um único aplicativo que realize várias funções, como visualizar os dados atuais e consultar os dados históricos. Para processar essas funções diferentes, você precisa criar um perfil de aplicativo para cada função. Dessa maneira, configure cada função de maneira diferente e atualize as configurações para uma função, e não outras.

Cada instância tem um perfil de app default, e você também pode criar perfis de aplicativo personalizados para cada instância. As seções abaixo descrevem default e perfis de aplicativo personalizados.

Ao se conectar à instância, use o perfil de app para especificá-lo no código. Se você não especificar um perfil de app, o Bigtable usará o perfil de app padrão da instância.

Perfil de app padrão

Quando você cria uma instância, o Bigtable cria automaticamente um perfil de app padrão para a instância. Caso o aplicativo não especifique um perfil de app ou você use o shell do HBase para se conectar à instância, o Bigtable usará as configurações no perfil de app padrão. É possível visualizar e alterar essas configurações a qualquer momento.

As configurações no perfil de app padrão de uma instância dependem do número de clusters que a instância tinha quando você a criou:

  • Se você criou a instância com um cluster, o perfil de app default usa o roteamento de cluster único e ativa transações de linha única. Isso garante que, ao adicionar mais clusters posteriormente, o comportamento de seus aplicativos atuais não será alterado.
  • Se você criou a instância com dois ou mais clusters, o perfil de app default usa o roteamento de vários clusters. As Transações de linha única não são permitidas com roteamento de vários clusters.

O perfil de app padrão não é alterado ao adicionar ou remover clusters. Você precisa atualizar o perfil de app padrão manualmente para alterar as configurações. No entanto, recomendamos que você crie e use um novo perfil de aplicativo em vez de alterar o perfil de aplicativo padrão.

Perfis de app personalizados

Um perfil de app personalizado é um perfil de app que você cria e configura. Uma instância pode ter até 2.000 perfis de aplicativo.

A seguir