Escreve

Esta página apresenta uma lista dos tipos de pedidos de gravação que pode enviar para o Bigtable e descreve quando os deve usar e quando não os deve usar. Para ver informações sobre a agregação de dados numa célula no momento da gravação, consulte o artigo Agregue valores no momento da gravação.

A Bigtable Data API e as bibliotecas de clientes permitem-lhe escrever dados nas suas tabelas de forma programática. O Bigtable envia uma resposta ou uma confirmação para cada gravação.

Cada biblioteca cliente oferece a capacidade de enviar os seguintes tipos de pedidos de escrita:

  • Escritas simples
  • Incrementos e anexos
  • Escritas condicionais
  • Escritas em lote

As bibliotecas de cliente do Bigtable têm uma funcionalidade de novas tentativas inteligentes incorporada para escritas simples e em lote, o que significa que processam sem problemas a indisponibilidade temporária. Por exemplo, se a sua aplicação tentar escrever dados e encontrar uma indisponibilidade temporária ou um problema de rede, tenta novamente automaticamente até que a escrita seja confirmada ou o prazo do pedido seja atingido. Esta resiliência funciona com instâncias de cluster único e replicadas, com o encaminhamento de cluster único ou o encaminhamento de vários clusters.

Para operações de escrita em lote e por streaming, pode usar o conetor Bigtable Beam. Para mais informações, consulte o artigo Gravações em lote.

Para saber mais sobre os limites aplicáveis a pedidos de gravação, consulte o artigo Quotas e limites.

Para ver exemplos da biblioteca cliente do Cloud Bigtable de pedidos de gravação descritos nesta página, consulte Exemplos de gravação.

Tipos de gravações e quando os usar

Todos os pedidos de gravação incluem os seguintes componentes básicos:

  • O nome da tabela na qual escrever.
  • Um ID do perfil da app, que indica ao Bigtable como encaminhar o tráfego.
  • Uma ou mais mutações. Uma mutação é composta pelos seguintes elementos:
    • Nome da família de colunas
    • Qualificador da coluna
    • Indicação de tempo
    • Valor que está a escrever na tabela

A data/hora de uma mutação tem um valor predefinido da data e hora atuais, medido como o tempo decorrido desde a época Unix, 00:00:00 UTC a 1 de janeiro de 1970.

Uma data/hora que envia para o Bigtable tem de ser um valor de microssegundos com, no máximo, uma precisão de milissegundos. Uma indicação de tempo com precisão de microssegundos, como 3023483279876543, é rejeitada. Neste exemplo, o valor de data/hora aceitável é 3023483279876000.

Todas as mutações num pedido de gravação único têm a mesma data/hora, a menos que as substitua. Pode definir a data/hora de todas as mutações num pedido de gravação para que seja igual ou diferente entre si.

Escritas simples

Pode escrever uma única linha no Bigtable com um pedido MutateRow que inclua o nome da tabela, o ID do perfil da app que deve ser usado, uma chave de linha e até 100 000 mutações para essa linha. Uma escrita de linha única é atómica. Use este tipo de gravação quando estiver a fazer várias mutações numa única linha.

Para ver exemplos de código que demonstram como enviar pedidos de gravação simples, consulte o artigo Executar uma gravação simples.

Quando não usar escritas simples

As escritas simples não são a melhor forma de escrever dados para os seguintes exemplos de utilização:

  • Está a escrever um lote de dados que vai ter chaves de linhas contíguas. Neste caso, deve usar gravações em lote em vez de gravações simples consecutivas, porque um lote contíguo pode ser aplicado numa única chamada de back-end.

  • Quer um débito elevado (linhas por segundo ou bytes por segundo) e não precisa de baixa latência. Neste caso, as gravações em lote são mais rápidas.

Atualizações incrementais

O Bigtable permite-lhe criar células com um tipo de dados de agregação. As células agregadas são otimizadas para quando quer alterar os valores nas células da tabela existentes, agregando os valores das células à medida que os dados são escritos. Estão disponíveis os seguintes tipos de agregação:

  • Soma: incrementa um contador ou mantém uma soma contínua.
  • Mínimo: envia um número inteiro para uma célula e o Bigtable mantém o menor dos dois valores.
  • Máximo: envie um número inteiro para uma célula e o Bigtable mantém o maior dos dois valores.
  • HyperLogLog (HLL): envie um valor que é adicionado a um conjunto probabilístico de todos os valores adicionados à célula.

