Conception de schéma pour les données de séries temporelles

Cette page décrit des modèles de conception de schéma permettant de stocker des données de séries temporelles Bigtable. Cette page s'appuie sur celle intitulée Conception de votre schéma et suppose que vous maîtrisez les concepts et les recommandations qui y figurent.

Une série temporelle est un ensemble de données constitué de mesures et des heures auxquelles ces mesures sont enregistrées. Voici des exemples de séries temporelles :

  • L'évolution de l'utilisation de la mémoire sur votre ordinateur
  • L'évolution des températures des prévisions météorologiques
  • Les cours de la bourse sur une période donnée

Un schéma efficace entraîne des performances et une évolutivité excellentes, tandis qu'un mauvais schéma peut conduire à un système peu performant. Cependant, le schéma unique parfait qui convient le mieux à tous les cas d'utilisation n'existe pas.

Les modèles décrits sur cette page constituent un point de départ. Votre ensemble de données unique et les requêtes que vous prévoyez d'utiliser sont les éléments les plus importants à prendre en compte lorsque vous concevez un schéma pour vos données de séries temporelles.

Les modèles de conception de base permettant de stocker des données de séries temporelles dans Bigtable sont les suivants :

Données pour les exemples

Pour illustrer les différences entre les modèles, les exemples de cette page partent du principe que vous stockez des données pour une application qui enregistre les mesures effectuées par des ballons-sondes toutes les minutes. Le terme event désigne une requête unique qui remplit une ou plusieurs cellules en même temps. Les ID de zone géographique correspondent aux régions Google Cloud.

Mesure Exemple
  1. Les horodatages de cette page sont au format "tAAAA-MM-JJ-HHMM" pour une question de lisibilité. Dans une table en production, les horodatages sont généralement exprimés sous forme du nombre de microsecondes écoulées depuis le 01/01/1970 à 00:00:00 UTC, par exemple "1616264288050807".
Pression (pascals) 94587
Température (Celsius) 9,5
Humidité (pourcentage) 65
Altitude (mètres) 601
Données connexes Exemple
ID d'infobulle 3698
Emplacement asia-southeast1
Horodatage1 t2021-03-05-1204

Buckets de temps

Dans un modèle de bucket temporel, chaque ligne de votre table représente un "bucket" temporel, par exemple une heure, un jour ou un mois. Une clé de ligne comprend un identifiant non-horodaté, tel que week49, pour la période enregistrée sur la ligne, ainsi que d'autres données d'identification.

La taille du bucket que vous utilisez (par exemple, minute, heure ou jour) dépend des requêtes que vous prévoyez d'utiliser et des limites de taille des données Bigtable. Par exemple, si les lignes contenant une heure de données sont plus grandes que la taille maximale recommandée par ligne de 100 Mo, puis les lignes qui représentent une demi-heure ou d'une minute sont probablement un meilleur choix.

Les avantages associés aux schémas de buckets temporels sont les suivants :

  • Vous obtiendrez de meilleures performances. Par exemple, si vous stockez 100 mesures, Bigtable les écrit et les lit plus rapidement si elles se trouvent sur une ligne, plutôt que sur 100 lignes.

  • Les données stockées de cette manière sont compressées plus efficacement que les données des tables longues et étroites.

Les inconvénients sont les suivants :

  • Les modèles de conception de schéma des buckets de temps sont plus complexes que ceux de l'horodatage unique et peuvent être plus longs et fastidieux à développer.

Ajouter des colonnes pour les nouveaux événements

Dans ce modèle de bucket temporel, vous écrivez une nouvelle colonne sur une ligne pour chaque événement, en stockant les données dans le qualificatif de colonne plutôt qu'en tant que valeur de cellule. Cela signifie que pour chaque cellule, vous envoyez la famille de colonnes, le qualificatif de colonne et l'horodatage, mais aucune valeur.

En appliquant ce modèle aux données de l'exemple des ballons-sondes, chaque ligne contient toutes les mesures d'une seule métrique, telle que pressure, pour un seul ballon-sonde, sur une semaine. Chaque clé de ligne contient l'emplacement, l'identifiant du ballon-sonde, la métrique que vous enregistrez sur la ligne et un numéro de semaine. Chaque fois qu'un ballon-sonde communique ses données pour une métrique, vous ajoutez une nouvelle colonne à la ligne. Le qualificatif de colonne contient la mesure et la pression en Pascal pour la minute identifiée par l'horodatage de la cellule.

Dans cet exemple, au bout de trois minutes, une ligne peut se présenter sous la forme suivante :

Clé de ligne 94558 94122 95992
us-west2#3698#pressure#week1 « » (t2021-03-05-1200) « » (t2021-03-05-1201) « » (t2021-03-05-1202)

Voici quelques exemples d'utilisation de ce modèle :

Ajouter des cellules pour les nouveaux événements

Dans ce modèle de bucket temporel, vous ajoutez de nouvelles cellules aux colonnes existantes lorsque vous écrivez un nouvel événement. Ce modèle vous permet de bénéficier de la capacité de Bigtable à stocker plusieurs cellules horodatées dans une ligne et une colonne données. Il est important de spécifier des règles de récupération de mémoire lors de l'utilisation de ce modèle.

Si l'on prend l'exemple des données des ballons-sondes, chaque ligne contient toutes les mesures d'un seul ballon-sonde sur une semaine. Le préfixe de la clé de ligne est un identifiant pour la semaine, de sorte que vous pouvez lire les données d'une semaine entière pour plusieurs ballons-sondes en une seule requête. Les autres segments clés de la ligne sont le site d'exploitation du ballon-sonde et son numéro d'identification. La table comporte une famille de colonnes, measurements, qui contient une colonne pour chaque type de mesure : pressure, temperature, humidity et altitude.

