Использование сжатие в Timescale DB?

[Pianionorama]

Добрый день.

Вопрос - использовал ли кто-то возможность сжатия таблиц timescale в рамках инсталляции zabbix 4.4? Если да, то какой опыт? Какие подводные камешки? Какие плюшки получили?

[DShegolkov]

Приветствую.
Работает замечательно. База данных реально ожила, старые данные удаляются на уровне партиций (чанков). Про проблему с housekeeper забыл, но:
Сегодня заметил что графики не рисуются. Смотрю лог postgre. А там на запрос

SELECT itemid,COUNT(*) AS count,AVG(value) AS avg,MIN(value) AS min,MAX(value) AS max,round(1782* MOD(CAST(clock AS BIGINT)+2204,3600)/(3600),0) AS i,MAX(clock) AS clock FROM history WHERE itemid='119456' AND clock>='1575498196' AND clock<='1575501796' GROUP BY itemid,round(1782*MOD(CAST(clock AS BIGINT)+2204,3600)/(3600),0);

ошибка: ERROR: cache lookup failed for function "time_bucket" with 2 args
пока не знаю куда копать.

А ранее была проблема в следующем: у меня таблицы заббикса находятся в схеме zabbix. А миграцию сделал в схему public. Пришлось все функции timestampdb угонять в схему zabbix.

[Pianionorama]

ХМмм, про вашу проблему сказать не смогу. С таким не сталкивались пока. Но я в вопросе не про это.
А вот про что - https://docs.timescale.com/latest/us...db/compression. Просто мы столкнулись с тем, что в grafana графики иногда строятся очень долго, особенно когда мы берём данный с частотой измерения 15-10 секунд и запрашиваем данные за 7-30 дней, база данных прикладывается по дисковым операциям > до 10k iops и мы подумали, что вероятно, стоит сжимать таблицы базы данных для снижения нагрузки на систему хранения при выполнении таких больших SELECT.

[DShegolkov]

Приветствую.
Наступил еще на одни грабли. Момент следующий: а если я захочу отключить timescaledb. Что вчера и сделал. Вернее сначала сделал бэкап. Удалил database. Отключил timescaledb. Создал database. Залил бэкап (залился с кучей ошибок связанных с таблицами timescaledb). И историю я потерял. Историю пришлось откатывать на бэкап до перехода на timescaledb.
По вопросу повышения производительности - теперь смотрю в сторону партиционирования штатными средствами postgre. Суть в чем, разобить таблицы, например, на каждые сутки, и сделать для каждой партиции свой индекс.
Сделал партиционированные таблицы истории, трендов и, на всякий, событий на каждый день. Согласно статьи https://postgrespro.ru/docs/postgres...l-partitioning (абзац начинается с "Как говорилось выше, в секционированных таблицах можно создавать индексы") создал индексы для каждой партиции и привязал к целевой таблице. Тут, я думаю будет выигрыш по времени поиска. И теперь можно старые данные удалять как таблицу. Буду тестировать.
По вопросы сжатия таблиц: в голову пришла следующая идея. Табличное пространство каждой партиции можно менять. Учитывая, что файловая система у меня ZFS, думаю сделать точку монтирования с опцией compression gzip-9 (напирмер) и туда перемещать партиции. Если партиции суточные - то все таблицы позже текущих суток перенести. Партиция вместе с индексом переедет на tablespase и сожмется средствами ZFS. Высокая нагрузка на процессор и оперативную память будет во время перемещения. На чтение особой нагрузки не должно быть. При этой схеме можно забыть про штатную очистку истории и трендов и, вероятно всего, придется стравить триггеры на удаление (вернее заглушки). Потестирую - отпишу результат.

[Pianionorama]

Хммм, а размерность базы у вас сейчас? Просто мы то маленькие - всего 45GB, но из-за виртуализации и не совсем быстрых систем хранения периодически получаем Slow Query на чтение до 80-90 секунд. И ещё, какая версия TS у вас установлена? Мы сейчас на последней версии и вроде бы всё тихо.