Os pedidos de atualização de células agregadas são enviados com um pedido MutateRow e um tipo de mutação de AddToCell, MergeToCell ou um dos tipos de mutação de eliminação.

Anexa

Para anexar dados a um valor existente, pode usar um pedido ReadModifyWriteRow. Este pedido inclui o nome da tabela, o ID do perfil da app que deve ser usado, uma chave de linha e um conjunto de regras a usar ao escrever os dados. Cada regra inclui o nome da família de colunas, o qualificador de coluna e um valor de anexação ou um valor de incremento.

As regras são aplicadas por ordem. Por exemplo, se o seu pedido incluir um pedido para anexar o valor de uma coluna que contém o valor some com a string thing e uma regra posterior no mesmo pedido anexar essa mesma coluna com body, o valor é modificado duas vezes numa única gravação atómica, e o valor resultante é somethingbody. A regra posterior não substitui a regra anterior.

Também pode incrementar um número inteiro com uma chamada ReadModifyWriteRow, mas recomendamos que use células agregadas e AddToCell ou MergeToCell. Um valor só pode ser incrementado através de ReadModifyWrite se estiver codificado como um inteiro assinado de 64 bits em formato big-endian. O Bigtable trata um incremento de um valor vazio ou inexistente como se o valor fosse zero.

ReadModifyWriteRow pedidos são atómicos. Não são repetidas se falharem por qualquer motivo.

Quando não usar ReadModifyWriteRow

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

  • O seu exemplo de utilização pode ser processado através do envio de um pedido MutateRow com uma mutação AddToCell. Para mais informações, consulte o artigo Agregação de valores no momento da escrita.

  • Está a usar um perfil de app com encaminhamento de vários clusters.

  • Está a usar vários perfis de apps de cluster único e a enviar escritas que podem entrar em conflito com os dados escritos na mesma linha e coluna noutros clusters na instância. Com o encaminhamento de cluster único, um pedido de gravação é enviado para um único cluster e, em seguida, replicado.

  • Confia na funcionalidade de novas tentativas inteligentes fornecida pelas bibliotecas cliente. Não é possível tentar novamente um pedido ReadModifyWriteRow.

  • Está a escrever grandes quantidades de dados e precisa que as escritas sejam concluídas rapidamente. Um pedido que lê e, em seguida, modifica uma linha é mais lento do que um pedido de gravação simples. Como resultado, este tipo de gravação não é, muitas vezes, a melhor abordagem em grande escala.

    Por exemplo, se quiser contar algo que vai atingir milhões, como visualizações de páginas, deve MutateRow com uma AddToCell mutação para atualizar as contagens no momento da gravação.

Escritas condicionais

Se quiser verificar uma condição numa linha e, em seguida, consoante o resultado, escrever dados nessa linha, envie um pedido CheckAndMutateRow. Este tipo de pedido inclui uma chave de linha e um filtro de linha. Um filtro de linhas é um conjunto de regras que usa para verificar o valor dos dados existentes. As mutações são, em seguida, confirmadas em colunas específicas na linha apenas quando determinadas condições, verificadas pelo filtro, são cumpridas. Este processo de verificação e, em seguida, de escrita é concluído como uma ação única e atómica.

Um pedido de filtro tem de incluir um ou ambos os seguintes tipos de mutações:

  • Mutações verdadeiras ou as mutações a aplicar se o filtro devolver um valor.
  • Mutações falsas, que são aplicadas se o filtro não produzir resultados.

Pode fornecer até 100 000 de cada tipo de mutação (verdadeira e falsa) numa única gravação e tem de enviar,pelo menos, uma. O Bigtable envia uma resposta quando todas as mutações estão concluídas.

Para ver exemplos de código que demonstram como enviar gravações condicionais, consulte o artigo Gravar um valor condicionalmente.

Quando não usar escritas condicionais

