Application des types de données dans Bigtable

Le schéma flexible de Bigtable vous permet de stocker des données de n'importe quel type (chaînes, dates, nombres, documents JSON, images ou PDF, par exemple) dans une table Bigtable.

Ce document décrit les cas où Bigtable applique un type, ce qui vous oblige à l'encoder ou à le décoder dans le code de votre application. Pour obtenir la liste des types de données Bigtable, consultez la section Type dans la documentation de référence de l'API Data.

Types appliqués

Le type de données est appliqué aux données suivantes :

Familles de colonnes agrégées (compteurs)
Horodatages
Vues matérialisées

Agrégations

Pour le type de données aggregate, l'encodage dépend du type d'agrégation. Lorsque vous créez une famille de colonnes agrégée, vous devez spécifier un type d'agrégation.

Ce tableau indique le type d'entrée et l'encodage pour chaque type d'agrégation.

Type d'agrégation	Type d'entrée	Encodage
Somme	Int64	`BigEndianBytes`
Min	Int64	`BigEndianBytes`
Max	Int64	`BigEndianBytes`
HLL	Octets	Zetasketch HLL++

Lorsque vous interrogez les données dans des cellules agrégées à l'aide de SQL, SQL intègre automatiquement les informations de type.

Lorsque vous lisez les données dans des cellules agrégées à l'aide de la méthode ReadRows de l'API Data, Bigtable renvoie des octets. Votre application doit donc décoder les valeurs à l'aide de l'encodage que Bigtable a utilisé pour mapper les données typées en octets.

Vous ne pouvez pas convertir une famille de colonnes contenant des données non agrégées en famille de colonnes agrégée. Les colonnes des familles de colonnes agrégées ne peuvent pas contenir de cellules non agrégées, et les familles de colonnes standards ne peuvent pas contenir de cellules agrégées.

Pour en savoir plus sur la création de tables avec des familles de colonnes agrégées, consultez la section Créer une table. Pour obtenir des exemples de code montrant comment incrémenter une cellule agrégée avec des valeurs encodées, consultez la section Incrémenter une valeur.

Horodatages

Chaque cellule Bigtable comporte un horodatage Int64 qui doit être une valeur en microsecondes avec une précision maximale de l'ordre de la milliseconde. Bigtable rejette un horodatage avec une précision en microsecondes, tel que 3023483279876543. Dans cet exemple, la valeur d'horodatage acceptable est 3023483279876000. Un horodatage correspond à le nombre de microsecondes écoulées depuis l'époque Unix, 1970-01-01 00:00:00 UTC.

Vues matérialisées continues

Les vues matérialisées continues sont des ressources en lecture seule que vous pouvez lire à l'aide de SQL ou d'un appel d'API Data ReadRows. Les données d'une vue matérialisée sont typées en fonction de la requête qui les définit. Pour obtenir une présentation, consultez la section Vues matérialisées continues.

Lorsque vous utilisez SQL pour interroger une vue matérialisée continue, SQL intègre automatiquement les informations de type.

Lorsque vous lisez une vue matérialisée continue à l'aide d'une requête de l'API Data ReadRows, vous devez connaître le type de chaque colonne et le décoder dans le code de votre application.

Les valeurs agrégées d'une vue matérialisée continue sont stockées à l'aide de l'encodage décrit dans le tableau suivant, en fonction du type de sortie de la colonne de la définition de la vue.

Type	Encodage
BOOL	Valeur de 1 octet, 1 = true, 0 = false
BYTES	Aucun encodage
INT64 (ou INT, SMALLINT, INTEGER, BIGINT, TINYINT, BYTEINT)	Big-endian 64 bits
FLOAT64	IEEE 754 64 bits, à l'exclusion de NaN et de +/-inf
STRING	UTF-8
TIME/TIMESTAMP	Entier 64 bits représentant le nombre de microsecondes écoulées depuis l'époque Unix (conforme à GoogleSQL)

Pour en savoir plus, consultez la section Encodage dans la documentation de référence de l'API Data.

Clés de ligne structurées

Les clés de ligne structurées vous permettent d'accéder à vos données à l'aide de clés à plusieurs colonnes, semblables aux clés composites des bases de données relationnelles.

Le type et l'encodage des clés de ligne structurées sont définis par un schéma de clé de ligne que vous pouvez éventuellement ajouter à une table Bigtable. Les données de clé de ligne structurées sont stockées sous forme d'octets, mais GoogleSQL pour Bigtable utilise automatiquement le type et l'encodage définis dans le schéma de clé de ligne lorsque vous exécutez une requête SQL sur la table.

L'utilisation d'un schéma de clé de ligne pour interroger une table avec une requête ReadRows n'est pas acceptée. Une vue matérialisée continue comporte un schéma de clé de ligne par défaut. Pour en savoir plus sur les clés de ligne structurées, consultez la section Gérer les schémas de clé de ligne.

Types non appliqués

Si aucune information de type n'est fournie, Bigtable traite chaque cellule comme des octets avec un encodage inconnu.

Lorsque vous interrogez des familles de colonnes créées sans application de type, vous devez fournir des informations de type au moment de la lecture pour vous assurer que les données sont lues correctement. Cela est pertinent pour les fonctions de base de données dont le comportement dépend du type de données. GoogleSQL pour Bigtable propose CAST des fonctions pour effectuer des conversions de type au moment de la requête. Ces fonctions convertissent les octets en types attendus par différentes fonctions.

Bien que Bigtable n'applique pas de types, certaines opérations supposent un type de données. Cela vous permet de vous assurer que vos données sont écrites de manière à pouvoir être traitées dans la base de données. Voici quelques exemples :

Les incréments utilisant ReadModifyWriteRow supposent que la cellule contient un entier signé big-endian 64 bits.
La fonction TO_VECTOR64 en SQL s'attend à ce que la cellule contienne un tableau d'octets qui est une concaténation des octets big-endian de nombres à virgule flottante 64 bits.
La fonction TO_VECTOR32 en SQL s'attend à ce que la cellule contienne un tableau d'octets qui est une concaténation des octets big-endian de nombres à virgule flottante 32 bits.