2 votes

Rollup de données complexes dans TimescaleDB

J'ai un système qui collecte des données de compteur toutes les 5s vers le TimescaleDB.

Les exigences en matière d'enroulement sont les suivantes :

  1. Pour les données datant de plus de 7 jours, la granularité passe de 5s à 1 heure.
  2. Pour les données de plus de 30 jours, la granularité passe de 1 heure à 1 jour.

Je peux obtenir (1) en utilisant un agrégat continu à partir de l'hypertable 5s et en utilisant la rétention des données.
Cependant, pour (2), je ne peux pas créer une deuxième vue matérialisée à partir de la première vue matérialisée de (1) parce que je ne peux le faire qu'à partir d'un hypertable.

Comment puis-je remplir les conditions du rollup ?
Puis-je d'une manière ou d'une autre tirer parti du fait que mes mesures sont des compteurs (je peux simplement supprimer des lignes pour réduire la granularité) ?

3voto

Mike Freedman Points 396

Vous pouvez définir plusieurs agrégats continus sur le même hypertable, donc l'approche typique est d'avoir un agrégat continu séparé de 5s, 1h, 1d, avec différentes politiques de rétention de données définies sur chacun.

3voto

k_rus Points 1642

Agrégats continus ne peut être défini qu'au sommet d'un hypertable. Vous ne pouvez pas définir un agrégat continu à partir d'un autre ou le modifier.

Je vois deux approches pour obtenir la fonctionnalité souhaitée avec la version actuelle de TimescaleDB 2.2 :

  1. Les deux sites politiques d'agrégation continue matérialise les données après 7 jours. Un politique de rétention supprime les données d'origine au bout d'une semaine et une autre politique de conservation supprime les données du premier agrégat continu avec un seau d'une heure au bout de 30 jours.
  2. La première police d'agrégation continue s'est matérialisée après 7 jours et la seconde - après 30 jours. Cela signifie que les données originales doivent être conservées jusqu'à ce que le deuxième agrégat continu matérialise les données. Ainsi, les deux politiques de rétention seront après 30 jours. Alors que les données originales sont conservées plus longtemps, l'hypertable peut être comprimé pour réduire l'utilisation du disque.

Voici une mise en œuvre possible. Les agrégats continus seront les mêmes dans les deux approches :

CREATE MATERIALIZED VIEW cagg_1h WITH (timescaledb.continuous) AS
SELECT time_bucket('1h', my_time_column), ...
FROM my_hypertable
WHERE ...
GROUP BY 1, ...;

CREATE MATERIALIZED VIEW cagg_1d WITH (timescaledb.continuous) AS
SELECT time_bucket('1d', my_time_column), ...
FROM my_hypertable
WHERE ...
GROUP BY 1, ...;

Les politiques de la première approche :

SELECT add_continuous_aggregate_policy('cagg_1h', INTERVAL '7d', INTERVAL '6d', INTERVAL '4h');
SELECT add_continuous_aggregate_policy('cagg_1d', INTERVAL '8d', INTERVAL '5d', INTERVAL '1h');
SELECT add_retention_policy('my_hypertable', INTERVAL '8d');
SELECT add_retention_policy('cagg_1h', INTERVAL '30d');

J'ai essayé de définir les fenêtres de rafraîchissement pour les agrégats continus, c'est-à-dire les intervalles de décalage de début et de fin, et l'intervalle de rétention des données originales de telle sorte que les données soient matérialisées dans les deux agrégats continus avant d'être abandonnées.

Pour la deuxième approche :

SELECT add_continuous_aggregate_policy('cagg_1h', INTERVAL '7d', INTERVAL '6d', INTERVAL '4h');
SELECT add_continuous_aggregate_policy('cagg_1d', INTERVAL '30d', INTERVAL '27d', INTERVAL '1d');
SELECT add_compression_policy('my_hypetable', INTERVAL '7d');
SELECT add_retention_policy('my_hypertable', INTERVAL '30d');
SELECT add_retention_policy('cagg_1h', INTERVAL '30d');

De même, les agrégats continus contiennent des fenêtres de rafraîchissement, afin que les données soient matérialisées à l'intervalle souhaité et ne soient pas abandonnées par les politiques de rétention. La deuxième approche inclut une politique de compression supposant qu'aucune mise à jour n'arrivera aux données originales après 7 jours, ce qui semble être vrai d'après la description de la question.

Avant d'ajouter une politique de compression, il est nécessaire de l'activer en modifier l'hypertable original .

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X