Não pode usar escritas condicionais para o seguinte exemplo de utilização:

  • Está a usar um perfil de app que tem encaminhamento de vários clusters.

  • Está a usar vários perfis de apps de cluster único e a enviar escritas que podem entrar em conflito com os dados escritos na mesma linha e coluna noutros clusters na instância. Com o encaminhamento de cluster único, um pedido de gravação é enviado para um único cluster e, em seguida, replicado.

  • Está a escrever grandes quantidades de dados e precisa que as escritas sejam concluídas rapidamente. Semelhante a ReadModifyWriteRow, os pedidos de gravação condicional têm de ler linhas antes de as modificar, pelo que os pedidos CheckAndModifyRow são mais lentos do que os pedidos de gravação simples. Como resultado, este tipo de gravação não é, muitas vezes, a melhor abordagem em grande escala.

Escritas em lote

Pode escrever mais do que uma linha com uma única chamada usando um pedido MutateRows. Os pedidos MutateRows contêm um conjunto de até 100 000 entradas que são aplicadas atomicamente. Cada entrada consiste numa chave de linha e, pelo menos, uma mutação a aplicar à linha. Um pedido 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.
  • 1000 entradas com 100 mutações cada.

Cada entrada num pedido MutateRows é atómica, mas o pedido como um todo não o é. Se necessário, o Bigtable tenta novamente todas as entradas no lote que não forem bem-sucedidas, até que todas as gravações sejam bem-sucedidas ou o prazo do pedido seja atingido. Em seguida, devolve uma resposta que identifica cada gravação no lote e se a gravação foi bem-sucedida ou não.

Para ver exemplos de código que demonstram como enviar gravações em lote, consulte o artigo Realizar gravações em lote.

Quando não usar gravações em lote

  • Está a escrever dados em massa em linhas que não estão próximas umas das outras. O Bigtable armazena dados lexicograficamente por chave de linha, o equivalente binário da ordem alfabética. Por este motivo, quando as chaves de linhas num pedido não são semelhantes entre si, o Bigtable processa-as sequencialmente, em vez de em paralelo. O débito vai ser elevado, mas a latência também vai ser elevada. Para evitar essa latência elevada, use MutateRows quando as chaves das linhas forem semelhantes e o Bigtable escrever linhas que estejam próximas umas das outras. Use MutateRow ou escritas simples para linhas que não estejam próximas umas das outras.

  • Está a pedir várias mutações à mesma linha. Neste caso, vai observar um melhor desempenho se executar todas as mutações num único pedido de gravação simples. Isto deve-se ao facto de, numa gravação simples, todas as alterações serem confirmadas numa única ação atómica, mas uma gravação em lote ser forçada a serializar mutações na mesma linha, o que causa latência.

Controlo do fluxo de gravação em lote

Se enviar as suas gravações em lote (incluindo eliminações) através de uma das seguintes opções, pode ativar o controlo de fluxo de gravação em lote no seu código.

Quando o controlo do fluxo de gravação em lote está ativado para uma tarefa do Dataflow, o Bigtable faz automaticamente o seguinte :

  • Limita a taxa de tráfego para evitar a sobrecarga do cluster do Bigtable
  • Garante que o cluster está sob carga suficiente para acionar o redimensionamento automático do Bigtable (se ativado), para que sejam adicionados automaticamente mais nós ao cluster quando necessário

Estas ações combinadas evitam a sobrecarga do cluster e a falha da tarefa, e não precisa de dimensionar manualmente o cluster antecipadamente para executar a gravação em lote. Quando o controlo de fluxo está ativado, o dimensionamento do cluster ocorre durante a tarefa do Dataflow e não antes. Por isso, a tarefa pode demorar mais tempo a terminar do que se dimensionar o cluster manualmente.

Tem de usar um perfil de app configurado para o encaminhamento de cluster único. A ativação da escala automática do Bigtable para o cluster de destino não é um requisito, mas a escala automática permite-lhe tirar total partido do controlo do fluxo de escrita em lote. Pode usar o ajuste de escala automático do Dataflow da mesma forma que o faria com qualquer outro trabalho.

Para saber mais sobre o ajuste de escala automático do Bigtable, consulte o artigo Ajuste de escala automático. Para compreender as políticas de encaminhamento de perfis de apps, consulte o artigo Vista geral dos perfis de apps.

