3. 历史数据库选型与部署

在SCADA系统中，“实时库”和“历史库”承担着完全不同的职责。实时库面向当前时刻，保存的是最新值、质量码和时标，通常驻留内存，读写延迟在毫秒级，用于画面刷新、报警判断和闭环控制；历史库面向过去，保存的是带时间戳的序列数据，用于趋势回放、报表统计、能效分析和事故追溯。把两者混为一谈，是选型阶段最常见的错误：用实时库的思路去设计历史库，会导致查询越用越慢；用历史库的接口去支撑实时画面，则会让操作响应变得不可接受。

从数据特征看，实时库是“点少、更新快、只关心当前值”，历史库是“点可多、写入持续、查询跨度大”。以一座中型能源站为例，测点规模约2万点，实时库只需维护这2万点的当前值，内存占用通常在几十到几百MB；而历史库按1秒采样、每点每年约3150万条记录计算，2万点一年就是约630亿条原始记录，即使经过压缩，也是TB级规模。这个数量级差异，决定了历史库必须围绕“顺序写入、批量压缩、时间范围检索”来设计，而不能照搬实时库的键值缓存结构。

常见的历史数据库架构可以归纳为三类。第一类是“关系库+时序扩展”，例如PostgreSQL配合TimescaleDB，用普通表存测点元数据，用超表（hypertable）按时间自动分区，优点是SQL生态成熟、运维人员熟悉，缺点是写入吞吐受事务机制限制，适合点数在数千到一两万、采样周期不低于1秒的场景。第二类是专用时序库，如InfluxDB、TDengine、OpenTSDB，它们把时间戳作为第一索引，采用列式存储和专用压缩算法，单节点即可支撑每秒数十万点的写入，适合大规模测点和高频采集。第三类是工业历史库，如PI System、Wonderware Historian，特点是内置旋转门压缩（swinging door）、支持插值查询和事件帧，与SCADA组态软件集成度高，但授权成本和封闭性也更高。

存储引擎的选择直接决定压缩比和查询效率。以旋转门压缩为例，它不保存每个原始值，而是保存能够包住变化趋势的“有损”折线：当新数据点落在上一条斜率线段的容差带内时就不落盘，超出容差才记录新点。假设某温度点每秒采集一次，量程0~100℃，压缩偏差设为0.5℃，一天86400个原始点经压缩后可能只剩几百到几千个存储点，压缩比可达几十比一。代价是回放时看到的是折线而非原始毛刺，因此对需要精确波形的电能质量分析，应单独设置高精度存储组，不启用有损压缩。

容量规划可以用一个简化公式估算：年存储量 ≈ 测点数 × 每秒采样次数 × 86400 × 365 × 单点字节数 ÷ 压缩比。以1万点、1秒采样、压缩后单点约2字节、压缩比20:1为例，年原始量约3.15×10¹¹条，压缩后约31.5GB，加上索引和元数据，按50GB/年预留较为稳妥。若保留5年，则需约250GB，再考虑副本和30%余量，实际磁盘应在650GB以上。这个估算应在部署前完成，而不是等磁盘写满再扩容。

部署模式上，单机部署把实时库和历史库放在同一台服务器，实施简单，但历史库的批量写入和长跨度查询会与实时库争抢CPU和磁盘I/O，点数超过5000或保留超过1年时建议分离。主备模式将历史库独立到专用主机，通过异步或半同步复制保持备机数据接近一致，切换时需关注复制延迟，通常要求延迟小于30秒。集群模式按测点哈希或时间范围分片，查询时由路由层合并结果，适合多站点汇聚和5万点以上规模，但分片键一旦选定后期调整成本很高，规划阶段就要结合站点分布和查询习惯确定。

最后需要强调，历史库的部署不是“装完即用”。上线前应做一次写入压测：用真实测点规模的一半持续写入24小时，观察写入延迟、磁盘增长速率和查询响应时间；同时验证降采样任务是否按时生成分钟级和小时级聚合数据。只有写入稳定、压缩比符合预期、查询在可接受范围内，历史库才算真正可用。