物联网平台选型时，数据库往往是最晚决定、也最容易后悔的一环。前期用 MySQL 扛着，设备量一上来就写不动、查不动、磁盘爆掉，这时候再迁移，代价是重写整个数据层。
这篇文章讲清楚三件事：什么情况下必须用时序库、四类主流方案怎么选、以及选型时最容易忽略的几个坑。
先判断：你到底需不需要时序数据库
不是所有物联网项目都要上时序库。满足下面任意两条，才值得考虑：
- 每秒写入超过 5000 个数据点，或者设备数超过 1000 台、上报频率高于 30 秒一次
- 单表数据量预期超过 5000 万行
- 查询以时间范围聚合为主（最近 7 天每小时均值、昨天最大值、本月同比）
- 需要保留 1 年以上的历史数据做趋势分析
- 需要降采样（原始数据存 3 个月，聚合数据存 3 年）
如果只是几十台设备、每分钟上报一次、只查最新值，MySQL 或 PostgreSQL 完全够用，上时序库反而增加运维负担。
一个粗略的容量估算公式：
日增行数 = 设备数 × 每台每日上报次数
比如 2000 台设备，每 30 秒上报一次，一天 2880 次/台，日增 576 万行。一年 21 亿行。这个量级 MySQL 单表肯定撑不住，必须上时序方案。
关系库为什么扛不住
不是性能不够，是三个结构性不匹配。
写入放大
关系库每次 insert 都要维护 B+ 树索引、写 redo log、更新统计信息。物联网数据是追加写入、几乎不更新，但关系库的机制是为「随机读写」设计的，用在「只追加」场景上纯属浪费。
实测中，MySQL 单机在普通硬件上写入吞吐通常在每秒几千到一两万行，且随索引数量线性下降。时序库同样硬件能做到每秒几十万到上百万点。
存储成本
物联网数据的特征是：字段少、数值重复度高、时间有序。这类数据压缩比极高。时序库通过列式存储 + 时间戳差分编码 + 数值压缩，通常能做到 5-20 倍压缩。关系库的行式存储基本压不动。
21 亿行数据，关系库可能要几个 TB，时序库可能只要几百 GB。三年的磁盘成本差就是几万到几十万。
聚合查询
「查最近 7 天每小时的平均温度和最大湿度」这类查询，关系库要先扫出全部原始行再 group by，数据量大时直接超时。时序库有专门的降采样机制和预聚合物化视图，查聚合结果和查原始数据一样快。
四类方案的真实差异
下面这几个是实际项目中用得最多的。我不做绝对的好坏判断，只说各自的适配场景和代价。
TDengine
国产时序数据库，为物联网场景设计，核心概念是「一个设备一张表」（超级表 + 子表）。
优势：
- 写入性能强，单机百万点/秒级别，集群可线性扩展
- 压缩率高，官方宣称 10 倍以上，实测在传感器数据上确实明显
- SQL 语法，学习成本低，会 SQL 就能用
- 内置流式计算（连续查询），降采样不用额外组件
- 国产化适配好，信创项目容易过审
代价：
- 生态相对新，第三方工具和社区资料比 InfluxDB 少
- 「一设备一表」的模型在设备数极大时（百万级）会带来元数据管理压力，需要合理设计超级表
- 复杂关联查询能力弱于 PostgreSQL 系
适合：设备数万到百万级、写入量大、需要国产化、团队 SQL 基础好。
InfluxDB
时序库领域知名度最高的产品，生态最成熟。
优势：
- 生态完善，各种语言的客户端、Grafana 集成、采集工具（Telegraf）齐全
- 查询语言（Flux / InfluxQL）表达力强，适合复杂分析
- 云托管服务成熟
代价：
- 开源版和商业版功能差距大，集群能力在商业版
- 2.x 引入的 Flux 学习曲线陡，3.x 又回到 SQL，版本演进路线让不少团队观望
- 高基数（tag 组合数爆炸）场景性能下降明显，设备 ID 当 tag 时容易踩坑
适合：中小规模、需要快速搭建、团队有运维能力、看重生态。
TimescaleDB
PostgreSQL 的时序扩展，本质是「PG + 时序优化」。
优势：
- 完整 PostgreSQL 能力，SQL、JOIN、JSON、地理空间、扩展生态全都有
- 业务数据和时序数据可以放在同一个库，减少架构复杂度
- 迁移成本低，已有 PG 经验的团队几乎零学习成本
- 压缩和连续聚合（Continuous Aggregates）能力成熟
代价：
- 写入吞吐上限低于专用时序库，百万点/秒级别需要较多资源
- 超大规模（百亿行以上）需要仔细设计分区策略
- 压缩后的数据不支持更新（对物联网场景通常不是问题）
适合：需要时序 + 关系混合查询、团队熟悉 PG、数据规模中等偏上、不想维护两套数据库。
ClickHouse
列式分析数据库，不是专用时序库，但在物联网分析场景用得很多。
优势：
- 聚合查询性能极强，大宽表扫描比专用时序库还快
- 压缩率高，成本低
- 适合做报表、大屏、多维分析
代价：
- 不适合高频单点写入和实时更新，写入要批量攒批
- 没有真正的时序语义（降采样、保留策略要自己实现）
- JOIN 能力弱，点查延迟高于时序库
- 运维复杂度高，集群调优需要经验
适合：以分析报表为主、写入可批量、能接受最终一致性的场景。常见做法是时序库 + ClickHouse 双写，前者管实时，后者管分析。
选型决策表
把上面的结论压缩成一张表，按自己的情况对号入座：
| 你的情况 | 建议 |
|---|---|
| 设备 <500 台，只查最新值 | MySQL / PostgreSQL 够用，别折腾 |
| 设备 1000-5 万台，写入为主，要国产化 | TDengine |
| 设备 1000-5 万台，团队熟 PG，要混合查询 | TimescaleDB |
| 中小规模，快速上线，看重生态 | InfluxDB |
| 以报表大屏为主，写入可批量 | ClickHouse |
| 设备 >50 万台，写入极高 | TDengine 集群，或时序库 + Kafka + ClickHouse 分层 |
| 信创/政务项目 | TDengine（国产化适配最完整） |
选型时最容易忽略的五个坑
坑一：没算保留期，磁盘规划错了
很多人只算日增量，忘了乘保留天数。2000 台设备日增 576 万行，保留 1 年是 21 亿行；保留 3 年是 63 亿行。规划时按 3 年算，别按 1 年。
同时要设计分层保留：原始数据存 3-6 个月，1 分钟聚合存 1 年，1 小时聚合存 3 年。这样既满足分析需求，又控制成本。
坑二：把设备 ID 当 tag，高基数把库拖死
InfluxDB 这类基于 tag 索引的库，tag 的每个唯一组合都会建索引。设备 ID 作为 tag，10 万台设备就是 10 万个序列，加上其他 tag 组合，很容易到百万级，内存直接爆。
正确做法：设备 ID 作为 field 或者用专门的设备维度表，tag 只用低基数字段（设备类型、区域、状态）。
坑三：忽略时间精度和时区
物联网数据的时间戳精度通常是毫秒或微秒。如果存储层只支持秒级，同一秒内的多条数据会冲突。
时区更麻烦：设备上报 UTC，平台展示北京时间，数据库存哪个？建议统一存 UTC，展示层转换。混着存后期必然出错。
坑四：没考虑乱序数据
设备网络抖动、离线补传，会导致数据到达顺序和时间戳顺序不一致。有些时序库对乱序写入支持不好，会拒绝或者性能骤降。
选型时明确问一句：支持多长时间的乱序写入？大多数场景要求至少支持 1 小时内的乱序。
坑五：把时序库当业务库用
时序库擅长「按时间查数值」，不擅长「按条件查记录」。比如「查询所有状态为异常的、属于 A 区域的、今天新装的设备列表」——这类查询在时序库上要么写不出来，要么极慢。
正确架构：业务数据（设备档案、用户、工单、告警记录）放关系库，时序数据放时序库，中间用设备 ID 关联。别指望一个库解决所有问题。
一个实际项目的架构
某园区项目，3000 台设备，30 秒上报，保留 3 年。最终架构：
- 接入层：EMQX 集群，3 节点
- 缓冲层：Kafka，削峰 + 解耦
- 时序存储：TDengine 3 节点集群，原始数据保留 6 个月，1 分钟聚合保留 1 年，1 小时聚合保留 3 年
- 业务库：PostgreSQL，存设备档案、告警、工单、用户
- 分析层：ClickHouse，存宽表，支撑大屏和报表
这套架构的日增数据约 860 万点，TDengine 三节点写入压力不到 20%，磁盘三年预估 1.2TB（压缩后）。如果换 MySQL，同样数据量三年要 15TB 以上，而且聚合查询基本不可用。
迁移建议
如果已经在用关系库存时序数据，想迁移，建议路径：
- 先双写：新数据同时写关系库和时序库，跑两周对比一致性
- 再切读：查询逐步切到新库，保留关系库兜底
- 最后迁移历史：按时间分批迁移历史数据，不追求一次迁完，迁最近 6 个月通常就够
- 停写旧库：确认新库稳定运行一个月后再停
不要想着停机迁移，物联网数据是 7×24 产生的，没有停机窗口。
需要具体建议
如果你的项目正在做数据库选型，可以把设备数、上报频率、保留期、查询需求发给我们，我们帮你算一下容量和成本，给一个具体方案。这类判断错一次，后面迁移的代价是重写数据层。