O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Aplicação de tipos de dados no Bigtable

O esquema flexível do Bigtable permite armazenar dados de qualquer tipo, como strings, datas, números, documentos JSON ou até mesmo imagens ou PDFs, em uma tabela do Bigtable.

Neste documento, descrevemos quando o Bigtable aplica o tipo, exigindo que você o codifique ou decodifique no código do aplicativo. Para uma lista de tipos de dados do Bigtable, consulte Tipo na documentação de referência da API Data.

Tipos aplicados

O tipo de dados é aplicado aos seguintes dados:

Grupos de colunas agregadas (contadores)
Carimbos de data/hora
Visualizações materializadas contínuas
Chaves de linha estruturadas

Agregações

Para o tipo de dados agregados, a codificação depende do tipo de agregação. Ao criar um grupo de colunas agregadas, é necessário especificar um tipo de agregação.

Esta tabela mostra o tipo de entrada e a codificação de cada tipo de agregação.

Tipo de agregação	Tipo de entrada	Codificação
Soma	Int64	`BigEndianBytes`
Mín.	Int64	`BigEndianBytes`
Máx.	Int64	`BigEndianBytes`
HLL	Bytes	Zetasketch HLL++

Quando você consulta os dados em células agregadas usando SQL, o SQL incorpora automaticamente as informações de tipo.

Quando você lê os dados em células agregadas usando o método ReadRows da API Data, o Bigtable retorna bytes. Portanto, seu aplicativo precisa decodificar os valores usando a codificação que o Bigtable usou para mapear os dados digitados em bytes.

Não é possível converter um grupo de colunas que contém dados não agregados em um grupo de colunas agregadas. As colunas em grupos de colunas agregadas não podem conter células não agregadas, e os grupos de colunas padrão não podem conter células agregadas.

Para mais informações sobre como criar tabelas com grupos de colunas agregadas, consulte Criar uma tabela. Para exemplos de código que mostram como incrementar uma célula agregada com valores codificados, consulte Incrementar um valor.

Carimbos de data/hora

Cada célula do Bigtable tem um carimbo de data/hora Int64 que representa o número de microssegundos desde a época Unix, 1970-01-01 00:00:00 UTC.

Origem do carimbo de data/hora

Cada carimbo de data/hora em uma tabela do Bigtable tem uma origem que indica como ele foi definido. O Bigtable reconhece as seguintes origens de carimbo de data/hora:

Especificado pelo usuário: carimbos de data/hora definidos por você ou por um aplicativo.
Gerados pelo Bigtable: carimbos de data/hora definidos pela biblioteca de cliente que usa o relógio do sistema local do cliente ou gerados pelo servidor que usam o horário atual do servidor.

Granularidade e precisão do carimbo de data/hora

O Bigtable é compatível com os seguintes níveis de granularidade de carimbo de data/hora:

Granularidade de milissegundos (padrão): o carimbo de data/hora precisa ser um valor em microssegundos com precisão de milissegundos no máximo, como 3023483279876000. O Bigtable rejeita carimbos de data/hora especificados pelo usuário com precisão de microssegundos e trunca carimbos de data/hora gerados pelo Bigtable com precisão de microssegundos para precisão de milissegundos.
Granularidade de microssegundos: o carimbo de data/hora pode ter precisão total de microssegundos, como 3023483279876543. O Bigtable aceita carimbos de data/hora especificados pelo usuário e gerados pelo Bigtable com precisão de microssegundos.

Defina a granularidade do carimbo de data/hora ao criar uma tabela.

Limitações de carimbo de data/hora

As seguintes limitações se aplicam a tabelas com granularidade de carimbo de data/hora em microssegundos:

