1. 先搞清楚时间序列数据库到底在解决什么问题
2026年开年到现在，我被问到最多的一句话就是：时间序列数据库到底选哪个。问的人背景差别很大，有做光伏电站远程监控的，有做工业视觉设备数据回传的，还有做前端埋点性能分析的。大家遇到的问题表面上看是"选型"，实际上真正卡住他们的，是没搞清楚自己手里的数据长什么样、查询长什么样、保留多久、谁来运维。选型这件事，产品参数只是一半，另一半是你自己的需求边界。
时间序列数据库（TSDB）这个概念这几年被用得很泛。严格来说，它是一类针对"带时间戳、写多读少、按时间范围聚合查询"这三点做专门优化的存储系统。它和普通关系型数据库最大的区别不是"能不能存时间"，而是它默认假设你的数据是追加写入的、几乎不更新、删除通常按时间分区整块丢。正因为这个假设，它才敢在写入路径上做大量取舍，换来高吞吐和高压缩比。
我见过太多团队栽在"用MySQL硬扛"这条路上。一开始几台设备、每秒几百个点，MySQL跑得好好的，加个索引查起来也顺。等到设备数翻十倍、采集频率从30秒提到1秒，写入开始堆积，慢查询日志一天几万条，然后开始分表、加中间件、做冷热分离，最后发现自己手搓了一个性能更差、维护成本更高的时序库。这个坑的本质是：你花在改造上的时间，早就够你把一款成熟TSDB跑起来了。
提示：如果你现在还在用关系型数据库存时序数据，并且已经出现了"按天分表""历史表归档""索引越加越多"这些症状，那就到了该认真评估TSDB的节点了，不要再往后拖。
这篇文章我想解决的是三个具体问题。第一，2026年这个时间点上，InfluxDB、TimescaleDB、VictoriaMetrics、TDengine、ClickHouse 这五款主流产品各自处在什么位置，架构上有什么本质差别。第二，面对IoT监控、可观测性、业务指标分析这几类典型场景，怎么用一套可复现的压测流程做判断，而不是拍脑袋。第三，把我在实际项目里踩过的坑整理出来，包括那些官方文档里不会写、但上线后一定会遇到的东西。适合正在做技术选型的架构师、后端工程师，也适合刚接触时序数据的运维同学。
2. 五款主流产品的定位与架构拆解
选型最怕的一件事，就是把五款定位完全不同的产品放在一张表里比参数，然后得出"A的写入比B快"这种结论。参数是在特定场景下测出来的，脱离场景没有意义。所以我想先把每款产品"为什么长成这样"讲清楚，你看完再去看参数，判断会准很多。
2.1 InfluxDB：从自研TSM引擎到IOx的存储换血
InfluxDB 是很多人接触的第一款TSDB，1.x时代的TSM Tree存储引擎加InfluxQL，简单直接，单机性能也够看。但它的老问题也很明显：标签基数（series cardinality）一高就容易内存爆炸，因为它在内存里维护了大量series索引。这个问题在设备ID、用户ID这种高基数标签场景下几乎是致命的。
到了3.0，官方直接换了引擎，用Rust重写成IOx，底层基于Apache Arrow、DataFusion和Parquet，查询语言也从Flux转向了SQL和InfluxQL，Flux在3.x里已经不是主推方向。这个转变的意义很大：它从"自研存储引擎"变成了"建立在列式格式和查询框架之上的时序层"，和ClickHouse那一派的路子开始靠近。好处是SQL生态一下子打开了，Parquet文件可以直接被外面的大数据工具读；代价是版本演进比较快，早期3.x的稳定性和功能完整度需要你关注具体小版本。
我的建议是：如果你是新项目，直接评估3.x；如果是存量1.x项目，迁移成本要单独算，因为查询语言、写入协议、客户端库都有变化。别看到"升级"两个字就以为是无痛替换。
2.2 TimescaleDB：长在PostgreSQL上的时序能力
TimescaleDB 的定位非常独特，它是一个PostgreSQL扩展，不是独立数据库。核心概念是Hypertable（超表），你建一张逻辑表，它按时间自动切成多个Chunk，每个Chunk底层还是普通PG表。这意味着什么？意味着你所有的PG技能、SQL语法、JOIN、事务、外键、现有ORM全部可以直接用。
它的连续聚合（Continuous Aggregates）是业务指标场景里非常好用的东西，可以理解成"自动增量维护的物化视图"，你定义好按小时、按天的聚合，新数据写进来它会自动更新对应的时间桶，查询直接命中预聚合结果。压缩方面用列式压缩，对历史Chunk压缩后存储能降到原来的十分之一量级。
代价是它继承了PG的一些限制。写入吞吐上限受PG的WAL和单表写入路径影响，虽然它做了很多优化，但在百万测点/秒这种极端写入场景下，和专门为写入设计的引擎比还是有差距。另外它更适合"时序数据只是我业务数据的一部分"这种场景，而不是"我要一个纯粹的指标存储"。
2.3 VictoriaMetrics：指标场景里把压缩和稳定做到极致
VictoriaMetrics 出身于监控指标这个圈子，兼容Prometheus的抓取协议和PromQL，所以从Prometheus迁过来的成本极低。它的存储引擎是自研的，走的是类似LSM的结构，主打两个点：一是高压缩比，二是单机就能扛很高写入，运维心智负担小。
我在几个项目里用它替换过Prometheus的长存储。最直观的感受是磁盘占用降得很明显，同样的指标量，VictoriaMetrics的磁盘使用通常比Prometheus本地存储低一截，查询历史数据的响应也稳。它的集群版分了vminsert、vmselect、vmstorage几个组件，可以水平扩展，但单机版其实已经能扛很大的量，很多团队根本不需要上集群。
需要说明的是，它的强项是指标（metric），也就是数值型的、带标签的、按时间聚合的数据。如果你要存的是事件、日志、或者需要复杂JOIN的业务数据，它不是合适的选择。它是把一件事做到极致的那类产品，不要指望它去做通用查询。
2.4 TDengine：一设备一表的超表建模
TDengine 是国内团队做的一款时序数据库，它的建模思路比较有辨识度：一个数据采集点一张表，多张同结构的表挂在超级表（STable）下面。这个模型对IoT场景非常自然，因为IoT的数据本来就是"设备-测点"的二维结构。它把标签（设备型号、位置等）单独存储，不占数据块空间，所以在标签基数大的情况下比早期InfluxDB更从容。
它的写入性能在单机场景下表现不错，官方一直强调高压缩和低资源占用，适合边缘侧、工控机上跑。3.0之后引入了更多分布式能力，也支持了标准SQL风格查询。生态上它和国内的工业互联网平台结合得比较多，中文文档和社区支持是它的一