2. 时序数据库选型：InfluxDB vs TimescaleDB vs TDengine
说实话，做电力数据存储这些年，我踩过不少坑。选时序数据库这事儿，真不是看个排行榜就能定的。我见过有人用MySQL硬扛千万级测点，结果查询慢到怀疑人生；也见过盲目上InfluxDB，结果发现聚合查询根本跑不动。
今天咱们就掰扯清楚：InfluxDB、TimescaleDB、TDengine，到底该怎么选？
2.1 先说说我的选型原则
我个人习惯，选型前先问自己三个问题：
- 数据量有多大？ 每天几百万测点？还是几十亿？
- 查询模式是什么？ 实时看曲线？还是做历史聚合分析？
- 团队技术栈是什么？ 全员SQL熟手？还是愿意学新东西？
你想想看，这三个问题问完，基本能筛掉一半选项。
核心观点：没有最好的数据库，只有最合适的。选型本质是 trade-off。
2.2 InfluxDB：老牌时序数据库
InfluxDB 是我最早接触的时序数据库。2017年那会儿，我负责一个光伏电站项目，每天要存几千万个测点。当时选的就是 InfluxDB 1.x 版本。
优点很明显：
- 专为时序设计，写入性能极好
- 自带数据保留策略，自动过期清理
- 查询语法简单，学习成本低
但坑也不少：
- 集群版是商业收费的，开源版只能单机
- JOIN 操作基本别想，关联查询很痛苦
- 2.0 版本改得太大，升级迁移很折腾
我的经验：InfluxDB 适合中小规模场景，单机扛个几百万测点还行。但如果你要做跨测点的复杂分析，它真的不太行。
2.3 TimescaleDB：披着SQL外衣的时序库
TimescaleDB 本质上是个 PostgreSQL 插件。我第一次用的时候，心里想的是：这不就是个带分区的PG吗？
后来真用上了才发现，它把时序场景优化得挺到位。
优势：
- 完全兼容 PostgreSQL，SQL 随便写
- 支持 JOIN、窗口函数、CTE 等复杂查询
- 自动分区 + 压缩，存储效率不错
劣势：
- 写入性能不如 InfluxDB 和 TDengine
- 数据量上亿后，查询会明显变慢
- 需要懂 PostgreSQL 调优，不然容易翻车
避坑指南：我曾经在一个项目里，用 TimescaleDB 存了 10 亿条数据。结果聚合查询跑了 30 秒还没出结果。后来发现是 chunk 大小没调好，索引也没建对。嗯，调优是个细活。
2.4 TDengine：国产新秀，专为物联网设计
TDengine 是涛思数据的产品。我第一次接触是 2020 年，当时觉得这玩意儿挺有意思——它把时序数据当成一种特殊的数据类型来处理。
亮点：
- 写入性能极强，单机每秒能写几百万测点
- 查询速度很快，尤其是聚合查询
- 自带超级表，天然支持设备分组
- 开源免费，集群版也免费
不足：
- 生态还在建设中，周边工具少
- SQL 语法和标准 SQL 有差异
- 对复杂查询支持有限
我的感受：TDengine 在电力场景下表现确实不错。特别是做设备级聚合时，超级表的设计让代码量少了一半。
2.5 三款数据库的横向对比
| 对比维度 | InfluxDB | TimescaleDB | TDengine |
|---|---|---|---|
| 写入性能 | 高 | 中 | 极高 |
| 查询性能 | 中 | 中高 | 高 |
| SQL 兼容性 | 低（类SQL） | 高（完整SQL） | 中（类SQL） |
| 集群能力 | 商业版支持 | 原生支持 | 原生支持 |
| 学习成本 | 低 | 中（需懂PG） | 中 |
| 生态成熟度 | 高 | 高 | 中 |
| 适用规模 | 中小规模 | 中大规模 | 大规模 |
2.6 电力场景下的选型建议
说了这么多，到底怎么选？我给出几个典型场景：
- 变电站监控系统：测点数量中等（几万到几十万），查询以实时曲线为主。我建议用 InfluxDB，简单够用。
- 电网调度系统：数据量大（千万级），需要做复杂分析。TimescaleDB 更合适，SQL 灵活。
- 新能源场站：测点极多（上亿），需要高性能写入和聚合。TDengine 是首选。
一个小技巧：如果你不确定选哪个，可以先做个小规模压测。我习惯用 100 万条数据，分别写入三个库，看看写入速度和查询响应。半小时就能出结果。
2.7 总结
选型这事儿，说白了就是看场景。InfluxDB 适合快速上手的小项目，TimescaleDB 适合需要复杂查询的中型项目，TDengine 适合大规模物联网场景。
我个人建议：如果你团队 SQL 能力强，优先考虑 TimescaleDB；如果追求极致性能，选 TDengine；如果只是小规模试点，InfluxDB 够用。
嗯，最后说一句：别迷信任何数据库。选型只是开始，真正的挑战在运维和调优上。