Chaque fois qu'un ballon-sonde communique ses mesures, l'application écrit de nouvelles valeurs sur la ligne qui contient les données de la semaine en cours pour ce ballon-sonde, en écrivant des cellules horodatées supplémentaires dans chaque colonne. À la fin de la semaine, chaque colonne de chaque ligne comporte une mesure pour chaque minute de la semaine, soit 10 080 cellules (si votre règle de récupération de mémoire l'autorise).

Chaque colonne de chaque ligne contient une mesure pour chaque minute de la semaine. Dans le cas présent, au bout de trois minutes, les deux premières colonnes d'une ligne peuvent se présenter sous la forme suivante :

Clé de ligne pression temp
asia-south2#3698#week1 94558 (t2021-03-05-1200) 9,5 (t2021-03-05-1200)
94122 (t2021-03-05-1201) 9,4 (t2021-03-05-1201)
95992 (t2021-03-05-1202) 9,2 (t2021-03-05-1202)

Voici quelques exemples d'utilisation de ce modèle :

  • Vous voulez pouvoir mesurer les changements de mesure au fil du temps.

Lignes à horodatage unique

Dans ce modèle, vous créez une ligne pour chaque nouvel événement ou mesure au lieu d'ajouter des cellules aux colonnes des lignes existantes. Le suffixe de la clé de ligne correspond à la valeur d'horodatage. Les tables qui suivent ce modèle ont tendance à être hautes et étroites, et chaque colonne d'une ligne ne contient qu'une seule cellule.

Sérialisée à un horodatage unique

Dans ce modèle, vous stockez toutes les données d'une ligne dans une seule colonne sous un format sérialisé, tel qu'un tampon de protocole (protobuf). Cette approche est décrite plus en détail sur la page Concevoir votre schéma.

Par exemple, si vous utilisez ce modèle pour stocker les données des ballons-sondes, votre table peut se présenter sous la forme suivante au bout de quatre minutes :

Clé de ligne measurements_blob
us-west2#3698#2021-03-05-1200 protobuf_1
us-west2#3698#2021-03-05-1201 protobuf_2
us-west2#3698#2021-03-05-1202 protobuf_3
us-west2#3698#2021-03-05-1203 protobuf_4

Les avantages de ce modèle sont les suivants :

  • Efficacité du stockage

  • Rapidité

Les inconvénients sont les suivants :

  • Impossibilité de récupérer certaines colonnes lorsque vous lisez les données

  • Besoin de désérialiser les données après leur lecture

Voici quelques exemples d'utilisation de ce modèle :

  • Vous ne savez pas comment vous allez interroger les données, ou vos requêtes sont susceptibles de fluctuer.

  • Votre besoin de limiter les coûts l'emporte sur votre besoin de pouvoir filtrer les données avant de les récupérer dans Bigtable.

  • Chaque événement contient tellement de mesures qu'il se peut que vous dépassiez la limite de 100 Mo par ligne si vous stockez les données dans plusieurs colonnes.

Horodatage unique désérialisé

Avec ce modèle, vous stockez chaque événement sur sa propre ligne, même si vous n'enregistrez qu'une seule mesure. Les données des colonnes ne sont pas sérialisées.

Les avantages de ce modèle sont les suivants :

  • Il est généralement plus facile de mettre en œuvre un modèle de bucket temporel.

  • Vous passerez sans doute moins de temps à affiner votre schéma avant de l'utiliser.

Les inconvénients de cette méthode l'emportent souvent sur les avantages :

  • Bigtable est moins performant avec ce modèle.

  • Les données stockées de cette manière ne sont pas compressées aussi efficacement que les données contenues dans des colonnes plus larges.

  • Même lorsque l'horodatage est à la fin de la clé de ligne, ce modèle peut entraîner des hotspots.

Voici quelques exemples d'utilisation de ce modèle :

  • Vous souhaitez toujours récupérer toutes les colonnes mais seulement une plage d'horodatage spécifique, or vous avez une raison de ne pas stocker les données dans une structure sérialisée.

  • Vous souhaitez stocker un nombre illimité d'événements.

Avec les exemples de données des ballons-sondes, la famille de colonnes et les qualificatifs de colonnes sont les mêmes que dans l'exemple utilisant les buckets temporels et les nouvelles cellules. Toutefois, avec ce modèle, chaque ensemble de mesures communiquées par chaque ballon-sonde est écrit dans sur nouvelle ligne. Le tableau suivant présente cinq lignes écrites via ce modèle :

Clé de ligne pression température humidité altitude
us-west2#3698#2021-03-05-1200 94558 9,6 61 612
us-west2#3698#2021-03-05-1201 94122 9,7 62 611
us-west2#3698#2021-03-05-1202 95992 9,5 58 602
us-west2#3698#2021-03-05-1203 96025 9,5 66 598
us-west2#3698#2021-03-05-1204 96021 9,6 63 624

Stratégies supplémentaires

Si vous devez envoyer plusieurs requêtes différentes pour le même ensemble de données, envisagez de stocker vos données dans plusieurs tables, chacune avec une clé de ligne conçue pour l'une des requêtes.

Dans certains cas, vous pouvez également combiner des modèles. Par exemple, vous pouvez stocker des données sérialisées dans des lignes représentant des buckets temporels, à condition que les lignes ne deviennent pas trop volumineuses.

Étape suivante