digoal
2019-12-16
PostgreSQL , timescaledb , compress , array , decompress
timescaledb是PG的一款时序数据插件，1.5版本添加了自动压缩的功能。
https://docs.timescale.com/latest/using-timescaledb/compression
As of version 1.5, TimescaleDB supports the ability to natively compress data. This functionality does not require the use of any specific file system or external software, and as you will see, it is simple to set up and configure by the user.
例如一个传感器监控表，有时间，设备id，监控维度，监控值等若干字段。
| time | device_id | cpu | disk_io | energy_consumption |
|---|---|---|---|---|
| 8/22/2019 0:00 | 1 | 88.2 | 20 | 0.8 |
| 8/22/2019 0:05 | 2 | 300.5 | 30 | 0.9 |
通过sql接口可以设置这个表的压缩分段字段，排序字段，压缩周期
ALTER TABLE measurements SET (
timescaledb.compress,
timescaledb.compress_segmentby = 'device_id'
);
ALTER TABLE measurements
SET (timescaledb.compress,
timescaledb.compress_orderby = 'device_id, time DESC');
SELECT add_compress_chunks_policy('measurements', INTERVAL '7 days');
时序数据量大，近期的数据主要是高并发高吞吐的写入，可能还有更新，明细查询需求，随着时间推移，历史数据逐渐转为分析需求。
压缩需要解决存储空间问题。
压缩需要解决存储空间问题，同时还不能影响近期数据的写入、更新、明细查询的效率。同时历史数据通常是大范围查询，压缩后不能影响大范围查询效率。
1、保证近期数据写入、更新、明细查询的效率
2、无损压缩
3、压缩后的数据在某些字段上可以较为高效的查询。
timescaledb压缩：选择分段字段，排序字段，时间字段，压缩什么时间之前的记录？
例如time字段为时间字段，这个字段7天前的数据，压缩。压缩的分段字段为device_id，排序字段为time 倒序。
压缩后的结果如下，实际上就是用数组存储多值，多条记录，实际上我以前也写过一些关于聚合提升范围检索效率的case，提高分析效率的vops插件等，末尾大家可以参考一下：
| time | device_id | cpu | disk_io | energy_consumption |
|---|---|---|---|---|
| [12:00:02, 12:00:01] | 1 | [88.2, 88.6] | [20, 25] | [0.8, 0.85] -- 一个chunk |
| [12:00:02, 12:00:01] | 2 | [300.5, 299.1] | [30, 40] | [0.9, 0.95] -- 另一个chunk |
多条记录压缩到一条记录，通常1000条一个chunk。
按device_id查询，效率可以保障。
timescale 1.5版本，压缩后到表不支持更新（未来可能支持）
为什么要压缩以前的数据？
1、保证近期数据写入、更新、明细查询的效率，压缩后无法写入、更新。
2、近期的数据到达顺序可能不完全与时间字段保持一致，例如ts=20:00的数据可能21:00才写入(由于程序问题或其他问题等造成)。所以要压缩这个到达窗口之前的数据（不会变的数据）
所以近期的数据不能压缩，得压缩以前的数据。
1、一个chunk至少要有一定的记录，压缩效率才高，例如1000条压缩为1条，压缩效率高（pglz，gzip字段压缩）。
所以被选择的分段字段不能是pk，pk的话就只有1条记录，没得压缩。
一般选择有查询需求（where xx），有重复值的字段。例如设备号。
通常选择where条件的第二个条件，例如时间。
查询什么设备，在什么时间区间（例如某5分钟）的数据。
所以会选择ts作为排序字段。
ALTER TABLE measurements
SET (timescaledb.compress,
timescaledb.compress_orderby = 'device_id, time DESC');
当前使用了PG内置的column压缩（toast pglz）。将多条记录转换为数组(variable)存储压缩。
One of the current limitations of TimescaleDB is that once chunks are converted into compressed column form, we do not currently allow any further modifications of the data (e.g., inserts, updates, deletes) or the schema without manual decompression.
In other words, chunks are immutable in compressed form. Attempts to modify the chunks’ data will either error or fail silently (as preferred by users). We plan to remove this limitation in future releases.
压缩表支持insert,update,delete
https://docs.timescale.com/latest/using-timescaledb/compression
《PostgreSQL VOPS 向量计算 + DBLINK异步并行 - 单实例 10亿 聚合计算跑进2秒》
《PostgreSQL 向量化执行插件(瓦片式实现-vops) 10x提速OLAP》
《PostgreSQL index include - 类聚簇表与应用(append only, IoT时空轨迹, 离散多行扫描与返回)》
《PostgreSQL IoT，车联网 - 实时轨迹、行程实践 2 - (含index only scan类聚簇表效果)》
《PostgreSQL IoT，车联网 - 实时轨迹、行程实践 1》
《PostgreSQL pipelinedb 流计算插件 - IoT应用 - 实时轨迹聚合》
您的愿望将传达给PG kernel hacker、数据库厂商等, 帮助提高数据库产品质量和功能, 说不定下一个PG版本就有您提出的功能点. 针对非常好的提议，奖励限量版PG文化衫、纪念品、贴纸、PG热门书籍等，奖品丰富，快来许愿。开不开森.
