Le contexte général de ce billet est celui du métrologie/monitoring domotique dont l’objectif est 1) de stocker dans une base de données des relevés horodatés (timestamp) de sources et de nature diverses (température, luminosité, détection, compteur…) ; et 2) de produire des graphiques en utilisant ces données.

Ces relevés sont des données singulières pour une base de données. Il est donc important de se poser des questions à leur sujet comme : Comment les traiter ? Existe-t-il ou faut-il utiliser un SGBD particulier pour les traiter ? Quels outils utiliser pour les explorer en produisant des graphiques ?

Les relevés que la base de données va devoir stocker sont particuliers et sont caractérisés par au moins :

• Un horodatage (timestamp)
• Une source permettant d’identifier l’origine de la mesure
• Une métrique permettant, entre autres, de caractériser la nature de la mesure
• Une valeur

De plus, ces relevés vont produire une grande quantité de données immuables. Par exemple, une centaine de capteurs avec en moyenne une mesure toutes les dix minutes vont produire plus de 5 millions de relevés par an. En principe, ces données ne sont jamais modifiées après insertion.

Il faut noter que dans ces données, la caractéristique horodatage est centrale : elle constitue un critère de tri et d’accès particulier qu’il peut être pertinent d’optimiser.

Enfin, il est souvent nécessaire de réduire la résolution de ces relevés chronologiques pour les afficher. Or cette réduction n’est pas triviale et fait intervenir des fonctions mathématiques pour produire des comptages, des moyennes, des interpolations, des lissages, des maximums, des minimums…

Pour trouver de l’information sur Internet à ce sujet, on peut utiliser les mots-clés suivant :

• Time Series Database
• Bases de données de séries chronologiques
• Bases de données de séries temporelles

Une petite recherche sur Internet permet de se rendre compte qu’il existe des SGBD dédiés, mais que l’on peut aussi utiliser un SGBD relationnel classique.

Concernant l’utilisation d’un SGBD classique, j’ai trouvé que le billet Querying Time Series in Postgresql constitue un bon point d’entrée dans cette problématique. En résumé, on utilise le type timestamptz ou bien en SQL standard timestamp with time zone pour horodater les mesures à la microseconde près. Ensuite, pour réduire la résolution des relevés, la fonction date_trunc constitue une aide précieuse. Et enfin, les window function sont très utiles pour réaliser certaines synthèses au niveaux des valeurs mesurées.

Querying Time Series in Postgresql

À ce niveau, deux grandes tendances se dessinent : les librairies PHP et les librairies JavaScript avec lesquelles le code est exécuté sur le poste client.

Du côté des librairies PHP, on peut citer :

• JpGraph – Gratuit pour une utilisation non commerciale, JpGraph permet de produire des images de type graphiques à partir d’un ensemble de données.
• pChart – Gratuit pour une utilisation non commerciale, pChart intègre des fonctions statistiques permet de générer des images.
• mtChart – est dérivé de la librairie pChart afin d’offrir des graphiques plus aboutis et plus variés.

Du côté des librairies JavaScript, on peut citer :

• Highcharts – Gratuit pour une utilisation non commerciale, Highcharts est une librairie puissante, facile d’accès, extrêmement paramétrable qui propose un très beau rendu pour un grand nombre de types de graphiques (Bar, pie, donut, scatter, bubble, line, stacked, spline, area, timeline).
• jqPlot
• dygraphs

Les bases de données relationnelles traditionnelles peuvent montrer leurs limites ou ne pas être les plus adaptées pour manipuler des données de séries chronologiques. Pour répondre à ce problème spécifique et récurrent (cf. le domaine de la supervision d’installations informatiques), des systèmes de gestion de bases de données dédiés ont été conçus.

RRDTool

Graphite

OpenTSDB

KairosDB

InfluxDB

Conclusions

Autres références