Go to content

Le décisionnel autrement : les Time-series databases

Le décisionnel autrement : les bases de données de séries chronologiques (Time-series databases)

Lorsque l’on fait de la métrologie (appels téléphoniques, mesures de performance, tracking de personnes, finance, évènements sur des équipements réseaux) on se retrouve très rapidement avec des volumes très importants. Dans le domaine des télécoms ou de la sécurité il n’est pas rare d’avoir des volumétries de plusieurs dizaines de millions d’évènements par mois. Chez les collecteurs de données personnelles (Facebook, Google et consorts) on parle en milliards.

Dans ce cadre, les bases de données relationnelles montrent leurs limites.  On peut repousser ces limites mais dans ce cas il faut avoir un portefeuille très garnis. Et des fois cela ne suffit même pas …

Ces données de métrologie sont souvent définies par les attributs suivants :

– 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

Time-series databases

 

Elles ont également plusieurs caractéristiques principales :

– De très nombreuses données : par exemple le nombre total de transactions des horodateurs de paris en 2014 représente près de 25 millions de points (https://opendata.paris.fr/explore/dataset/horodateurs-transactions-de-paiement/)

– Des données immuables : en principe, ces données ne sont jamais modifiées après insertion

– L’horodatage est la clé d’accès privilégiée : ce type d’accès au sein de la base de données relationnelles ajoute des traitements supplémentaires, qui affectent le stockage et l’accès à ces données

– Leur utilisation nécessite la manipulation de fonctions statistiques (maximums, minimums, moyennes, déviations, etc.) car il est souvent utile de réduire la résolution pour comprendre les données

 

Ceux qui ont déjà travaillé avec ce type de données savent qu’ils vont devoir relever plusieurs défis pour avoir des performances correctes :

– Limiter les accès complets à des données « mortes » : on fait souvent appel dans ce cas au partitionnement de tables

– Gérer les calculs de date sans pénaliser les performances, en maniant le between en lieu et place du trunc par exemple

– Indexer des données dont les valeurs sont uniques en utilisant des index fonctions, car la disparité des données rend l’index b-tree inutile

 

Pour restituer et stocker ces données temporelles on avait « souvent » recours à  RRD Tool. Cependant cet outil impose plusieurs contraintes et limites. Tout d’abord il est très spécialisé, il adresse principalement des données de supervision. De plus, il est relativement complexe à mettre en œuvre et nécessite de se poser les bonnes questions pour aborder son exploitation à long terme. Et surtout la caractéristique de RRD Tool qui fait sa force est également sa plus grande limite, en effet le principal avantage d’une base RRD est sa taille fixe, ce qui implique qu’il y a perte de précision au fil du temps.

 

Pour répondre aux besoins de stockage des données temporelles, de nouvelles bases de données sont apparues. Ce sont les bases de données de séries chronologiques (Time-series databases) qui sont spécialisées sur les problématiques de données temporelles et très performantes dans ce cadre d’utilisation. Ces bases de données temporelles partagent dans l’ensemble les caractéristiques suivantes :

– Architecture industrielle, scalable et haute disponibilité (avec plein de nouveaux outils à découvrir : Docker, Puppet, Chef, Kubernete)

– API permettant le stockage et le requêtage basé sur des paires clés/valeur (au revoir le SQL bonjour aux requêtes http et aux réponses JSON)

– Possibilité d’effectuer des opérations statistiques natives sur les données

– Pas de perte de précision

 

L’écosystème de ces bases est très vivant et de nombreuses solutions sont disponibles. On peut citer  par exemple OpenTSDB qui est utilisé par StumbleUpon pour stocker plus d’un milliard de points par jour et qui s’appuie sur le moteur HBase. Un projet se détache du lot : InfluxDB. Il s’appuie sur levelDB (une librairie clé/valeur développée par Google dans une optique de performance) et s’inscrit dans une logique de développement qui vise à proposer une couche complète d’analyse des données temporelles avec les outils suivants :

  • Telegraf est un outil de collecte qui permet de récupérer des métriques sur des services Docker, RDBS, NoSQL, SNMP et bien plus
  • Influxdb est un moteur de base de données écrit en Go pour gérer de manière spécifique les données temporelles avec un objectif de haute disponibilité et de forte performance
  • Chronograf est une application de visualisation qui permet de faire des requêtes ad hoc, il inclut également des Template et des Dashboard préconfigurés
  • Kapacitor est le moteur interne d’Influxdb, on peut le configurer pour gérer des alerte

Avec le nombre croissant d’objets connectés qui produisent de la donnée temporelle et/ou spatiale, ces Time-series databases très spécialisées ont de bonnes chances de creuser leur trou dans le paysage technologique du traitement de la donnée.

 

Auteur : Jean-Christophe DurantonCONIX