Suggestions pour stocker et récupérer des données de séries chronologiques

Question

Je travaille actuellement sur un projet qui nécessite de stocker une grande quantité de données de séries chronologiques, mais plus important encore, d'en extraire rapidement de grandes quantités.

Il y aura N périphériques (> 10 000) qui enverront périodiquement des données au système, disons toutes les 5 secondes. Ces données s'accumuleront rapidement, mais nous ne sommes généralement intéressés que par les données les plus récentes et nous souhaitons compacter les anciennes données. Nous ne voulons pas le supprimer, car il est toujours utile, mais au lieu d'avoir des milliers de points de données par jour, nous pourrions économiser 5 ou 10 points après que N jours/semaines/mois se sont écoulés. En particulier, nous voulons pouvoir extraire des données échantillonnées sur une longue période, disons un an ou deux. Il pourrait y avoir des millions de points ici, mais nous voulons juste un petit échantillon linéaire de ces données.

Aujourd'hui, nous expérimentons avec influxdb, qui semblait initialement une bonne solution. C'était assez rapide et cela nous a permis de stocker nos données dans une structure raisonnable, mais nous avons trouvé que ce n'était pas complètement satisfaisant. Nous n'avons pas pu exécuter l'exemple de requête décrit ci-dessus et, en général, le système ne semble pas assez mature pour nous.

Tout conseil sur la façon dont nous pouvons procéder, ou des solutions alternatives, est très apprécié.

Answer 1

Vous pourriez être intéressé à regarder TimescaleDB:

https://github.com/timescale/timescaledb

Il construit une série chronologique DB sur le dessus de Postgres et ainsi offre un support SQL, ainsi que généralement l'écosystème/fiabilité Postgres. Cela peut vous donner une plus grande flexibilité de requête, ce qui sonne comme vous le souhaitez.

En ce qui concerne votre cas d'utilisation spécifique, il y aurait vraiment deux solutions. Tout d'abord, ce que les gens font typiquement est de créer deux "hypertables", un pour les données brutes, un autre pour les données échantillonnées. Ces hypertables ressemblent à des tables standard pour l'utilisateur, bien que fortement partitionnés sous les couvertures pour une meilleure évolutivité (par exemple, un débit d'insertion de 20x par rapport à postgres pour les grandes tailles de tables). Ensuite, vous effectuez un cumul de la table brute à la table échantillonnée et utilisez une politique de rétention des données différente pour chacun (ainsi vous conservez des données brutes pendant 1 mois, avec des données échantillonnées pendant des années).

http://docs.timescale.com/getting-started/setup/starting-from-scratch http://docs.timescale.com/api/data-retention

Deuxièmement, vous pouvez aller avec un seul hypertable, puis planifier juste une requête SQL normale pour supprimer des lignes individuelles de données qui est plus d'une certaine période de temps.

Nous pourrions même dans le futur ajouter un meilleur support de première classe pour cette dernière approche si elle devient une fonctionnalité demandée assez courante, bien que la plupart des cas d'utilisation que nous avons rencontrés semblent plus centrés sur # 1, esp. afin de conserver des données statistiques sur les points de données supprimés, par opposition à des échantillons simples. (Déni: Je suis l'un des auteurs de TimescaleDB.)