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