Points Clés
- La gestion chronologique des données est essentielle pour les analyses de données initiées dans les organisations. Des exemples de données chronologiques sont les cours des actions ou les mesures de performances du processeur.
- Les bases de données temporelles spécialement conçues, telles que RedisTimeSeries, répondent aux besoins de gestion des données chronologiques et suppriment également les limitations imposées par les bases de données relationnelles.
- Parmi les autres bases de données créées pour les données chronologiques, on peut citer InfluxDB et Prometheus.
- En intégrant Grafana à RedisTimeSeries, vous pouvez effectuer un zoom avant ou arrière sur les graphiques en temps réel.
Les données de série chronologique sont définies de manière générale comme une série de données stockées dans un ordre temporel. Les exemples de données chronologiques peuvent aller du prix des actions sur une période de plusieurs années aux mesures de performances d'un processeur sur les dernières heures. Les données chronologiques sont largement utilisées dans de nombreux secteurs. Il a été créé une catégorie de bases de données propre, car les bases de données relationnelles, orientées document et streaming ne répondent pas aux besoins de ce type particulier de données.
Caractéristiques des données chronologiques
En raison de ses caractéristiques distinctes (énumérées ci-dessous), les données de série chronologique sont généralement inefficaces lorsqu'elles sont gérées avec d'autres bases de données :
- Acquisition de données à haute vitesse : qu'il s'agisse d'un cas d'utilisation IoT ou de données d'analyse de marché, vous disposez d'un flux de données constant qui arrive à grande vitesse et souvent en rafale. Pour la plupart des solutions, les données arrivent 24 heures sur 24, 7 jours sur 7, 365 jours par an.
- Données immuables : une fois inséré dans la base de données, un point de données ne subit aucune modification jusqu'à son expiration ou sa suppression. Les données sont généralement des données de journal avec un horodatage et un point de données.
- Étiquettes non structurées : les données de séries chronologiques sont généralement produites de manière continue sur une longue période par de nombreuses sources. Par exemple, dans un cas d'utilisation IoT, chaque capteur est une source de données chronologiques. Dans de telles situations, chaque point de données de la série stocke les informations de la source et d'autres mesures du capteur sous forme d'étiquettes (labels). Les étiquettes de données de toutes les sources peuvent ne pas être conformes à la même structure ou au même ordre.
- Diminution de la valeur dans le temps : seul un résumé agrégé des données avec une plage de temps appropriée serait pertinent à l'avenir. Par exemple, dans un an, la plupart des utilisateurs n'auront pas besoin de tous les points de données stockés à l'échelle de la milliseconde. Dans ce cas, seules les données agrégées et généralisées par minute, heure ou jour ont du sens.
- Les requêtes sont agrégées par intervalles de temps : les graphiques basés sur des données chronologiques vous permettent d'effectuer des zooms avant et arrière. Ils le font en agrégeant leurs données par intervalles de temps. Généralement, les requêtes de données chronologiques sont des agrégations. Cela contraste avec l'extraction des enregistrements individuels de la base de données.
Les problèmes liés à l'utilisation de bases de données traditionnelles pour des cas d'utilisation de séries chronologiques
De nombreuses solutions stockent encore des données chronologiques dans une base de données relationnelle. Cette approche présente de nombreux inconvénients, car les bases de données relationnelles :
- Sont conçus et optimisés pour les cas d'utilisation transactionnelle.
- Assument une surcharge de travail liée au verrouillage et à la synchronisation qui n'est pas requise pour les données de série temporelle immuables. Cela se traduit par des performances plus lentes que nécessaire pour l'acquisition et les requêtes. Les entreprises finissent ensuite par investir dans des ressources de calcul supplémentaires pour monter en charge.
- Appliquent une structure rigide pour les étiquettes et ne pouvent pas prendre en charge des données non structurées.
- Exigent des travaux planifiés pour nettoyer les anciennes données.
- Sont utilisés pour plusieurs cas d'utilisation. La surutilisation de requêtes chronologiques en cours peut affecter d'autres charges de travail.
Repenser la base de données chronologique
Une base de données chronologiques spécialement conçue répond aux besoins de traitement des données chronologiques. Elle supprime également les limitations imposées par les bases de données relationnelles. RedisTimeSeries est spécialement conçu pour collecter, gérer et transmettre des données de séries chronologiques à grande échelle. Elle offre :
- Acquisition rapide des données : en tant que base de données en mémoire, RedisTimeSeries peut importer plus de 500 000 enregistrements par seconde sur un nœud standard. Nos tests montrent que l'on peut ingérer plus de 11,5 millions d'enregistrements par seconde avec un cluster de 16 shards Redis.
- Efficacité des ressources : avec RedisTimeSeries, vous pouvez ajouter des règles pour compacter les données par sous-échantillonnage. Par exemple, si vous avez collecté plus d'un milliard de points de données par jour, vous pouvez les regrouper toutes les minutes pour les sous-échantillonner, ce qui réduit la taille du jeu de données à 24 * 60 = 1 440 points de données. Vous pouvez également définir des stratégies de conservation des données et les faire expirer au moment où vous n'en avez plus besoin.
Figure 1 : Sous-échantillonnage et agrégation à l'aide d'une base de données chronologique
- Requêtes simples et rapides : RedisTimeSeries vous permet d'agréger les données par moyenne, minimum, maximum, somme, nombre, plage, premier et dernier. Vous pouvez exécuter plus de 100 000 requêtes d'agrégation par seconde avec une latence inférieure à la milliseconde. Vous pouvez également effectuer des recherches inverses sur les étiquettes dans une plage de temps spécifique.
Influx DB et Prometheus font partie des bases de données construites spécialement pour les données chronologiques.
Une base de données chronologique typique est généralement conçue pour gérer uniquement des données chronologiques. L'un des problèmes auxquels elle est confrontée concerne les cas d'utilisation qui impliquent une sorte de calcul en plus des données chronologiques. Un exemple serait de capturer un flux vidéo en direct dans une base de données chronologique. Si vous deviez appliquer une sorte de modèle d'intelligence artificielle pour de la reconnaissance faciale, il vous faudrait extraire les données de la série chronologique, appliquer une sorte de transformation des données, puis effectuer des calculs. Ce n'est pas idéal pour un cas d'utilisation en temps réel. Les bases de données multimodèles qui gèrent également d'autres modèles de données résolvent ces cas d'utilisation où de multiples modèles de données peuvent être manipulés sur place.
Guide de démarrage rapide de RedisTimeSeries
Le moyen le plus rapide de démarrer avec RedisTimeSeries consiste à l'ajouter en tant que source de données à votre tableau de bord dans Grafana. Dans la section suivante de cet article, je vais vous expliquer comment j'ai chargé des échantillons de données de séries chronologiques dans RedisTimeSeries et je les ai affichées dans un tableau de bord Grafana.
J'ai choisi de comparer la performance des cours des actions d'Apple Inc. (AAPL) et d'Intel Inc. (INTC) sur 19 ans, en utilisant un graphique sur un panneau Grafana :
Figure 2: Comparaison des performances boursières d'Apple et d'Intel avec RedisTimesSeries et Grafana
Ma configuration de RedisTimeSeries
J'ai commencé par télécharger le code source de RedisTimeSeries à partir de GitHub et à le construire localement. J'ai ensuite importé le fichier ".so" dans Redis à l'aide de la commande suivante:
MODULE LOAD [path to]/redistimeseries.so
J'aurais aussi pu charger le module en insérant la commande suivante dans le fichier redis.conf :
loadmodule [path to]/redistimeseries.so
Si vous préférez utiliser Docker, lancez la commande suivante :
docker run -p 6379:6379 -it --rm redislabs/redistimeseries
Une fois mon serveur Redis installé, j'ai vérifié si Redis avait chargé le module avec succès en exécutant la commande «module list». Voici, «timeseries» est l'un des modules :
127.0.0.1:6379> module list
1) 1) "name"
2) "timeseries"
3) "ver"
4) (integer) 200
Exemple de jeu de données : plus de 19 ans de données boursières
J'ai téléchargé les cours quotidiens des actions AAPL et INTC à partir du Wall Street Journal. Le fichier comprenait les prix de l'année 2000 à ce jour au format csv (valeurs séparées par des virgules). Voici quelques exemples de données sur AAPL :
2006-01-03,10.34,10.68,10.32,10.68,201853036,AAPL
2006-01-04,10.73,10.85,10.64,10.71,155225609,AAPL
2006-01-05,10.69,10.7,10.54,10.63,112396081,AAPL
2006-01-06,10.75,10.96,10.65,10.9,176139334,AAPL
2006-01-09,10.96,11.03,10.82,10.86,168861224,AAPL
2006-01-10,10.89,11.7,10.83,11.55,570088246,AAPL
2006-01-11,11.98,12.11,11.8,11.99,373548882,AAPL
2006-01-12,12.14,12.34,11.95,12.04,320201966,AAPL
2006-01-13,12.14,12.29,12.09,12.23,194153393,AAPL
2006-01-17,12.24,12.34,11.98,12.1,209215265,AAPL
Ensuite, j'ai écrit un script Python pour importer ces données dans RedisTimeSeries :
import sys
import csv
import time
import redis
if(len(sys.argv) > 1):
ticker = str(sys.argv[1])
else:
ticker = 'test'
file = ticker + '.csv'
r = redis.Redis(host='localhost', port=6380, db=0)
with open(file) as csv_file:
csv_reader = csv.reader(csv_file, delimiter=",")
r.execute_command("ts.create stock:"+ticker);
count = 0
for row in csv_reader:
time_tuple = time.strptime(row[0], '%Y-%m-%d')
time_epoch = time.mktime(time_tuple)*1000
r.execute_command("ts.add stock:"+ticker+" "+str(int(time_epoch))+" "+row[1])
count = count + 1
print(f'Imported {count} lines')
Comme vous pouvez le constater, j'ai utilisé la commande TS.CREATE
de RedisTimeSeries pour établir la nouvelle structure de données chronologiques et sa commande TS.ADD
pour renseigner cette structure de données. Pour le symbole AAPL, ce programme a créé une structure de données appelée stock:aapl. Un exemple de commande pour l'ajout de données ressemble à ceci :
TS.ADD stock:aapl 1513324800000 173.04
J'ai ensuite exécuté TS.RANGE pour vérifier les données. Notez que les horodatages utilisés dans cette requête sont exprimés en millisecondes.
127.0.0.1:6379> TS.RANGE stock:aapl 1513324800000 1514324800000 aggregation avg 1
1) 1) (integer) 1513324800000
2) "173.63"
2) 1) (integer) 1513584000000
2) "174.88"
3) 1) (integer) 1513670400000
2) "174.99000000000001"
4) 1) (integer) 1513756800000
2) "174.87"
5) 1) (integer) 1513843200000
2) "174.16999999999999"
6) 1) (integer) 1513929600000
2) "174.68000000000001"
7) 1) (integer) 1514275200000
2) "170.80000000000001"
Dans la prochaine étape, j'expliquerai comment j'ai utilisé Grafana pour afficher et comparer les cours des actions.
L'affichage des données RedisTimeSeries dans Grafana
Dans cette section, je vais expliquer comment j'ai installé Grafana et utilisé le connecteur de données SimpleJSON pour lire les données de RedisTimeSeries. Pour ce faire, j'ai développé une nouvelle application de source de données SimpleJSON. C'est une application intermédiaire basée sur HTTP Node.js qui convertit les appels SimpleJSON en appels Redis et les données RedisTimeSeries en données JSON.
Étape 1: Installez Grafana
Tout d'abord, j'ai utilisé l'utilitaire homebrew pour installer Grafana sur mon Mac (si vous utilisez un PC, suivez le manuel d'utilisation de Grafana pour l'installer et le configurer). J'ai lancé les commandes suivantes pour que Grafana soit opérationnel :
$ brew install grafana
$ brew services start grafana
==> Successfully started `grafana` (label: homebrew.mxcl.grafana)
Grafana fonctionnant maintenant sur le port 3000, je pouvais me connecter à l'aide de l'url http://localhost:3000.
Étape 2: Développer et exécuter l'application de source de données SimpleJSON
Grafana est livré avec un connecteur de source de données intégré appelé SimpleJSON, qui se connecte à toute application avec un serveur HTTP prenant en charge "/", "/search" et "/query" RedisTimeSeries n'ayant pas encore son propre connecteur, j'ai développé une nouvelle application Node.js prenant en charge le protocole HTTP et les requêtes requises pour l'application de source de données SimpleJSON. Vous pouvez télécharger mon code depuis GitHub et l'exécuter dans votre environnement Node.js local.
Chaque requête HTTP dans l'application de source de données SimpleJSON a un objectif unique et j'ai développé mon programme avec les principes de conception suivants pour chacune d'entre elles :
1. "/" : Ceci est une requête par défaut qui devrait répondre avec un message arbitraire. Il est utilisé pour tester la connexion (comme un test de ping).
2. "/search" : Ceci devrait renvoyer la liste des clés contenant les données de la série chronologique. (Avec d'autres bases de données, il pourrait s'agir d'une liste de noms de tables au lieu de clés. Toutefois, Redis étant un store clé-valeur, nous renvoyons la liste des clés de type spécial pour une série chronologique).
Pour obtenir cette liste de clés, j'ai utilisé la commande "SCAN", plus sûre, à la place de "KEYS". Et pour chaque clé, j'ai vérifié si la clé était de type "TSDB-TYPE", le nom interne que nous utilisons pour les clés de séries chronologiques. Le programme gère un tableau de toutes les clés de ce type et renvoie le tableau au format JSON.
3. "/query" : la commande de requête reçoit des arguments d'entrée comprenant la liste des clés, l'heure de début, l'heure de fin et l'heure du compartiment. L'application renvoie des données de série chronologique au format JSON en fonction des commandes d'entrée.
Il existe également une quatrième requête HTTP, appelée "/annotations", mais je n'ai pas eu besoin de cette requête pour cet exemple d'application.
Une fois le code prêt, j'ai exécuté l'application. L'exemple de code écoutait les requêtes HTTP sur le port 3333, donc je pouvais le tester sur un navigateur en appelant http://localhost:3333. Il renvoie, "j'ai une quête pour vous!"
Étape 3: Connectez Grafana avec RedisTimeSeries
C'était la plus facile de toutes les étapes. Une fois connecté à Grafana, j'ai ajouté une source de données en allant dans Configuration > Data Sources, puis en cliquant sur "Add data source".
J'ai cherché l'option SimpleJSON et l'ai sélectionnée.
Cela a ouvert un écran de configuration, où j'ai entré l'URL pour me connecter à mon application Node.js.
Maintenant que la source de données est configurée, je peux ajouter de nouveaux panneaux à mon tableau de bord. Pour cet exemple, j'ai ajouté un panneau avec deux requêtes : une requête de série chronologique pour chaque titre boursier. Comme indiqué dans l'image, le menu déroulant de ma requête avait déjà renseigné les clés de série temporelle stock:aapl et stock:intc. Le graphique contient également les données dès que j'ai sélectionné les clés de série chronologique. En coulisse, le connecteur SimpleJSON avait appelé notre application avec les requêtes appropriées ("/search" et "/query").
Voici le résultat final : un panneau Grafana interrogeant RedisTimeSeries. Il était assez simple de configurer RedisTimeSeries et de le connecter à Grafana.
En conclusion, RedisTimeSeries combine tous les avantages de Redis et une base de données chronologique construite à cet effet. Cela peut aider votre entreprise de nombreuses manières, notamment en économisant des ressources, en prenant en charge davantage d'utilisateurs finaux et en permettant à vos applications de pénétrer plus rapidement sur le marché avec une intégration facile. En intégrant Grafana à RedisTimeSeries, vous pouvez effectuer un zoom avant ou arrière sur les graphiques en temps réel. Vous pouvez également gérer plus de requêtes par seconde, en laissant votre tableau de bord afficher plus de points de données dans leurs panneaux. En plus de cela, vous pouvez ajouter plus de panneaux et servir plus d'utilisateurs finaux.
A propos de l'auteur
Roshan Kumar est chef de produit senior chez Redis Labs, Inc. Il possède une grande expérience dans le développement de logiciels et la gestion de produits dans le secteur de la technologie. Dans le passé, Kumar a travaillé pour Hewlett-Packard et quelques startups prospères de la Silicon Valley. Il est titulaire d'un baccalauréat en informatique et d'une maîtrise en administration des affaires de l'Université de Santa Clara, en Californie, aux États-Unis.