经常有客户问,使用你们的实时数据库,该如何计算存贮一年历史数据所需要的磁盘空间?
让我们以一个具体例子进行说明吧:一个项目中,总共有
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/平均变化一次的秒数
----------------> 就存储来说:RTDB是DB 的 1/100