实时数据库历史数据容量的计算方法
经常有客户问,使用你们的实时数据库,该如何计算存贮一年历史数据所需要的磁盘空间?
让我们以一个具体例子进行说明吧:一个项目中,总共有1万个模拟量测点,这些测点平均每秒变化一次,每次变化均要保存,存贮一年历史数据,需要多少磁盘空间?
为了很好地说明这个问题,我们先来分析一下,如果采用关系数据库来保存这些历史数据,需要多少磁盘空间。假定关系数据库采用一个表来保存历史数据,表的格式定义如下:
字段名 | 类型 | 长度 | 备注 |
TagID | 整型 | 4字节 | 测点编号,1万个测点只需2字节整型,但考虑到最大保存测点可能超过65536,因此,定义为4字节整型 |
Second | 整型 | 4字节 | 秒 |
MillSecond | 短整型 | 2字节 | 毫秒 |
Quality | 字节 | 1字节 | 质量戳 |
Value | 双精度数 | 8字节 | 值 |
关系数据库中,计算历史数据应考虑如下几个方面的因素:
l 管理文件
l 表格式描述头
l 数据
l 索引
其中,管理文件及表格式描述头可以忽略不计,只需要考虑数据和索引即可。另外,在此也不考虑日志文件的大小。
假定关系数据库中不对数据进行任何压缩,采用定时保存,则数据容量的计算公式如下所示:
数据容量=单条历史数据的尺寸*秒数*分钟数*小时数*天数*测点数
所以,数据容量=(4+4+2+1+8)*60*60*24*365*10000=5580G
假定对该表中的TagID、Second和MillSecond建立唯一索引,同时假定关系数据库的索引结构为B+树索引,一般的B+树的利用效率在40%左右,因此,索引大小的计算公式如下所示:
索引容量=单条索引的尺寸*秒数*分钟数*小时数*天数*测点数/0.4
所以,索引容量=(4+4+2)*60*60*24*365*10000/0.4=7342G
因此,用关系数据库保存10000个每秒钟变化一次的双精度数,同时建立一个索引,需要磁盘空间为:12922G。
下面,我们再来计算一下实时数据库的历史数据容量的计算方法。
首先要说明,不同的实时数据库对历史数据采用了不同的存贮方法,因此,计算方法也各不相同,在此,仅以我们自己的实时数据库为例,进行计算。
首先需要介绍一下我们的实时数据库的特点:
l 历史数据按时间段分为多个文件保存,每个文件保存一段时间内的历史数据,保存一年的历史数据大概需要60个文件;
l 每段时间内的数据和索引保存在同一个文件内;
l 测点的ID与其它数据在文件内分开保存。
针对我们的实时数据库,计算历史数据应考虑如下几个方面的因素:
l 管理文件
l 文件头
l 数据
l 索引
其中,管理文件的大小大概为100K左右,可以忽略。
文件头大小=单个文件头大小*所有历史数据文件头大小=512K*60=0.03G,也可以忽略
在完全不压缩的情况下,数据容量的计算公式为:
不压缩数据容量=单条历史数据的尺寸*秒数*分钟数*小时数*天数*测点数
其中,单条历史数据的尺寸已经过紧密化处理,只占14字节,所以,数据容量=14*60*60*24*365*10000=4111G
我们的实时数据库采用了特殊的索引机制,不需要对每条数据进行索引,平均200条数据才需要记录一次索引,在完全不压缩的情况下,索引容量的计算方法为:
不压缩索引容量=单条索引的尺寸*秒数*分钟数*小时数*天数*测点数/200
所以,索引容量=10*60*60*24*365*10000/200=15G
最后,再考虑压缩率。采用不同的压缩算法会有不同的压缩比,另外,还与压缩率有关,这个没有统一的计算公式。但是,在工程现场,一般而言,采用哈佛曼算法的压缩比为15:1左右,采用变化压缩算法的压缩比为20:1左右,采用旋转门算法的压缩比为30:1左右。如果再加上一些特殊的技术(如二次压缩技术,质量戳与数据值分开保存等),压缩比可以达到40:1左右。我们就按40:1进行计算
压缩后总容量=(不压缩数据容量+不压缩索引容量)/压缩比
所以,以上例子中,实时数据库历史数据总容量=(4111+15)/40=103G
注意,以上计算只考虑了双精度数测点,如果系统中还有开关量、字符串、单精度数,其中,开关量的变化可能非常缓慢,这些没有准确的计算公式,可以近似地处理为,将以上结果再除以4。
最后,给出一个在我们的实时数据库中,大致计算历史数据容量的公式:
历史数据容量=年数*万点数*25/平均变化一次的秒数