第二章：历史数据架构
好，咱们进入正题。历史数据架构这块，说实话，是很多OPC UA项目里最容易出问题的地方。我见过太多项目，实时通讯跑得挺顺，一到要查历史数据就卡壳。为什么？架构没想清楚。
历史服务器架构
先说说历史服务器架构。你想想看，一个工厂里几百上千个变量，每秒都在产生数据。这些数据往哪存？怎么存？谁来管？这就是架构要解决的问题。
我个人习惯把历史服务器分成三层：
- 采集层：负责从OPC UA服务器拉数据。这里要注意，不是所有数据都要实时拉，有些可以批量拉。
- 存储层：数据落地的地方。可以是关系数据库，也可以是时序数据库。
- 服务层：对外提供查询接口。客户端要查历史数据，走这一层。
我在项目中遇到过一种情况：客户把所有数据都往一个数据库里塞，结果查询慢得要命。后来我们拆成了热数据和冷数据两层——最近一周的数据放内存数据库，历史数据放磁盘。效果立竿见影。
核心要点：历史服务器架构的关键是分层。每一层各司其职，别混在一起。
历史数据存储引擎
存储引擎这块，选择很多。但说白了，就两种主流方案：
| 引擎类型 | 代表产品 | 适用场景 |
|---|---|---|
| 关系型 | SQL Server, PostgreSQL | 数据量不大，需要复杂查询 |
| 时序型 | InfluxDB, TimescaleDB | 高频采集，海量数据 |
嗯，这里要注意。OPC UA规范里其实没规定你必须用哪种引擎。它只定义了数据怎么存、怎么取。我建议你根据数据量来选：
- 每天少于100万条记录？关系型够用。
- 每天上亿条？老老实实用时序数据库。
我曾经在一个钢铁厂项目里，用了SQL Server存温度数据。结果三个月后，查询一次要等两分钟。后来换成InfluxDB，同样的数据量，查询时间降到毫秒级。这就是选错引擎的代价。
小技巧：如果预算有限，可以考虑PostgreSQL + TimescaleDB插件。既有关系型的灵活性，又有时序数据库的性能。
历史数据存储的配置与部署
配置部署这块，我踩过的坑最多。先说说OPC UA历史服务器的配置项：
// 典型的OPC UA历史服务器配置
{
"ServerUri": "opc.tcp://localhost:4840",
"HistoryDatabase": {
"Type": "TimescaleDB",
"ConnectionString": "Host=localhost;Port=5432;Database=opcua_history",
"RetentionPeriod": "90d"
},
"SamplingInterval": 1000, // 毫秒
"QueueSize": 10000,
"ArchivePeriod": "1h"
}这里有几个关键参数：
- SamplingInterval：采样间隔。别设太短，否则数据量爆炸。我一般建议工业场景设1秒。
- QueueSize：缓冲区大小。网络断了怎么办？数据先放队列里，等恢复再写库。
- ArchivePeriod：归档周期。数据先攒一批，再批量写入。这样效率高。
部署的时候，我建议把历史服务器和OPC UA服务器分开部署。为什么？因为历史查询很吃资源，混在一起会影响实时通讯。我曾经见过一个项目，就因为没分开部署，导致实时数据采集延迟从10毫秒飙到了500毫秒。
避坑指南：我曾经在生产环境里直接把历史数据库和OPC UA服务器装在同一台机器上。结果数据量一上来，CPU直接打满。后来不得不紧急迁移。记住：历史服务要独立部署，最好用单独的服务器。
最后说说部署的硬件要求。根据我的经验：
- CPU：4核起步，8核更稳
- 内存：16GB保底，32GB推荐
- 磁盘：SSD必须的。机械盘扛不住高频写入
- 网络：千兆网卡，别省这个钱
嗯，大概就这些。历史数据架构这块，说白了就是三个字：分、存、查。分清楚层次，存对地方，查得快。做到这三点，你的历史数据系统基本就稳了。