Para ver exemplos de código, consulte o artigo Ative o controlo do fluxo de gravação em lote.

Escreva dados numa vista autorizada

Para escrever dados numa vista autorizada, tem de usar uma das seguintes opções:

  • CLI gcloud
  • Cliente do Bigtable para Java

As outras bibliotecas de cliente do Bigtable ainda não suportam o acesso à vista autorizado.

Quando escreve dados numa visualização de propriedade autorizada, fornece o ID da visualização de propriedade autorizada, além do ID da tabela.

Todas as escritas numa vista autorizada são aplicadas diretamente à tabela subjacente.

Limitações da definição de vistas autorizadas

Numa visualização autorizada, as linhas ou as colunas nas quais pode escrever dados estão limitadas pela definição da visualização autorizada. Por outras palavras, só pode escrever em linhas e colunas que cumpram os mesmos critérios especificados para a vista autorizada.

Por exemplo, se a vista autorizada for definida pelo prefixo da chave da linha examplepetstore1, não pode escrever dados com uma chave da linha examplepetstore2. O início do valor da chave da linha tem de incluir a string examplepetstore1 completa.

Da mesma forma, se a vista autorizada for definida pelo prefixo do qualificador de coluna order-phone, pode escrever dados usando o qualificador de coluna order-phone123, mas não pode usar o qualificador de coluna order-tablet.

O seu pedido de gravação também não pode fazer referência a dados que estejam fora da vista autorizada, como quando está a verificar um valor num pedido de gravação condicional.

Para qualquer pedido que escreva ou faça referência a dados fora da vista autorizada, é devolvida uma mensagem de erro PERMISSION_DENIED.

Replicação

Quando um cluster de uma instância replicada recebe uma gravação, essa gravação é replicada imediatamente para os outros clusters na instância.

Atomicidade

Cada pedido MutateRows que enviar a uma instância replicada é confirmado como uma única ação atómica no cluster para o qual o pedido é encaminhado. Quando a gravação é replicada para os outros clusters na instância, esses clusters também recebem a gravação como uma operação atómica. Os clusters não recebem mutações parciais. Uma mutação tem êxito ou falha atomicamente para todas as células que modifica.

Consistência

O tempo necessário para que os dados que escreve estejam disponíveis para leituras depende de vários fatores, incluindo o número de clusters na sua instância e o tipo de encaminhamento que o perfil da app usa.

Com uma instância de cluster único, os dados podem ser lidos imediatamente, mas se uma instância tiver mais do que um cluster, o que significa que está a usar a replicação, o Bigtable é eventualmente consistente. Pode alcançar a consistência de leitura/escrita encaminhando os pedidos para o mesmo cluster.

Pode criar e usar um token de consistência e chamar CheckConsistency no modo StandardReadRemoteWrites depois de enviar pedidos de gravação. O token verifica a consistência da replicação. Em geral, cria um token de consistência após o envio de um lote de gravações ou após um determinado intervalo, como uma hora. Em seguida, pode entregar o token para ser usado por outro processo, como um módulo que faz um pedido de leitura, que usa o token para verificar se todos os dados foram replicados antes de tentar ler.

Se usar um token imediatamente após a criação, a verificação da consistência pode demorar alguns minutos na primeira vez que o usar. Este atraso deve-se ao facto de cada cluster verificar todos os outros clusters para garantir que não estão a chegar mais dados. Após a utilização inicial ou se aguardar vários minutos para utilizar o token pela primeira vez, o token tem êxito imediatamente sempre que é utilizado.

Resolução de conflitos

Cada valor de célula numa tabela do Bigtable é identificado exclusivamente pela tupla de quatro elementos (chave da linha, família de colunas, qualificador da coluna e data/hora). Consulte o artigo Modelo de armazenamento do Bigtable para ver mais detalhes sobre estes identificadores. No caso de serem enviadas duas escritas com a mesma tupla de quatro elementos exata para dois clusters diferentes, o Bigtable resolve automaticamente o conflito através de um algoritmo interno last write wins com base na hora do servidor. A implementação "last write wins" do Bigtable é determinística e, quando a replicação é atualizada, todos os clusters têm o mesmo valor para a tupla de quatro elementos.

O que se segue?