时序数据库与工业存储专题

时序数据库(Time-Series Database, TSDB)是专门为处理带时间戳的数据设计的数据库。和关系库的核心区别：① 写入模式——时序数据是按时间顺序的追加写，几乎不更新删除，关系库是随机读写；② 存储引擎——时序库用 LSM-Tree 等写优化引擎和列式存储，关系库用 B+树行存；③ 压缩——时序数据规律性强，专用压缩算法能达到 5-20 倍压缩比；④ 查询——时序查询几乎都带时间范围和分组聚合，时序库对此做了专门优化；⑤ 自动功能——时序库内置数据保留策略、自动降采样、时间分区，关系库需要自己实现。简单说，关系库是万能的但在高频时序场景性能差，时序库是专用的在时序场景性能好几十倍。

小规模、低频采集(几百点、几秒一次)用 MySQL 也能跑，但随着点位和时间增长会遇到几个硬伤：① 写入性能——1000 个点每秒采集一次就是每天 8640 万条，MySQL 单表几百万行后写入和查询明显变慢；② 查询性能——查一个月的趋势数据，MySQL 需要扫描几百万行做聚合，可能要几十秒，时序库用降采样数据几秒返回；③ 存储成本——MySQL 行存压缩比低，时序库列存+专用压缩能省 5-10 倍存储空间；④ 运维复杂度——MySQL 需要自己做表分区、数据清理、归档，时序库内置保留策略和自动降采样。经验上，点位超过 500、采样频率高于 10 秒、数据需要保留超过 3 个月，就应该考虑用时序数据库。如果已经用了 MySQL，也可以用时序库做历史数据存储，MySQL 只存最新状态和配置。

两者都是优秀的开源时序库，选型取决于具体场景：① 国产替代和自主可控——TDengine 是国产开源，集群版完全开源，中文文档和社区好，信创环境首选；InfluxDB 集群版是商业的，单机版开源。② 性能——TDengine 是 C 语言开发，写入和查询性能极高，尤其是在工业场景的「一个采集点一张表」模型下；InfluxDB 是 Go 语言，性能也很好但略逊于 TDengine。③ 生态——InfluxDB 生态更成熟，Telegraf 采集器+Grafana 可视化+Kapacitor 告警是监控领域经典组合，第三方集成多；TDengine 生态在快速完善，原生支持 Grafana，也有自己的采集方案。④ 部署运维——TDengine 自带消息队列和缓存，架构更一体化，集群部署相对简单；InfluxDB 组件更多(InfluxDB+Telegraf+Kapacitor)，但每个组件都很成熟。⑤ 工业场景——TDengine 从设计之初就面向工业物联网，「一个数据采集点一张表」的模型和工业场景天然契合，国内工业项目落地案例多。建议：国产替代/工业场景/追求极致性能选 TDengine；监控运维/生态成熟/团队已有 InfluxDB 经验选 InfluxDB。两者都可以先做 POC 测试再决定。

保留策略(Retention Policy, RP)是时序库的核心功能之一，它定义了数据保留多长时间，到期后自动删除。设置原则：① 按数据价值和查询频率分层——高频原始数据(1 秒级)保留 7-30 天，因为超过这个时间范围的查询很少看原始精度；1 分钟降采样保留 3-6 个月；1 小时降采样保留 1-3 年甚至更久。② 降采样和保留策略配合——先做降采样(1 秒→1 分钟→1 小时)，再对不同精度设置不同保留期，这样既省空间又不丢长期趋势。③ 自动删除是安全的——保留策略删除的是超过保留期的原始数据，降采样数据不受影响；删除前确保已经做了降采样和备份。④ 重要数据额外备份——对不能丢失的数据(如合规要求保留 5 年)，定期用 taosdump 等工具备份到对象存储或磁带，不要只依赖在线存储。⑤ 监控删除过程——设置告警，确保保留策略按预期运行，不会因为配置错误导致数据误删。简单说：保留策略不会「丢数据」，它删除的是你明确告诉它可以删除的过期原始数据，长期趋势数据通过降采样保留。

