5 款时序数据库：谁扛得住 1 万点/秒的厂级 SCADA
你是不是这样干的？
厂区里的 SCADA 系统、数控机床、环保网关一齐开工，一秒钟有一万多个测点（温度、压力、振动等）源源不断地往上传。
最开始，你觉得数据量不大，直接用 MySQL 存。半年后，单表数据破亿，查个历史曲线要等 2 分钟，甚至直接把 CPU 跑满锁死。
后来，你听说 MongoDB 合适，连夜重构。结果发现虽然写入勉强能顶住，但内存占用像无底洞，而且时序数据特有的“按时间降采样（Downsampling）”和“窗口聚合（Window Aggregation）”写起来极其痛苦。
你需要的是专业的“时序数据库（TSDB）”——专门对时间戳数据进行高度压缩、极速写入和多维查询的引擎。
我们实测了 5 款主流时序数据库，结论是——不要只被宣传里的“写入速度”忽悠，海量设备带来的“高基数（High Cardinality）”内存爆炸，才是时序库真正需要避开的深水炸弹。
1. InfluxDB
“时序数据库界的 MySQL，生态最好但高版本变了天”
【适合】 中小型监控项目、TIG 栈（Telegraf + InfluxDB + Grafana）极速搭建、指标标签维度较少的常规 IT 监控。
【不适合】 时间序列“高基数”场景（如百万台设备，每台有多个经常变化的动态标签）、预算受限的分布式集群部署（开源版仅支持单机，集群版需要购买商业服务）。
【评价】 InfluxDB 是时序数据库的老牌霸主。它开箱即用，周边的采集器、可视化生态好到无可挑剔，找资料最容易。但它也有两个硬伤：
版本断代严重： 1.x 版本的 InfluxQL 很好用；2.x 版本非要推行难学的 Flux 查询语言，导致社区怨声载道；最新的 3.x 版本（基于 Apache Arrow 引擎）虽然重构了底层，但开源版策略一变再变。
内存溢出（OOM）常客： 只要你的设备标签组合（Tag-Set）过多，就会导致索引“高基数”问题，内存瞬间吃满崩溃。
【关键数据】 单机版开源/集群版商业化 | 3.x 基于 Rust 与 Apache Arrow | 支持 SQL 与 InfluxQL | 压缩比约 1:5 ~ 1:8
2. TDengine（涛思数据）
“‘一表一设备’的创新设计，最懂中国工业场景的国产自研时序库”
【适合】 标准的工业物联网场景（PLC、水表、电表等固定测点结构）、边缘端硬件资源受限的网关、有数据库国产化合规要求的项目。
【不适合】 测点结构频繁变动（Schema-less）的动态场景、需要频繁进行多表跨库复杂 SQL JOIN 查询的业务系统。
【评价】 TDengine 的核心竞争力在于它对工业场景的深度定制。它创新地提出了**“一个设备一张表，超级表建分类”**的模型。因为每个设备都有独立的表，写入时完全避免了锁竞争，不仅写入速度快得惊人，而且数据压缩比极高。它对硬件资源的消耗非常低，在树莓派或者低配工控机上都能流畅跑起来。但这种设计也有局限：如果你的设备数据结构极度混乱，或者需要做互联网式的无 schema 灵活查询，它的建表和维护成本会呈指数级上升。
【关键数据】 开源分布式/商业版支持 | 独创“一表一设备”架构 | 标准 SQL 接口 | 压缩比可达 1:10 ~ 1:20 | 资源消耗仅为传统方案 1/5
3. TimescaleDB
“披着 PostgreSQL 外衣的时序怪兽，关系型和时序型‘既要又要’的最优解”
【适合】 需要频繁进行“设备台账（关系数据）+ 历史曲线（时序数据）”联合查询（JOIN）的系统、对数据完整性和事务（ACID）有硬性要求的金融/核心工业控制项目。
【不适合】 写入性能要求达到每秒数百万点以上的超大规模高频采集场景、硬盘容量和 IO 极度受限的边缘环境。
【评价】 TimescaleDB 并不是独立研发的数据库，它本质上是 PostgreSQL 的一个插件。它把 PG 的普通表虚拟成了一个个“超表（Hypertables）”，在底层自动切分时间分区。这意味着：你原有的 PG 驱动、工具链、SQL 技能全部不需要换。对于工业项目来说，最爽的就是可以一行 SQL 直接把“设备所属部门、维保记录”与“昨天的温度变化”连表查出来。但由于它底层依然背负着 PostgreSQL 关系型数据库的包袱，在超大规模的纯写入场景下，它的吞吐上限和压缩比无法与 TDengine 这样的专有列式时序库抗衡。
【关键数据】 基于 PostgreSQL 开源扩展 | 支持完整标准 SQL（含 JOIN、Window 函数）| 强 ACID 事务支持 | 压缩比约 1:4 ~ 1:6
4. Apache IoTDB（天谋科技）
“专为工业物联网（IIoT）树状物理世界深度定制的‘大国重器’”
【适合】 大型集团级工业项目、多级树状物理资产模型（如：集团 -> 厂区 -> 车间 -> 产线 -> 设备 -> 传感器）、端边云协同的超大规模数据湖。
【不适合】 纯轻量级 IT 监控（用 InfluxDB/Prometheus 更合适）、团队完全没有 Java/JVM 调优经验的团队。
【评价】 诞生于清华大学，现在是 Apache 顶级项目。IoTDB 的最大特色是**“物理树状模型”**，它可以用类似于文件路径的 root.group.factory.device.sensor 来定义和存取数据，这与工业上 PLC 的物料命名习惯高度契合。另外，它的“一键式端边云同步”对工业场景非常实用：边缘端采集用 IoTDB，断网时本地缓存，联网后自动且高压缩地同步到云端。不过，它是用 Java 编写的，在内存占用和冷启动速度上，相比 C/Rust 编写的引擎会略显沉重，需要专人进行 JVM 调优。
【关键数据】 完全开源 Apache 2.0 | Java 语言开发 | 支持原生树状路径查询 | 压缩比可达 1:10 以上 | 写入吞吐量随节点数线性扩展
5. ClickHouse
“虽然不是原生时序数据库，但暴力性能让专门的时序库都害怕”
【适合】 统一数据大池（不仅存时序，还存报警日志、业务订单）、需要秒级对数亿条历史记录进行任意维度自由多维分析（OLAP）的场景。
【不适合】 边缘端极低配置节点部署、需要极低写延迟（ClickHouse 强在批量写入，单条点写会造成严重碎片化）、需要原生内置时序降采样函数的场景。
【评价】 严格来说，ClickHouse 是一个分析型列式数据库（OLAP），但近几年越来越多的工业和 IT 架构师用它来替代时序库。它的查询性能堪称“暴力暴力更暴力”，凭借着极强的多线程并行处理和向量化执行引擎，多维聚合查询的速度经常能把专业时序库按在地上摩擦。但它对资源的要求很高，而且它不是专门针对时序设计的，所以你得自己写 SQL 去模拟“前向填充（Locf）”或“降采样”等时序专属算子。
【关键数据】 完全开源/商业版 | 列式分析型引擎 | 极强的并行查询能力 | 压缩比 1:5 ~ 1:10 | 硬件开销较大（内存和 CPU 杀手）
如果你只有 3 分钟
| 你的场景 | 选它 | 理由 |
| 设备测点结构固定，且预算有限、看重低硬件开销 | TDengine | 国产自研，独创架构，同等配置下能省 70% 的硬件和运维成本 |
| 项目有复杂的关系业务，必须做复杂的 JOIN 查询 | TimescaleDB | PostgreSQL 亲儿子，在不牺牲 ACID 事务的同时提供时序性能 |
| 大型多级厂区，需要契合工业设备树物理模型，端边云同步 | Apache IoTDB | 清华团队出品，树形路径查询极其直观，端边云架构天然契合工业 |
| 中小型 IT/网络监控项目，想要快速搭建 | InfluxDB | TIG 生态极度成熟，上手最快，网上解决方案最多 |
| 数据量极其庞大（百亿级），且需要混合日志/报警进行大数据分析 | ClickHouse | 暴力查询机器，多维分析（OLAP）性能首选 |
关键对比（注册解锁完整数据）
| 维度 | InfluxDB (2.x) | TDengine (3.x) | TimescaleDB | Apache IoTDB | ClickHouse |
| 写入吞吐量（单机） | 中等 | 极高 | 中等 | 极高 | 极高（需批量写） |
| 高基数（高Tag组合）耐受度 | 较差（极易 OOM） | 优秀（标签与时序分离） | 极好（借助 PG 关系表） | 优秀 | 极好 |
| 存储压缩比 | 1:5 ~ 1:8 | 1:10 ~ 1:20 | 1:4 ~ 1:6 | 1:10 ~ 1:15 | 1:5 ~ 1:10 |
| 查询语言 | Flux / SQL | SQL | 标准 SQL | 类 SQL | 标准 SQL |
| 边缘网关部署友好度 | 一般 | 优秀（内存占用极低） | 较差 | 良好（有轻量级版本） | 极差（不建议部署在边缘） |
| 关系型数据 JOIN 支持 | 不支持 | 较弱 | 支持（原生 JOIN） | 不支持 | 优秀 |
| 高可用集群（开源版） | 不支持 | 支持 | 不支持 | 支持 | 支持 |
| 中国市场支持与文档 | 较差 | 优秀 | 一般 | 优秀 | 良好 |
[ 注册解锁完整对比数据 ]
注册后获取——5 款时序数据库的“1万、10万、100万点/秒写入压力测试实测报告”（吞吐与 CPU 曲线）、高基数标签环境下内存暴涨临界点对比、以及“工业 SCADA 系统时序数据库选型决策树 PDF”。
时序库迁移避坑清单（注册解锁完整版）
“高基数（High Cardinality）”是第一杀手：如果你有 10,000 台设备，每台设备用“软件版本、操作员 ID、动态订单号”作为 tag/label 写入 InfluxDB，你会发现内存会在 2 小时内飙升至 64G 并直接 OOM 崩溃。
时序库更新和删除极其昂贵：时序数据库是为“追加（Append-only）”而设计的。如果你的业务场景需要频繁修改历史测点值，或者频繁执行删除，TimescaleDB 尚可顶住，而 InfluxDB 和 TDengine 会因为频繁的重写碎片（Compaction）导致磁盘 I/O 爆表，严重时直接导致系统无法写入。
单条写入（Single Write）是自杀行为：时序数据在写入时必须在客户端或中转网关（如 Telegraf、Vector）做批量（Batch）缓存后再统一提交。单条点对点写入会导致时序库的内存缓冲区无法发挥作用，磁盘写放大严重，直接拉垮写入性能。
数据来源：2026 Time-Series Database Benchmark Reports (DB-Engines); TDengine 官方测试基准文档; Apache IoTDB 社区性能评测白皮书.
