4. 时序数据库选型与部署

能源管理系统的数据底座，本质上是一个“高频写入、按时间聚合、长期留存”的时序数据库问题。一个中等规模的光伏+储能+配电监控场景，往往有 3000～8000 个测点，采样周期 1～5 秒，日增原始数据约 1～3 亿点。选型时如果只看“能不能存”，很容易在半年后遇到写入抖动、压缩率低、历史查询慢、扩容困难等问题。本节从数据模型、写入性能、压缩策略、高可用部署四个维度，对 InfluxDB、TimescaleDB、TDengine、PI System 做工程化对比，并给出能源场景的适配判断。

一、四类数据库的定位差异

InfluxDB 是原生时序库，采用 TSM（Time-Structured Merge Tree）存储引擎，数据模型为 measurement + tag + field + timestamp，tag 建索引、field 不建索引，适合标签基数可控的场景。TimescaleDB 是 PostgreSQL 扩展，把时序表按时间分区成 chunk，保留完整 SQL 能力，适合需要与关系数据联表分析的场景。TDengine 采用“一个设备一张表”的模型，超级表定义 schema，子表按设备自动创建，写入路径针对物联网做了深度优化。PI System 是工业界老牌实时数据库，以 PI Data Archive 为核心，配合 PI AF 做资产建模，强项在于与 DCS/PLC 的稳定对接和成熟的工业生态。

选型的第一判断不是性能数字，而是“数据模型是否匹配现场对象”。能源现场天然是“设备—测点”两级结构：一台逆变器有直流电压、交流电流、有功功率、温度等测点。TDengine 的子表模型和 PI System 的位号模型对这种结构最自然；InfluxDB 需要用 tag 表达设备维度，要控制设备数量带来的序列基数；TimescaleDB 则用普通表加设备 ID 外键，最灵活但需要自己设计分区。

二、写入性能测试怎么做才有意义

写入性能不能只看厂商给的“每秒百万点”，必须按自己的数据形态压测。建议构造与现场一致的测点结构：例如 5000 个测点、每点 1 秒一个值、连续写入 30 分钟，总点数约 900 万。压测时重点观察四个指标：写入吞吐（点/秒）、P99 写入延迟、CPU 与内存占用、磁盘增长速率。

以 TDengine 为例，可用 taosBenchmark 快速构造负载：

taosBenchmark -I stmt -n 5000 -t 5000 -r 1 -T 1 -d power_db
# -n 总记录数(万) -t 子表数 -r 每子表记录数 -T 线程数
# 观察 taosd 日志中的 write throughput 与磁盘增量

InfluxDB 可用 influx write 或 line protocol 批量导入，TimescaleDB 用 COPY 或 generate_series 造数。判断写入是否健康，关键看“写入速率是否随时间衰减”。如果前 5 分钟 80 万点/秒、后 25 分钟掉到 20 万点/秒，说明 compaction 或索引维护跟不上，长期运行会持续抖动。能源场景还常遇到乱序数据——网关断点续传会把几小时前的数据补传进来，此时要测试乱序容忍度，TDengine 和 InfluxDB 对乱序窗口都有参数限制，TimescaleDB 则依赖分区设计。

三、压缩策略与保留策略

压缩直接决定三年历史数据的存储成本。能源数据的压缩要分类型处理：模拟量（电压、电流、功率）适合有损压缩，允许 ±0.5% 偏差；状态量（开关位置、告警）必须无损；电度量（kWh）需要保留累计值精度。TDengine 的列式压缩对模拟量通常能到 10 倍以上，InfluxDB 的 TSM 约 5～10 倍，TimescaleDB 开启压缩后约 3～8 倍，PI System 的旋转门压缩在变化平缓时压缩比极高。

保留策略建议分层：原始数据保留 3～6 个月，1 分钟聚合保留 2 年，15 分钟聚合保留 5 年，日聚合长期保留。这样既满足实时监视和短期追溯，又控制长期存储。以 5000 测点、1 秒采样估算：原始数据日增约 4.3 亿点，按 8 倍压缩、每点 2 字节估算，日增约 100 MB 级；若只保留 1 分钟聚合，日增降到约 720 万点，存储压力下降两个数量级。

四、高可用部署与能源场景适配

高可用的核心是“副本 + 故障切换 + 数据一致性”。TDengine 集群用多副本和 Raft 选主，节点故障时副本自动接管；TimescaleDB 通常用 Patroni + etcd 管理 PostgreSQL 流复制，配合 HAProxy 做读写分离；InfluxDB 开源版高可用能力有限，生产环境多依赖企业版或外部双写；PI System 用 PI Collective 实现多成员同步，适合对连续性要求极高的电力调度场景。

能源场景适配可以按三条线判断：一是数据规模，万点以下 InfluxDB 或 TimescaleDB 足够，十万点以上优先 TDengine；二是分析需求，需要与工单、资产、电费数据联表，选 TimescaleDB；三是工业集成，现场已有大量 PI 接口和 DCS 资产模型，继续用 PI System 迁移成本最低。实际项目中常见混合架构：TDengine 承担高频原始数据写入，TimescaleDB 承担聚合结果与业务分析，PI System 保留在核心电力监控层。

部署落地时，建议先用真实测点结构做 24 小时压测，再决定分片数、副本数和保留策略。不要用厂商基准数据直接推算，能源现场的标签基数、乱序比例和查询模式，往往才是决定数据库能否长期稳定运行的关键变量。