Application des types de données dans Bigtable

Remarque : Cette page inclut des fonctionnalités qui ne sont disponibles que dans l'édition Enterprise Plus. Pour en savoir plus, consultez la présentation des éditions.

Le schéma flexible de Bigtable vous permet de stocker des données de tout type (chaînes, dates, nombres, documents JSON, ou même 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é pour les données suivantes :

• Familles de colonnes d'agrégation (compteurs)
• Codes temporels
• Vues matérialisées continues
• Clés de ligne structuré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 d'agrégation, 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 de cellules d'agrégation à l'aide de SQL, SQL intègre automatiquement les informations de type.

Lorsque vous lisez les données dans des cellules d'agrégation à 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 utilisé par Bigtable 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 une famille de colonnes agrégées. Les colonnes des familles de colonnes d'agrégation ne peuvent pas contenir de cellules non agrégées, et les familles de colonnes standards ne peuvent pas contenir de cellules d'agrégation.

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

Codes temporels

Chaque cellule Bigtable possède un code temporel Int64 qui représente le nombre de microsecondes écoulées depuis l'epoch Unix, 1970-01-01 00:00:00 UTC.

Origine du code temporel

Chaque code temporel d'une table Bigtable a une origine qui indique comment il a été défini. Bigtable reconnaît les origines de code temporel suivantes :

• Spécifié par l'utilisateur : codes temporels définis par vous ou par une application.
• Générés par Bigtable : codes temporels définis par la bibliothèque cliente qui utilise l'horloge système locale du client ou générés par le serveur qui utilise l'heure actuelle du serveur.

Précision temporelle

Bigtable accepte les niveaux de précision de code temporel suivants :

• Précision à la milliseconde (par défaut) : le code temporel doit être exprimé en microsecondes avec une précision maximale de l'ordre de la milliseconde (par exemple, 3023483279876000). Bigtable rejette les codes temporels spécifiés par l'utilisateur avec une précision de l'ordre de la microseconde et tronque les codes temporels générés par Bigtable avec une précision de l'ordre de la microseconde à la milliseconde.
• Précision à la microseconde : le code temporel peut avoir une précision à la microseconde, par exemple 3023483279876543. Bigtable accepte les codes temporels spécifiés par l'utilisateur et générés par Bigtable avec une précision à la microseconde.

Vous définissez la précision du code temporel lorsque vous créez une table.

Limites d'horodatage

Les limites suivantes s'appliquent aux tables avec une précision d'horodatage en microsecondes :

• Seule la bibliothèque cliente Bigtable pour Java version 2.82.0 ou ultérieure est compatible avec la précision des codes temporels en microsecondes. Les requêtes de lecture ou d'écriture qui utilisent un autre client échouent.
• La précision des codes temporels à la microseconde n'est disponible que pour les instances de l'édition Enterprise Plus.
• Vous ne pouvez pas modifier la précision du code temporel d'une table après sa création.
• Vous ne pouvez pas créer de vues matérialisées continues sur des tables avec une précision en microsecondes.
• Vous ne pouvez pas créer de vues logiques sur des tables avec une précision en microsecondes.
• Vous ne pouvez pas passer d'une instance Enterprise Plus à une instance Enterprise si elle contient des tables avec une précision à la microseconde. Vous devez supprimer ces tables avant de lancer un passage à une version antérieure.
• Les sauvegardes de tables avec une précision à la microseconde ne peuvent être restaurées que sur des instances Enterprise Plus.

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 de données 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 à partir 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 +/-inf
STRING	UTF-8
TIME/TIMESTAMP	Entier 64 bits représentant le nombre de microsecondes écoulées depuis l'epoch Unix (cohérent avec GoogleSQL)

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

Clés de ligne structurées

Aperçu

Ce produit ou cette fonctionnalité sont soumis aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une compatibilité limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

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 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 possible. 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 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 des fonctions CAST pour effectuer des conversions de types 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 des exemples :

• Les incréments utilisant ReadModifyWriteRow supposent que la cellule contient un entier signé big-endian de 64 bits.
• La fonction TO_VECTOR64 en SQL attend que la cellule contienne un tableau d'octets qui est une concaténation des octets big-endian de nombres à virgule flottante de 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 de 32 bits.

Étapes suivantes

• Lecture
• Présentation de GoogleSQL pour Bigtable