Vitesse d'indexation des données : Elasticsearch et Influxdb
De nos jours nous utilisons de plus en plus de données temporaires. L’internet des objets, les détections de pannes, les données météorologiques, l'étude de la qualité de l’air, la gestion des flux sur les routes utilisent des données provenant de capteurs. L’efficacité de ces systèmes nécessite un enregistrement et un stockage en temps réel des données afin que ces dernières puissent être utilisées pour lancer des alarmes, exécuter des algorithmes pour réaliser des prévisions... La présence de flux continus avec de fortes volumétries qui rend aujourd’hui nécessaire l’utilisation de bases de données optimisées.
Les bases de données Nosql proposent une maintenance simplifiée et la possibilité de dimensionner la puissance de calcul en fonction de l’importance du flux.
Pour avoir un ordre d’idée de l’importance des flux des données temporelles, pour rappel une seconde est 1 000 millisecondes, une milliseconde est 1 000 microsecondes et une microseconde est 1 000 nanosecondes, c’est-à-dire que pour une seconde nous avons un million de microsecondes et qu’en une heure nous avons 3.6e+9 microsecondes.
D’après Wikipédia, la vitesse de transaction pour le trading haute fréquence était de 20 millisecondes à la fin des années 2010 pour passer en 2011 à 113 microsecondes, ce changement d’échelle nécessite une faible latence que les bases de données NoSql propose.
Format des dates
| Unix timestamp | ISO8601 | |
|---|---|---|
| Secondes | 1487331769 | 2017-01-16T19:20:30 |
| Millisecondes | 1487331769345 | 2017-01-16T19:20:03.166 |
| Microsecondes | 1487331769345234 | 2017-01-16T19:20:03.166456 |
| Nanosecondes | 1487331769345234654 | 2017-01-16T19:20:03.166456345 |
1. Présentation des données
Dans cette partie nous étudierons l'injection de données d'une base de plusieurs millions d'enregistrements.
https://archive.ics.uci.edu/ml/datasets/Heterogeneity+Activity+Recognition
Exemple d'un document du fichier csv
Index,Arrival_Time,Creation_Time,x,y,z,User,Model,Device,gt
0,1424696633909,1424696631914042029,0.013748169,-0.0006256103500000001,-
0.023376465,a,nexus4,nexus4_1,stand
Dans cette base nous utiliserons les données du gyroscope de téléphone portable, fichier
Phones_gyroscope.csv, taille de 1.3 Go.
Les données des gyroscopes sont x, y, z.
Pour chaque enregistrement nous avons la date en millisecondes de type Unix de la mesure,
le type d'appareil utilisé, le numéro de l'appareil, le nom de l'utilisation et le type d'activité :
"Biking", "Sitting", "Standing", "Walking", "Stair Up", "Stair down".
Ce type de données provenant de capteurs peut être utilisé pour modéliser le type d'activité c'est-à-dire qu'avec seulement les données des capteurs il serait possible de connaître le type d'activité en cours.
Dans notre cas nous utiliserons ce fichier de presque 14 millions d'enregistrements pour tester la vitesse d'indexation d'Elasticsearch et de influxdb.
2. Elasticsearch
3. Influxdb
Conclusion
L'environnement d'Elasticsearch permet relativement simplement de récupérer un flux de données et de créer un tableau de bord. J'ai été séduit par la possibilité de créer des index selon la date ce qui permet de supprimer facilement des données obsolètes sans bloquer la base de données avec des opérations de sauvegardes ce qui réduit le risque de corrompre ses données.
Le langage de requête d'Elasticsearch gagnerait à être plus lisible, l'utilisation du format json oblige à gérer un grand nombre d'accolades et augmente le risque d'erreur, à la différence du sql une requête complexe peut prendre plusieurs dizaines de lignes, les différentes documentations traitent peu de ce type de requête. Il faudrait créer un outil graphique pour rendre l'outil plus accessible, cependant on ne peut retirer à Elasticsearch la rapidité d'exécution des requêtes, souvent moins de 200 millisecondes avec les données que j'ai utilisées.
Au sujet de la vitesse d'indexation des données j'ai été impressionné par la vitesse d'indexation de influxdb par rapport à Elasticsearch cependant je ne peux conclure si un outil est mieux qu'un autre n'ayant testé que la partie indexation.
Pour des données massives, il faudrait en plus de la vitesse d'indexation tester la scalabilité des deux outils, selon une étude du Cern il y a quelques années elasticsearch brillait par sa capacité à la "scalabilité" par rapport à influxdb depuis il y a eu de nombreuses nouvelles versions de ces deux outils une nouvelle étude serait intéressante.