时序数据库的存储容量取决于数据规模、压缩比和保留策略。容量规划公式：① 原始数据日增量 = 点位数 × 每秒采样次数 × 每点字节数(通常 10-20 字节含时间戳和标签) × 86400；② 压缩后存储量 = 原始数据量 ÷ 压缩比(通常 5-10 倍，具体看数据规律性)；③ 总存储 = 压缩后日增量 × 保留天数 × (1 + 降采样数据量 10-20%) × 1.3(预留余量)。举例：1000 点、1 秒采样、每点 16 字节，日增量 = 1000×1×16×86400 = 1.38GB/天，压缩 8 倍后约 172MB/天，保留 90 天约 15GB，加上降采样和预留约 25GB。磁盘满了的应对：① 立即告警——设置磁盘使用率告警(80% 警告，90% 严重)；② 缩短保留期——临时缩短高频原始数据的保留期，释放空间；③ 扩容——增加数据节点或扩容磁盘，TDengine 等支持在线扩容；④ 归档——把冷数据备份到对象存储/磁带后从在线库删除；⑤ 降采样——如果还没做降采样，立即做，降采样数据量只有原始数据的几十分之一。关键是提前规划，不要等磁盘满了才处理。

大部分时序数据库都支持类 SQL 查询，但和 MySQL 的标准 SQL 有差异：① TimescaleDB 是 PostgreSQL 扩展，支持完整标准 SQL，包括 JOIN、子查询、窗口函数等，和 MySQL 最接近，学习成本最低；② TDengine 支持类 SQL，语法和 MySQL 很像，支持 where/group by/order by/limit/聚合函数，但不支持 JOIN(用超级表和标签代替)，有自己特有的时间相关函数；③ InfluxDB 1.x 支持 InfluxQL(类 SQL)，2.x 主推 Flux(函数式查询语言)，也支持 InfluxQL；④ Apache IoTDB 支持类 SQL，语法和 MySQL 类似；⑤ QuestDB 支持标准 SQL，扩展了时间相关功能。时序查询的特点：① 几乎所有查询都带时间范围(where ts > now() - 7d)；② 常用聚合函数(avg/max/min/count/sum/first/last)；③ 分组 by time(1m) 做时间维度聚合；④ 按标签(tag)分组过滤。和 MySQL 的主要区别：① 不支持或弱化 JOIN(时序库用宽表和标签代替关系型的 JOIN)；② 有更多时间相关函数和聚合；③ 事务支持弱(时序库大多不支持复杂事务，因为追加写不需要)；④ 不建议用 select *，要明确指定时间范围和列。总体来说，会 MySQL 的 SQL，时序库的 SQL 半天就能上手，主要是理解时间聚合和降采样的概念。

边缘端可以用时序数据库，而且是工业物联网的常见架构。边缘端时序库的选择和资源占用：① TDengine 有边缘版，资源占用低(几百 MB 内存)，支持 ARM 架构，适合在边缘网关和工控机上运行；② InfluxDB 也可以在边缘端运行，但资源占用比 TDengine 高一些；③ SQLite 也可以在边缘端做轻量时序存储，但点位多了性能不够；④ 还有专门的边缘时序库如 EdgeDB、rqlite 等。边缘端时序库的典型用法：① 本地缓存——边缘端采集数据先存本地时序库，网络中断时不丢数据，网络恢复后同步到云端；② 本地查询——边缘端做本地监控和告警，不需要连云端；③ 边缘计算——在边缘端做数据预处理和降采样，只把需要的数据上传云端，节省带宽。端云配合架构：① 边缘端采集→边缘时序库本地存储→数据同步(TDengine 有数据订阅功能，或用 MQTT/Kafka)→云端时序库长期存储和分析；② 边缘端只存最近 7-30 天的高频数据，云端存长期降采样数据；③ Grafana 可以同时查询边缘和云端时序库，做统一可视化。资源规划：边缘网关(ARM 4 核 2GB)可以跑 TDengine 边缘版，支持几千点 1 秒采样；工控机(x86 4 核 4GB)可以跑完整版 TDengine/InfluxDB，支持几万点。