Comment stocker efficacement des données de grandes séries temporelles?
J'ai besoin de stocker et de pouvoir interroger des données de séries chronologiques de très grandes quantités.
Les propriétés des données sont les suivantes:
- nombre de séries: environ 12.000 (douze mille)
- nombre de points de données, globalement: environ 500.000.000 par mois (cinq cent millions)
- types de valeurs mixtes: la majorité des points de données sont des valeurs à virgule flottante, les autres sont des chaînes
- période d'échantillonnage: variable entre les séries ainsi que au sein d'une série
- horodatage: précision en millisecondes
- période de conservation des données: plusieurs années, sans décroissance ni sous-échantillonnage
- les archives de données doivent être construites presque en temps réel, mais un délai raisonnable (~ 1 heure) est acceptable
- les données passées peuvent être reconstruites si nécessaire, mais à un coût élevé
- parfois, mais assez rarement, certaines données antérieures doivent être mises à jour
Propriétés des requêtes envisagées:
- la plupart des requêtes sur les données seront des requêtes basées sur l'horodatage; allant d'un jour à plusieurs mois/années. 90% + seront des requêtes sur les données les plus récentes
Autres exigences:
- la solution doit être libre comme dans la bière gratuite et de préférence opensource
Ma pensée initiale a été d'utiliser PyTables/Pandas avec fichiers HDF5 comme stockage de backend au lieu d'une base de données SQL.
Des questions :
En supposant que PyTables/Pandas est la "meilleure" route, serait-il préférable de diviser les données en plusieurs fichiers HDF, chacun s'étendant sur une période de temps donnée , ou tout mettre dans un seul fichier qui deviendrait alors énorme?
Dois-je aller préférer le format fixe ou le format tableau? Pour moi, le format fixe semble OK si je garde un fichier HDF par mois, comme de cette façon un toute la série tient probablement dans RAM et je peux découper en mémoire sans avoir besoin d'un index de format de table. Suis-je correct?
Et si c'est pas la meilleure approche, comment dois-je structurer ce magasin de données ou quelles technologies dois-je envisager? Je ne suis pas le premier à aborder le stockage de grands ensembles de données de séries chronologiques, quelle est l'approche générale pour résoudre ce défi?
Autres approches que j'ai envisagées:
- bases de données de tableaux: elles conviennent parfaitement aux séries chronologiques avec une période d'échantillonnage constante, car il vous suffit alors de stocker les heures de début et de fin et la période d'échantillonnage du tableau, puis seules les valeurs dans le tableau lui-même et l'indexation sont faciles. Mais avec des périodes d'échantillonnage variables dans les séries elles-mêmes, je dois garder une relation d'horodatage-> valeur plus étroite, qui, à mon avis, ne convient pas si bien au SGBD de tableau.
- base de données SQL standard avec horodatage, paramID, valeur sous forme de colonnes mais de par leur nature, ils demandent beaucoup d'E/S disque pour toute requête
Vous voudrez peut-être jeter un œil à carbone et chuchotement , une partie du projet graphite . Le carbone peut gérer de très grandes quantités de données de séries chronologiques. Bien que maintenant que j'ai lu les documents (cela fait quelques années que je ne les ai pas utilisés), ce n'est que pour les données numériques. Vous avez dit que vous disposiez également de données de chaîne, ce qui pourrait ne pas vous être utile. Cependant, vous pourrez peut-être glaner une certaine sagesse sur la façon dont ils sont capables de traiter rapidement de grandes quantités de données.
Pour vous donner une idée de son évolutivité, lorsque le graphite a été mis en production pour la première fois chez Orbitz, il traitait 160 000 métriques par minute .
InfluxDB est une base de données open source écrite en Go. Il a été écrit spécialement pour gérer les données de séries chronologiques, et ils ont publié des benchmarks montrant de bien meilleures performances par rapport à Cassandra :
InfluxDB a surperformé Cassandra dans les trois tests avec un débit d'écriture 4,5 fois supérieur, tout en utilisant 10,8 fois moins d'espace disque et en offrant des temps de réponse jusqu'à 168 fois plus rapides pour les requêtes testées.
vous souhaiterez peut-être extraire des bases de données orientées colonnes. Je ne sais pas ce que vous entendez par bases de données de tableaux mais avec mon approche suggérée, vous pouvez avoir un nombre dynamique de valeurs par période. Vous pouvez également avoir plusieurs valeurs pour le même horodatage. La partie intéressante est que si vous avez des valeurs mesurées au même horodatage, vous pouvez les enregistrer en tant que colonnes supplémentaires (par exemple, un capteur qui mesure la température et l'humidité, dans le prix de négociation des actions et la taille d'un commerce, ...). En raison de la nature orientée colonnes, vous pouvez avoir des tables de 100 colonnes mais si votre requête accède uniquement à cinq colonnes, la base de données lit uniquement les données des cinq colonnes.
J'ai écrit une série sur la création de votre propre base de données de séries chronologiques, vous voudrez peut-être y jeter un œil: