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 是很多人接触的第一款TSDB1.x时代的TSM Tree存储引擎加InfluxQL简单直接单机性能也够看。但它的老问题也很明显标签基数series cardinality一高就容易内存爆炸因为它在内存里维护了大量series索引。这个问题在设备ID、用户ID这种高基数标签场景下几乎是致命的。到了3.0官方直接换了引擎用Rust重写成IOx底层基于Apache Arrow、DataFusion和Parquet查询语言也从Flux转向了SQL和InfluxQLFlux在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风格查询。生态上它和国内的工业互联网平台结合得比较多中文文档和社区支持是它的一 2026 TSDB选型：五大时序数据库架构对比与实战
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 是很多人接触的第一款TSDB1.x时代的TSM Tree存储引擎加InfluxQL简单直接单机性能也够看。但它的老问题也很明显标签基数series cardinality一高就容易内存爆炸因为它在内存里维护了大量series索引。这个问题在设备ID、用户ID这种高基数标签场景下几乎是致命的。到了3.0官方直接换了引擎用Rust重写成IOx底层基于Apache Arrow、DataFusion和Parquet查询语言也从Flux转向了SQL和InfluxQLFlux在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风格查询。生态上它和国内的工业互联网平台结合得比较多中文文档和社区支持是它的一