Комплексное сведение данных в TimescaleDB

У меня есть система, собирающая данные счетчика каждые 5 секунд в TimescaleDB.

Требования к накоплению:

  1. Для данных старше 7 дней степень детализации изменяется с 5 секунд до 1 часа.
  2. Для данных старше 30 дней детализация снижается с 1 часа до 1 дня.

Я могу получить (1), используя непрерывный агрегат из гипертаблицы 5s и используя сохранение данных.
Однако для (2) я не могу создать второе материализованное представление из 1h материализованного представления (1), потому что я может сделать это только из гипертаблицы.

Как я могу выполнить требования к объединению?
Могу ли я каким-то образом использовать тот факт, что мои измерения являются счетчиками (можно просто удалить строки, чтобы уменьшить детализацию)?


person yossile    schedule 02.05.2021    source источник


Ответы (2)


Непрерывные агрегаты можно определять только поверх гипертаблицы. Вы не можете определить непрерывный агрегат из другого или изменить его.

Я вижу два подхода к достижению желаемой функциональности с текущей версией TimescaleDB 2.2:

  1. Обе политики непрерывного агрегирования материализует данные через 7 дней. Одна политика хранения удаляет исходные данные через 1 неделю, а другая политика хранения удаляет данные из первый непрерывный заполнитель с 1-часовым ведром через 30 дней.
  2. Первая непрерывная совокупная политика материализовалась через 7 дней, вторая - через 30 дней. Это означает, что исходные данные необходимо хранить до тех пор, пока второй непрерывный агрегат не материализует данные. Таким образом, обе политики хранения будут действовать через 30 дней. Хотя исходные данные хранятся дольше, гипертаблицу можно сжать, чтобы уменьшить использование диска.

Здесь возможна реализация. Непрерывные агрегаты будут одинаковыми в обоих подходах:

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, ...;

Политика для первого подхода:

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');

Я попытался определить окна обновления для непрерывных агрегатов, то есть интервалы начального и конечного смещения, а также интервал для хранения исходных данных таким образом, чтобы данные были материализованы в обоих непрерывных агрегатах перед удалением.

Для второго подхода:

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');

То же самое и здесь, непрерывные агрегаты содержат окна обновления, поэтому данные будут материализованы с желаемым интервалом и не будут отброшены политиками хранения. Второй подход включает политику сжатия, предполагающую, что никакие обновления исходных данных не поступят через 7 дней, что, как представляется, соответствует действительности из описания вопроса.

Перед добавлением политики сжатия необходимо включить ее, изменив исходную гипертаблицу .

person k_rus    schedule 03.05.2021

Вы можете определить несколько непрерывных агрегатов в одной и той же гипертаблице, поэтому типичный подход состоит в том, чтобы иметь отдельные непрерывные агрегаты 5s, 1h, 1d, с разными политиками хранения данных, определенными для каждого из них.

person Mike Freedman    schedule 03.05.2021