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 :
- 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.
- 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 .