Somente a biblioteca de cliente do Bigtable para Java versão 2.82.0 ou mais recente é compatível com a granularidade de carimbo de data/hora em microssegundos. As solicitações de leitura ou gravação que usam outro cliente falham.
A granularidade de carimbo de data/hora de microssegundos está disponível apenas para instâncias na edição Enterprise Plus.
Não é possível mudar a granularidade do carimbo de data/hora de uma tabela depois que ela é criada.
Não é possível criar visualizações materializadas contínuas em tabelas com granularidade de microssegundos.
Não é possível criar visualizações lógicas em tabelas com granularidade de microssegundos.
Não é possível fazer downgrade de uma instância do Enterprise Plus para o Enterprise se ela contiver tabelas com granularidade de microssegundos. É necessário excluir essas tabelas antes de iniciar um downgrade.
Os backups de tabelas com granularidade de microssegundos só podem ser restaurados para instâncias do Enterprise Plus.

Visualizações materializadas contínuas

As visualizações materializadas contínuas são recursos somente leitura que podem ser lidos usando SQL ou com uma chamada de APIs Data do ReadRows. Os dados em uma visualização materializada são tipados com base na consulta que a define. Para uma visão geral, consulte Visualizações materializadas contínuas.

Quando você usa SQL para consultar uma visualização materializada contínua, o SQL incorpora automaticamente as informações de tipo.

Ao ler uma visualização materializada contínua usando uma solicitação ReadRows da API Data, é necessário saber o tipo de cada coluna e decodificá-lo no código do aplicativo.

Os valores agregados em uma visualização materializada contínua são armazenados usando a codificação descrita na tabela a seguir, com base no tipo de saída da coluna da definição da visualização.

Tipo	Codificação
BOOL	Valor de 1 byte, 1 = verdadeiro, 0 = falso
BYTES	Sem codificação
INT64 (ou INT, SMALLINT, INTEGER, BIGINT, TINYINT, BYTEINT)	Big-endian de 64 bits
FLOAT64	IEEE 754 de 64 bits, exceto NaN e +/-inf
STRING	UTF-8
TIME/TIMESTAMP	Número inteiro de 64 bits que representa o número de microssegundos desde a época Unix (consistente com o GoogleSQL)

Para mais informações, consulte Codificação na referência da API Data.

Chaves de linha estruturadas

As chaves de linha estruturadas permitem acessar seus dados usando chaves de várias colunas, semelhantes às chaves compostas em bancos de dados relacionais.

O tipo e a codificação das chaves de linha estruturadas são definidos por um esquema de chave de linha que pode ser adicionado a uma tabela do Bigtable. Os dados estruturados da chave de linha são armazenados como bytes, mas o GoogleSQL para Bigtable usa automaticamente o tipo e a codificação definidos no esquema da chave de linha quando você executa uma consulta SQL na tabela.

Não é possível usar um esquema de chave de linha para consultar uma tabela com uma solicitação ReadRows. Uma visualização materializada contínua tem um esquema de chave de linha por padrão. Para mais informações sobre chaves de linha estruturadas, consulte Gerenciar chave de linha linha.

Tipos não aplicados

Se nenhuma informação de tipo for fornecida, o Bigtable vai tratar cada célula como bytes com uma codificação desconhecida.

Ao consultar grupos de colunas criados sem aplicação de tipo, é necessário fornecer informações de tipo no momento da leitura para garantir que os dados sejam lidos corretamente. Isso é relevante para funções de banco de dados cujo comportamento depende do tipo de dados. O GoogleSQL para Bigtable oferece funções CAST para fazer conversões de tipo no momento da consulta. Essas funções convertem de bytes para os tipos que várias funções esperam.

Embora o Bigtable não aplique tipos, algumas operações assumem um tipo de dados. Saber disso ajuda a garantir que os dados sejam gravados de uma maneira que possa ser processada no banco de dados. Confira alguns exemplos:

Os incrementos que usam ReadModifyWriteRow pressupõem que a célula contém um número inteiro assinado big-endian de 64 bits.
A função TO_VECTOR64 em SQL espera que a célula contenha uma matriz de bytes que seja uma concatenação dos bytes big-endian de números de ponto flutuante de 64 bits.
A função TO_VECTOR32 em SQL espera que a célula contenha uma matriz de bytes que seja uma concatenação dos bytes big-endian de números de ponto flutuante de 32 bits.