Application des types de données dans Bigtable

Le schéma flexible de Bigtable vous permet de stocker des données de tout type (chaînes, dates, nombres, documents JSON, voire images ou PDF) 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 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 :

  • Agréger les familles de colonnes (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égat 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ées. 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 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 Incrémenter une valeur.

Horodatages

Chaque cellule Bigtable dispose d'un code temporel Int64 qui doit être exprimé en microsecondes avec une précision maximale de l'ordre de la milliseconde. Bigtable refuse les codes temporels avec une précision de l'ordre de la microseconde, comme 3023483279876543. Dans cet exemple, la valeur de code temporel acceptable est 3023483279876000. Un code temporel correspond au 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 la définit. Pour en savoir plus, consultez 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 ReadRows de l'API Data, 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 = vrai, 0 = faux
BYTES Aucun encodage
INT64 (ou INT, SMALLINT, INTEGER, BIGINT, TINYINT, BYTEINT) 64 bits big-endian
FLOAT64 IEEE 754 64 bits, à l'exclusion de NaN et de +/-inf
STRING UTF-8
TIME/TIMESTAMP Nombre entier de 64 bits représentant le nombre de microsecondes écoulées depuis l'époque Unix (compatible avec GoogleSQL)
Pour en savoir plus, consultez 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 multicolonnes, 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 structurées de clé de ligne 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 prise en charge. Une vue matérialisée continue possède un schéma de clé de ligne par défaut. Pour en savoir plus sur les clés de ligne structurées, consultez Gérer les schémas de clés de ligne.

Types non appliqués

Si aucune information sur le 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 sur le 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 des fonctions CAST pour effectuer des conversions de type au moment de l'exécution des requêtes. Ces fonctions convertissent les octets dans les types attendus par les 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é de 64 bits en big-endian.
  • 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 des nombres à virgule flottante de 64 bits.
  • La fonction TO_VECTOR32 en SQL attend que la cellule contienne un tableau d'octets qui est une concaténation des octets big-endian de nombres à virgule flottante 32 bits.

Étapes suivantes