Gravações do Cloud Bigtable

Visão geral

Esta página lista os tipos de solicitações de gravação que você pode enviar ao Cloud Bigtable e descreve quando você deve usá-las e quando não deve.

As APIs de dados e as bibliotecas de cliente do Cloud Bigtable permitem que você grave dados programaticamente em suas tabelas. O Cloud Bigtable retorna uma resposta ou confirmação para cada gravação.

Cada biblioteca de cliente oferece a capacidade de enviar os seguintes tipos de solicitações de gravação:

  • Gravações simples
  • Incrementos e anexos
  • Gravações condicionais
  • Gravações em lote

As bibliotecas de cliente do Cloud Bigtable têm um recurso integrado de tentativas inteligentes para gravações simples e em lote, isto é, elas podem solucionar indisponibilidades temporárias sem interromper a tarefa. Por exemplo, se o aplicativo encontrar uma interrupção temporária ou um problema de rede enquanto tenta gravar dados, ele fará novas tentativas automaticamente até que a gravação seja confirmada ou que o prazo final da solicitação seja atingido. Essa resiliência funciona com instâncias de cluster único e de vários clusters, com roteamento de cluster único ou roteamento de vários clusters.

Para operações de gravação em lote e de streaming, use o conector do Dataflow para o Cloud Bigtable.

exemplos de cada tipo de gravação disponíveis para cada biblioteca de cliente do Cloud Bigtable.

Tipos de gravações e quando usá-las

Todas as solicitações de gravação incluem os seguintes componentes básicos:

  • O nome da tabela na qual gravar.
  • Um ID de perfil de aplicativo, que informa ao Cloud Bigtable como rotear o tráfego.
  • Uma ou mais mutações. Uma mutação é formada por quatro elementos:
    • Nome do grupo de colunas
    • Qualificador de coluna
    • Carimbo de data/hora
    • Valor que está sendo gravado no banco de dados

O carimbo de data e hora de uma mutação tem um valor padrão da data e hora atuais. Todas as mutações em uma única solicitação de gravação têm o mesmo carimbo, a menos que você os substitua. Você pode definir o carimbo de data/hora de todas as mutações em uma solicitação de gravação para que sejam iguais ou diferentes entre si.

Gravações simples

Você grava uma única linha no Cloud Bigtable com uma solicitação MutateRow que inclui o nome da tabela, o ID do perfil de aplicativo que será usado, uma chave de linha e até 100.000 mutações para essa linha. Uma gravação de linha única é atômica. Use esse tipo de gravação quando estiver fazendo várias mutações em uma única linha.

Para amostras de código que demonstram como enviar solicitações de gravação simples, consulte Como executar uma gravação simples.

Quando não usar gravações simples

As gravações simples não são o melhor modo para gravar dados nos seguintes casos de uso:

  • Ao gravar um lote de dados que terá chaves de linha contíguas . Nesse caso, você deve usar gravações em lote em vez de gravações simples consecutivas, já que é possível aplicar um lote contíguo em uma única chamada de back-end.

  • Se você quer alta capacidade (linhas por segundo ou bytes por segundo) e não exige baixa latência. As gravações em lote serão mais rápidas neste caso.

Incrementos e anexos

Caso queira anexar dados a um valor atual ou incrementar um valor numérico atual, envie uma solicitação ReadModifyWriteRow. Essa solicitação inclui o nome da tabela, o ID do perfil de aplicativo que será usado, uma chave de linha e um conjunto de regras para a gravação de dados. Cada regra inclui o nome do grupo de colunas, o qualificador de coluna e um valor de anexo ou um valor de incremento.

As regras são aplicadas segundo a ordenação. Por exemplo, se sua solicitação incluir uma solicitação para incrementar o valor de uma coluna em dois, e uma regra posterior na mesma solicitação incrementar a mesma coluna em um, a coluna será incrementada em 3 nessa única gravação atômica. A regra posterior não substitui a regra anterior.

Um valor pode ser incrementado apenas se for codificado como um número inteiro com sinal big-endian de 64 bits. O Cloud Bigtable trata um incremento para um valor vazio ou inexistente como se o valor fosse zero. Solicitações ReadModifyWriteRow são atômicas. Elas não serão repetidas se falharem por qualquer motivo.

Para amostras de código que demonstram como anexar um valor em uma célula, consulte Como incrementar um valor existente.

Quando não usar incrementos e anexos

Não envie solicitações ReadModifyWriteRow nas seguintes situações:

  • Se você usa um perfil de aplicativo que tem roteamento de vários clusters.

  • Se você está usando vários perfis de aplicativo de cluster único e enviando gravações que podem entrar em conflito com dados gravados na mesma linha e coluna em outros clusters na instância. Com o roteamento de cluster único, uma solicitação de gravação é enviada para um único cluster e replicada posteriormente.

  • Se você depende do recurso de tentativas inteligentes fornecido pelas bibliotecas de cliente. Incrementos e anexos não podem ser tentados novamente.

  • Se você está gravando grandes quantidades de dados e precisa que as gravações sejam concluídas rapidamente. Uma solicitação que lê e, em seguida, modifica uma linha é mais lenta do que uma solicitação de gravação simples. Consequentemente, esse tipo de gravação muitas vezes não é a melhor abordagem em grande escala. Por exemplo, se você quiser contar algo que será numerado em milhões, como visualizações de página, registre cada visualização como uma gravação simples em vez de incrementar um valor. Em seguida, use um job do Dataflow para agregar os dados.

