Questions essentielles sur les base de données Time Series

Aujourd’hui, le gros des données Big Data est de nature temporelle. On le constate dans les médias comme chez nos clients : compteurs intelligents, transactions bancaires, usines intelligentes, véhicules connectés… IoT et Big Data font bon ménage.

Nous avons plusieurs fois traité des Time Series par le passé, à travers des études comparatives et la réalisation de PoCs (Proof of Concept), ou bien via la mise en production de certaines des solutions disponibles. Parmi les technologies utilisées, citons Grafana+OpenTSDB+HBase, Warp 10, Druid, Cassandra…

Ces solutions sont-elles incontournables lorsqu’on traite des Time Series ? À partir de quel volume de données ces solutions apportent un avantage décisif ? Sont-elles matures ?

Légitimité

On peut répondre à la question “quand faut-il passer sur une base de données spécifique ?” de la même manière qu’on justifierait une transition d’une base de données classique à une plateforme Big Data : dès que la solution en cours n’est plus en mesure d’adresser ses services, que ce soit dû aux coûts, à la difficulté de maintenir un service opérationnel ou à la volumétrie. Cette volumétrie ne se limite pas au stockage des données mais aussi au profil des requêtes, à leur nombre (concurrency), à leur vitesse d’exécution (latency), aux accès en écriture, etc.

Solutions disponibles

Depuis quelques années, sont apparues plusieurs bases de données dédiées à la gestion de grandes quantités de données de mesure horodatées (time-series databases) dont la plupart sont des logiciels libres. Les solutions pour stocker des données temporelles sont diverses. Elles incluent :

• Les bases de données de type sorted key value set (incluant les columns family) comme HBase et OpenTSDB, Cassandra et KairosDB, et InfluxDB.
• Des solutions spécifiques comme Druid, Prometheus.
• Des nouveaux entrants comme TimescaleDB et TileDB.

Presque toutes ces solutions peuvent être considérées comme matures et sont en production. Nous avons par exemple testé la première fois OpenTSDB en 2011, pendant la préhistoire du Big Data. De par leur spécialisation, une bonne compréhension des cas d’usage et des PoCs comparatifs sont nécessaires avant validation.

Toutes ces solutions sont Open Source, mis à part InfluxDB. Plus précisément, son cœur de solution est Open Source, cependant le code est propriétaire et les fonctionnalités de scalabilité (clustering) ne sont accessibles que par l’offre Enterprise. Cela peut entrer en conflit avec la vision “Open Source First” d’un grand nombre d’entreprise.

Critères de comparaison

Il y a de nombreux aspects à comparer dont les performances, l’écosystème, les fonctionnalités ou encore l’opérabilité. Aussi, il convient de délimiter ce que l’outil apporte versus ce qui est de la responsabilité de l’application. Doit-on considérer la base de données comme un stockage brut, auquel cas HBase et Cassandra sont d’excellents candidats, ou bien comme embarquant des fonctionnalités spécifiques aux Time Series (eg requêtes GroupBy et TopN), nécessitant une solution spécialisée comme Druid ou InfluxDB.

Attention aux comparatifs douteux. Par exemple, notre opinion nous a été demandée à propos d’un comparatif InfluxDB vs ElasticSearch qui n’a aucune pertinence si le sujet est traité sous l’angle des performances lorsqu’on parle en centaines de terabytes. Cela revient en effet à comparer les performances d’une voiture familiale avec celle d’une voiture de course. On ne se porte pas acquéreur d’une voiture familiale pour sa vitesse. Ainsi ElasticSearch n’a pas vocation à être une base de données optimisée pour le stockage des Time Series mais, comme une base de données relationnelle, son modèle lui permet de le faire au détriment des performances.

Batch vs Streaming

Les données peuvent être stockées en fichier et être traitées par batch, que ce soit sur Hadoop (eg HDFS + ORC + Hive) ou bien sur le Cloud (eg S3 + Spot Instance + Spark). Ces architectures sont techniquement simples à mettre en œuvre et justifiables pour certains traitements d’Analytics et de Data Science ou dans l’attente de futurs cas d’usage.

À terme, des solutions plus ambitieuses imposent une alimentation et des traitements en flux continu (semi temps réel) ainsi que des requêtes interactives à très faible latence et/ou très forte concurrence. Ce type de requêtes impose des stockages qui échangent la flexibilité contre une forte spécialisation.

Pour choisir entre une architecture batch ou une architecture streaming, il y a plusieurs approches possibles :

1. Des questions sont toujours en suspens : les cas d’usage ne sont pas encore très clairs ; les composants, le matériel et la quantité à commander ne sont pas encore définis ; on souhaite disposer d’un peu plus temps à la réflexion ou à l’expérimentation ; les données doivent être stockées au plus vite afin de construire le futur dataset et le délivrer à des populations de Data Analysts et Data Scientists. Alors le plus sage est de conserver une architecture batch avec par exemple un stockage dans HDFS ou bien S3.
2. Les contraintes autour des données sont fortes : un ou plusieurs cas d’usage nécessitent des accès uniques, par exemple 1 ou N capteurs sur une plage de temps déterminée, à très faible latence et en fortes quantités ; les données sont alimentées au fil de l’eau et doivent être mises à disposition en quasi-temps réel tout au long de la chaîne d’ingestion ; le système est fortement sollicité en nombre d’écriture. Dans ce cas une base de données spécifique aux Time Series est requise.

Ces deux approches peuvent être complémentaires l’une de l’autre :

• Parce qu’elles adressent des requêtes différentes : faible latence et forte concurrence (OLTP) contre haut débit de lecture (OLAP).
• Sur des rétentions différentes, avec par exemple un stockage fichier long terme et du in-memory à court terme