海量时序数据存储空间问题
以城市气温为例
- 以城市气温为例，气温采集的传感器通常以一个固定的间隔采样
- 比如每5秒采集一次温度数据进行上报，也就是采集会7*24小时365天不间断。
- 那么我们做个简单的算术题，5秒一个数据点，一分钟会有12个点
- 那么一天就是
12*60*2417280个数据点 - 一个月则会有
12*60*24*30518400个数据点。这就是时序数据写入的第一个特点：持续写入，累计数据量大 。
多个采集站和多个传感器
- 同时需要在一个城市设置多个气温采集站，采集站内温度布置多个传感器
- 也就是说同一时刻数百万甚至数千万的数据写入
指标占用存储空间计算
- 一个点16 byte 那么一个小时的数据就是 17280* 16/1024/1024=0.26MB，这只是1个指标
- 如果上百万的指标，那么一个小时所需要的存储空间为250GB，一天则为6T的数据
分析结论
- 由于海量的监控指标和源源不断的采集
- 时序监控系统的所需的存储空间是很大
为什么要做数据点压缩
- 因为存储一般是一套大系统中的资源开销大户
- 以时序监控系统来说，假设查询模块需要10cpu，20G内存，100G磁盘，那么存储模块往往需要100cpu，2000G内存，3T磁盘。
- 所以能对存储中的数据点进行压缩，那么能直接降低内存和磁盘空间/io的开销，所以这也是tsdb开发人员不断努力的地方。
facebook_gorilla压缩算法
- Gorilla压缩算法是facebook2016发布的一篇论文 论文中提到了，Facebook内部高速发展的业务对监控系统提出了下列数据要求：
要求
- 20亿个不同的Time Series
- 每分钟产生7亿个Data Points，即每秒钟产生1200万Data Points
- 数据需要存储26个小时
- 高峰期的查询高达40000次每秒
- 查询时延需要小于1ms
- 每个Time Series每分钟可产生4个Data Points
- 每年的数据增长率为200%
特点
- 在两个小时的block里从16byte压缩到1.37byte，压缩比例高达11.6
本节重点总结 :
- 海量时序数据存储空间问题
- 为什么要做数据点压缩
- facebook_gorilla压缩算法
- 压缩比例高达11.6