Gravações condicionais

Se quiser verificar uma linha em relação a uma condição e, dependendo do resultado, gravar dados nessa linha, envie uma solicitação CheckAndMutateRow. Esse tipo de solicitação inclui uma chave de linha e um filtro de linha. Um filtro de linha é um conjunto de regras usadas para verificar o valor dos dados atuais. As mutações só serão confirmadas para colunas específicas na linha quando determinadas condições, verificadas pelo filtro, sejam atendidas. Esse processo de análise e gravação é concluído como uma única ação atômica.

Uma solicitação de filtro deve incluir um ou os dois tipos de mutações abaixo:

  • Mutações verdadeiras, isto é, as mutações que serão aplicadas se o filtro retornar um valor.
  • Mutações falsas, que são aplicadas se o filtro não retornar nada.

Você pode fornecer até 100.000 mutações de cada tipo, verdadeiras e falsas, em uma única gravação, e você deve enviar pelo menos uma. O Cloud Bigtable envia uma resposta quando todas as mutações são concluídas.

Para amostras de código que demonstram como enviar gravações condicionais, consulte Como gravar um valor condicionalmente.

Quando não usar gravações condicionais

Não é possível usar gravações condicionais no seguinte caso de uso:

  • Se você está usando um perfil de aplicativo que tem roteamento de vários clusters.

  • Se você está usando vários perfis de aplicativo de cluster único e enviando gravações que podem entrar em conflito com dados gravados na mesma linha e coluna em outros clusters na instância. Com o roteamento de cluster único, uma solicitação de gravação é enviada para um único cluster e replicada posteriormente.

Gravações em lote

É possível gravar mais de uma linha com uma única chamada usando uma solicitação MutateRows. As solicitações MutateRows contêm um conjunto de até 100.000 entradas que são aplicadas atomicamente. Cada entrada consiste em uma chave de linha e pelo menos uma mutação a ser aplicada à linha. Uma solicitação de gravação em lote pode conter até 100.000 mutações distribuídas por todas as entradas. Por exemplo, uma gravação em lote pode incluir qualquer uma das seguintes permutações:

  • 100.000 entradas com 1 mutação em cada entrada.
  • 1 entrada com 100.000 mutações.
  • 1.000 entradas com 100 mutações cada.

Cada entrada em uma solicitação MutateRows é atômica, mas a solicitação como um todo não é. O Cloud Bigtable envia uma resposta quando todas as entradas foram gravadas.

Para amostras de código que demonstram como enviar gravações em lote, consulte Como executar gravações em lote.

Quando não usar gravações em lote

  • Se você está gravando dados em massa em linhas que não são próximas umas das outras. O Cloud Bigtable armazena dados lexicograficamente por chave de linha, o equivalente binário à ordem alfabética. Por causa disso, quando as chaves de linha em uma solicitação não são semelhantes entre si, o Cloud Bigtable as trata de modo sequencial, e não em paralelo. A capacidade será alta, mas a latência também será alta. Para evitar essa alta latência, use MutateRows quando as chaves de linha forem semelhantes, e o Cloud Bigtable for escrever linhas próximas umas das outras. Use MutateRow, ou gravações simples, para linhas que não são próximas umas das outras.

  • Se você está solicitando várias mutações para a mesma linha. Nesse caso, você observará um desempenho melhor se todas as mutações forem executadas em uma única solicitação de gravação simples. Isso ocorre porque, em uma gravação simples, todas as alterações são confirmadas em uma única ação atômica, mas uma gravação em lote é forçada a serializar mutações para a mesma linha, causando latência.

Consistência no uso da replicação

O tempo necessário para que os dados gravados estejam disponíveis para leituras depende de vários fatores, incluindo o número de clusters em sua instância e o tipo de roteamento usado pelo perfil de aplicativo. Com uma instância de cluster único, os dados podem ser lidos imediatamente, mas se a instância tiver mais de um cluster, o que significa que está usando a replicação, o Cloud Bigtable terá uma consistência eventual. Você pode atingir consistência na leitura das gravações ao rotear solicitações para o mesmo cluster.

Você pode criar e usar um token de consistência após enviar solicitações de gravação. O token verifica a consistência da replicação. Em geral, é melhor criar um token de consistência após o envio de um lote de gravações ou após um determinado intervalo, de uma hora, por exemplo. Em seguida, o token pode ser usado por outro processo, como um módulo que faz uma solicitação de leitura e usa o token para verificar se todos os dados foram replicados antes da tentativa de leitura.

Se você usar um token logo após sua criação, ele pode demorar alguns minutos para verificar a consistência em sua primeira utilização. Essa demora ocorre porque cada cluster verifica todos os outros clusters para garantir que não há mais dados chegando. Depois do uso inicial, ou se você esperar vários minutos para usar o token pela primeira vez, o token será bem-sucedido imediatamente sempre que for usado.

A seguir