从2017年第一次被物联网项目的千万级采样点搞到半夜扩容到2026年站在新的选型节点上重新把几款主流时序数据库拉出来实测我对“时间序列数据库选型”这件事的判断已经彻底变了性能不再是第一瓶颈数据模型、运维成本、生态兼容性和授权模式才是真正决定项目生死的东西。这篇分享不是拿官方文档凑数的清单式对比而是我结合多个真实项目、五款主流产品——InfluxDB、TimescaleDB、Prometheus、TDengine、VictoriaMetrics——在实际场景里的取舍记录适合正在做技术选型、或者被时序数据存储折磨的工程师参考。1. 时序数据不是“大号日志”先统一三个基础认知很多团队在选型前就搞错了一个前提以为时序数据库就是把数据按时间存起来于是拿MySQL、MongoDB硬扛或者反过来觉得“反正是时序随便选一个开源库就行”。这两种极端我都见过代价都很惨。先花点篇幅把时序数据的三个基础认知对齐后面所有对比才有意义。1.1 时序数据到底有什么特殊之处时间序列数据最核心的特征是写多读少、追加为主、时间有序、生命周期有限。以工业设备为例一台设备每5秒上报一组数据温度、振动、电流等一天就是17280条记录一万台设备一天就是1.7亿条。这些数据几乎不会单独修改某一条只会持续追加查询也不会随便跳着查基本都是按时间范围做区间扫描配合设备维度的过滤和聚合。普通关系型数据库在这里遇到的第一个麻烦是存储模型。MySQL按B树组织数据索引更新有开销写入一高磁盘随机I/O和WAL竞争立刻成为瓶颈更别提没有“时间分区”的概念数据老化删除要靠定时任务手动DELETE删除几亿行记录本身就是灾难。第二个麻烦是数据特征不匹配时序查询里大量用到时间窗口聚合一分钟平均、一小时最大关系型数据库要么全表扫描要么提前建大量冗余聚合表维护成本直接爆炸。1.2 “能存时间字段”不等于“时序数据库”我经常遇到有团队说“我们用PostgreSQL存时间戳加个索引也挺好”。这个说法在小数据量、低频写入的场景下成立但如果把一天几千万条的点位数据灌进一张普通PG表很快会发现几个问题数据膨胀快、清理任务重、聚合查询慢、索引越来越大。TimescaleDB能解决这些问题但它的本质是“给PG补上时序能力”而不是把PG变成另一个专用存储——这一点在后文会细说。判断一个存储是不是真正的时序数据库看三件事第一存储引擎是否针对append-only写入做了优化第二是否原生支持时间分区/分片和自动数据老化TTL第三是否内置降采样、连续聚合这类时间窗口计算能力。满足这三点才算一个合格的时间序列数据库。1.3 选型的第一步不是比功能是先画数据模型我说的数据模型不是概念上的ER图而是三张表写入模型每秒多少点位、峰值多少、查询模型查询频率、窗口大小、是否涉及关联分析、生命周期模型数据保留多久、多老的数据需要降采样、是否需要回溯历史。只有先回答这三个问题才能判断该选谁。举个例子一个纯粹的Prometheus监控体系每天产生约200 GB原始指标数据保留15天这样的负载和“一亿台智能电表每15分钟上报一次需要按用户维度做灵活聚合”的负载在数据模型上完全是两个物种。下面的所有产品对比都是基于不同负载形态来讨论的。2. 五款产品家底拆解它们想解决的问题本就不一样2.1 InfluxDB生态最完整的老牌通用时序库InfluxDB是很多人接触的第一款时序数据库也是过去十年里生态最完整的通用型时序库之一。它从1.x时代的TSM存储引擎到2.x引入Bucket和Flux查询语言再到3.x拥抱Parquet和对象存储一路走来一直都在改。它最大的优势是“开箱即用”自带数据采集器Telegraf、可视化面板Chronograf后来合并为InfluxDB UI、告警规则和权限管理非常适合中小团队快速搭建一套完整的时序数据平台。但InfluxDB有个著名的“高基数之痛”每条时序序列由measurement、tag set和field set共同定义tag的每一种组合都对应一条独立序列内存中要维护这些序列的索引。当tag组合数量过大时内存会被撑爆。我的第一个InfluxDB生产事故就死在这里——把客户端请求ID塞进了tag几千万个独立序列直接让服务端OOM。后来的版本在索引上有所优化但这个坑依旧存在选型时必须评估自己数据的基数规模。2.2 TimescaleDB藏在PostgreSQL里的时序能力TimescaleDB不是独立的数据库软件而是一个PostgreSQL扩展。它通过hypertable超表把一张逻辑大表按时间自动切成许多chunk每个chunk本质上还是标准的PG表所以它保留了PostgreSQL的全部优点完整的SQL、事务、JOIN、丰富的数据类型和生态工具。这意味着如果业务数据本来就在PostgreSQL里又需要附带存储一些高频采样数据TimescaleDB能让你在一套系统里用SQL同时处理业务数据和时序数据省掉跨系统ETL。它的压缩机制也很有特色当chunk中的数据变为“只读”之后可以启用列式压缩实测在很多标签重复度高的业务场景下压缩率能到90%以上。连续聚合continuous aggregates则把降采样预计算做成了自动任务查询高频窗口时可以直接命中预聚合结果。代价是它的写入吞吐上限不如那些为append-only设计的专用LSM/列式引擎在高写入速率和超高基数的极端压力下需要很仔细地调chunk间隔和索引策略否则容易在PG主进程上撞到瓶颈。2.3 Prometheus监控场景的“事实标准”但别把它当通用数据库Prometheus在容器监控领域是无可争议的事实标准但它和前面两款不是一类东西。它本质上是一套“指标抓取告警存储”的一体化监控系统通过HTTP周期性拉取目标暴露的指标在内存中维护最近2小时的Head Block然后周期性写入磁盘、压缩合并成Block默认本地保留15天。Prometheus最大的价值是它的数据模型和PromQL查询语言指标名标签构成序列PromQL能用极简的语法完成速率、分位数、多指标运算等监控场景的高频查询这套生态已经被所有主流监控产品兼容。但它不适合做通用时序存储没有原生的SQL没有复杂权限管理本地存储单机扩展性有限长期历史数据需要借助Thanos或VictoriaMetrics之类的远端存储。如果项目场景是“我要存能设备上报的数据并做数据分析”直接上Prometheus是把屠龙刀当菜刀用后面会很难受。2.4 TDengine面向物联网的超级表设计TDengine在国内物联网领域存在感很强它最大的设计亮点是“一设备一张表”加“超级表STable”。超级表是一个逻辑表按标签定义设备维度比如站点、设备类型、地区每个设备对应一张独立的子表子表数据按时间排序存储。查询时通过超级表按标签过滤可以自动路由到多个子表并行扫描这种设计对“成千上万设备采集数据、按设备分组聚合”的物联网场景非常友好也是它在很多国产IoT项目里中标率高的原因之一。TDengine 3.x之后用C语言重写了存储和计算引擎原生支持SQL内置了流式计算、数据订阅、降采样等能力。相比传统时序库它的部署更轻对服务器配置要求也更低。不过需要特别注意的是TDengine在不同版本上的开源版和商业版功能范围有差异集群、副本等能力请务必对照官方当前授权确认。选型时如果业务主要集中在大规模IoT点位采集TDengine的优势可以充分释放但如果你需要频繁做复杂的多表关联分析它并不比成熟的SQL引擎强。2.5 VictoriaMetricsPrometheus兼容路线上的性能天花板VictoriaMetrics是我个人在监控场景里用得最多、也最敢拍胸脯推荐的一款。它本质上是“Prometheus兼容高可用/高性能存储”对外兼容Prometheus的remote write协议和PromQL查询但底层存储完全自研单节点就能支撑很高的写入吞吐。我们在一个32C64G的单节点上压测过写入速率跑到80万points/sCPU和磁盘IO还留有余量这个性价比在同类方案里相当突出。它的集群版拆成vminsert、vmselect、vmstorage三组件支持多租户和水平扩展单节点版又有极其出色的资源使用效率实测同样负载下VictoriaMetrics的内存占用通常只有原生Prometheus的一半左右。另外它内置了 vmagent 作为采集器天然支持服务发现和指标抓取还能直接承接已有的Prometheus配置。可以说凡是原本准备用Prometheus做大规模监控的团队在存储层换成VictoriaMetrics基本都是无痛迁移而且能明显改善性能和历史数据保留能力。2.6 还有一个大家都爱提的ClickHouse严格来说ClickHouse不是时序数据库而是列式OLAP数据库但它经常在时序场景里被当作“大容量存储”使用。它的写入吞吐非常夸张压缩率高SQL能力强很多团队用它统一处理日志和指标。代价是它缺少原生的时序语义没有内置的TTL策略需要用表分区和定时删除手工模拟、没有标准的时序写入协议、降采样和连续聚合需要自己建物化视图。所以我的态度是如果团队已经有很重的ClickHouse且不介意额外工作量可以考虑混用但全新项目为时序数据引入ClickHouse等于主动放弃了一堆现成能力。3. 四张表把差异一次讲清楚别只看基准测试现在的时序数据库厂商发布基准测试时经常出现“我写入500万points/s是世界第一”的宣传。真到了业务里写得快只代表你写入环节没有瓶颈压缩率、查询延迟、部署复杂度、团队技能匹配度才是决定项目长期运维感受的关键。3.1 写入吞吐与存储引擎对比产品存储引擎典型写入方式适合负载规模InfluxDBTime-Structured Merge TreeTSM批量写入/HTTP Line Protocol中小规模单体写入轻松支撑每秒数万~数十万点数TimescaleDBPostgreSQL行存储列式压缩批量INSERT中大规模依赖表结构和Chunk调优Prometheus自研时序TSDBBlock Compaction拉取抓取批量Append单机建议百万序列以下TDengine列式存储按设备分表SQL/批量写入大数据量IoT场景横向扩展能力强VictoriaMetrics自研列式存储分桶索引Prometheus remote write单节点即可达数十万~百万points/s从写入模型能看出一个核心差异InfluxDB、TDengine、VictoriaMetrics都针对append-only做了专门的存储设计写入路径短、合并开销小TimescaleDB本质还在PG的事务和索引体系内写入上限受制于行存储特性如果一定要追求极致写入需要花精力做批量提交和分区规划——但好处是和业务数据打通这笔账在不同项目里结论不同。3.2 压缩率与存储成本存储成本在时序场景直接和保留期限挂钩。时序数据重复度高相邻时间段内数值变化不大所以列式压缩和delta-of-delta编码记录相邻时间戳差值的变化量能大幅降低磁盘占用。我的经验值如下InfluxDB的TSM引擎在默认配置下压制工业传感器数据通常在8~15倍左右取决于一样数据的波动程度。TimescaleDB需要等chunk变为只读后触发压缩压缩率普遍能到90%以上但要注意压缩后的查询性能需要通过segmentate索引来保障。Prometheus本地存储压缩也做得好但它的设计目标是短周期存储长期保留成本需要配合远端存储解决。TDengine因为按设备、按时间紧凑排序存储压缩率高我实测过一组24小时温度曲线数据磁盘占比大概是原始文本的十分之一左右。VictoriaMetrics在压缩算法上很激进我对比过同批Cassandra导出数据磁盘占用约为前者的三分之一到四分之一。压缩率会影响选型吗会。如果业务要求保留三年以上的秒级数据压缩率差一倍的存储成本可能就是几十万和上百万的差别这一点必须在选型前用真实数据做一次压测评估不能只看厂商给的理论值。3.3 查询能力与实际手感产品查询语言优势场景InfluxDBInfluxQL / SQL3.x监控指标、IoT点位查询API成熟TimescaleDBSQL与时序关联的业务分析、数据科学场景PrometheusPromQL实时监控、告警规则、速率和分位数计算TDengineSQL 时间窗口函数物联网聚合查询、设备明细、流式计算VictoriaMetricsPromQL / MetricsQL大规模监控查询、告警场景选择查询语言本质上是在选择“谁来使用这些数据”。如果数据要进入BI平台、数据分析师要用SQL做探索性分析TimescaleDB或TDengine会更顺如果数据只服务于监控大屏和告警PromQL完全够用而且MetricSQL的语法表达能力在监控领域非常成熟。最怕的情况是“监控团队用Prometheus、大数据团队又要这份数据双方各查各的”导致数据要双写两份运维复杂度翻倍。3.4 部署、高可用与团队技能要求InfluxDB单机一键启动高可用需要企业版或自行解决生态组件齐全官方文档丰富中小团队上手最快。TimescaleDB如果你的团队已经熟练PostgreSQL几乎零学习成本但高可用是基于PG的主从/复制方案对PG运维本身就有要求。Prometheus部署很简单但单机有状态、本地存储不好扩展高可用通常要背一个Thanos或VictoriaMetrics架构复杂度一下就上来了。TDengine安装包小、起服务快运维轻量集群版和副本能力需要结合授权支持范围评估。VictoriaMetrics单节点就是一个二进制文件部署极简单集群版组件分工清晰运维也不算难但对监控体系vmagent、vmselect各角色要有基本认识。4. 场景适配判断四个真实项目我分别选了谁4.1 场景A容器/基础设施监控——选Prometheus VictoriaMetrics一个比较典型的Kubernetes集群监控项目节点上百个Pod上千每个节点采集CPU、内存、磁盘、网络等宿主指标再加上容器和中间件的指标序列规模在百万级。如果直接用原生Prometheus本地存储压力大历史查询容易拖垮IO更别说要保留半年以上的容量规划数据。我的方案是采集层保留Prometheus exporter和服务发现机制存储层用VictoriaMetrics单节点让Prometheus通过remote write写入同时用vmagent替代部分采集角色统一对接到VictoriaMetrics。这样既保住了PromQL和告警规则生态又解决了性能和历史数据问题。整个迁移过程基本平滑没有改任何告警规则。4.2 场景B千万级IoT设备数据——选TDengine另一个场景是智能表计类项目几百万台设备每5分钟上报一次数据每天约1.5亿点位查询大多按设备维度取最近一天或一周的曲线偶尔要做区域聚合。在这个场景里TDengine的超级表模型堪称量身定做每台设备一张子表标签做设备维度天然规避了InfluxDB的高基数问题SQL聚合也能直接打到多张子表上并行执行。实际运行下来几十台普通服务器就能扛住千万点位的写入和查询维护成本比之前用MongoDB集群低了一个数量级。要说缺点也有——团队需要重新理解“子表/超级表”的模型不能照搬关系型建模习惯但这种学习成本相对收获是值得的。4.3 场景C业务数据时序数据混合查询——选TimescaleDB还有一些偏业务系统的场景比如设备运行记录需要和订单、客户、工单等关系型数据频繁做关联查询这时候我不建议再引入一套独立时序库做跨系统同步更稳妥的方案是把时序采样数据直接放进TimescaleDB。例如一个智慧园区项目设备传感器数据要跟商户信息、合同周期关联分析TimescaleDB的hypertable允许你在SQL里直接JOIN业务表和时序表开发效率极高。这个场景不需要顶级的写入吞吐一天的数据量也就几千万条TimescaleDB完全扛得住况且还能享受PostgreSQL生态里的所有扩展。要注意的是chunk间隔设置我通常会根据数据量和保留周期把chunk大小控制在500MB到1GB左右让压缩和查询都处于相对最优的状态。4.4 场景D快速原型和中小规模统一存储——选InfluxDB如果项目周期短、数据量不大比如单机几十万点位以内、团队希望快速把“采集-存储-展示-告警”整条链路跑起来InfluxDB仍然是我会优先考虑的选择。它的Telegraf插件生态覆盖了大多数常见数据源一条命令就能接入系统指标、日志、数据库监控等UI面板也够用。不过我会额外做两件事提前估算基数上限把tags数乘上每个tag的基数做到心中有数以及把保留策略和降采样规则在项目第一天就设计好避免后期无限膨胀。InfluxDB的坑不在功能缺失而在前期太容易上手导致后面数据模型混乱。5. 选型前必须避开的五个坑5.1 高基数比数据量大更致命前面反复提到高基数问题这里再多说一句。很多团队评估数据量时只看“每天多少GB、多少条记录”却忽略了序列数量。在InfluxDB里一个基数一亿的库即便总数据量不大内存也会先撑不住在Prometheus里高基数的告警规则和查询会让查询引擎内存暴涨。我见过最典型的错误是把用户ID、订单号这类高离散值放进tag/label字段里直接制造出上亿序列。请把高基数维度拆出去放进field或者另建明细表而不是作为序列标识。5.2 只顾写入快没算保留策略和降采样的账时序库的写入性能普遍不是瓶颈容易出问题的是数据的“生命周期管理”。一个常见的场景线上环境所有点位都按秒级采集并存了一年结果发现热数据查询变慢、存储成本翻了几倍而真正高频查询的只有最近一周的秒级数据和更早的小时级聚合数据。好的做法是从一开始就设置多级保留策略秒级数据保留30天分钟级降采样保留半年小时级降采样长期保留。InfluxDB、TimescaleDB、TDengine都有现成的降采样/连续聚合能力重点是选型时就要确认这些能力在你要用的版本里是可用的、够用的别等上线后才发现要自己写定时任务去搬数据。5.3 Prometheus的本地存储不是保险箱如果团队选择Prometheus作为唯一时序存储我建议一定要做历史数据外置方案。Prometheus本地存储本身的设计目标就是短周期、服务发现场景磁盘损坏、误删Pod导致的数据丢失并不少见。很多团队以为Prometheus有副本或集群能力其实官方原生组件没有内置集群所谓的HA只是双跑负载均衡数据仍是多份独立副本而非强一致。真要在监控场景长期运行建议从一开始就规划好remote write到VictoriaMetrics或Thanos避免一年后数据量上来再被迫迁移。5.4 开源版与商业版的功能裁剪差异这个问题在国内产品上尤其要留意。几家数据库的开源版和商业版在集群管理、告警通知、数据复制、权限控制等方面存在差异有的甚至把核心集群能力放进了商业版。选型时不要只看官网首页的功能大图而是进入下载页和文档里确认“你准备部署的版本到底支不支持这些功能”。同时把License条款也看清楚有些开源项目虽然开放源码但对云厂商和嵌入式场景有额外限制公司产品如果涉及对外分发务必提前让法务参与评估。5.5 团队学习成本容易被低估我见过不止一个团队因为“某数据库性能第一”选型结果运维团队没人熟悉该产品的调优参数遇到一次节点故障恢复流程全靠翻社区帖线上恢复时间以小时计。选型一定要把团队技能栈算进去如果团队都是PG背景TimescaleDB是零门槛如果团队对Prometheus生态已经熟练VictoriaMetrics是最平滑的增强如果团队有Java/大数据背景对TDengine体感也不错。性能差距可以通过加机器弥补学习成本和踩坑时间没那么容易用预算买回来。6. 2026年选型的几个判断维度兼容性、授权、存储分层6.1 接口兼容性决定你未来迁移是否痛苦站在2026年往回看时序数据库市场已经形成了两个事实标准Prometheus的remote write和PromQL成为监控数据接入层默认协议SQL成为分析查询层通用语言。新选型的产品不管是哪家最好同时具备两套接口能力既能通过remote write接收监控数据又能提供SQL作为分析查询入口。这种“左右逢源”的兼容策略能最大限度减少未来的迁移成本。比如基于Prometheus生态建设的监控体系未来如果要把数据送到分析平台做二次加工SQL接口就能直接对接不用再写复杂的转换管道。6.2 授权模式和社区活跃度要一起看开源时序数据库的授权变化这几年比技术迭代更值得关注。某些项目从宽松协议切换到更严格的商业授权有些项目开源版和商业版的功能差距越拉越大。选型时不仅要看当前版本还要看懂项目近两年的版本发布节奏、社区贡献者构成和主创公司的商业模式。如果一家公司只有社区“晒性能”的声音没有稳定的版本迭代和响应的Issue闭环我建议谨慎押注。与之相反能明显看到企业客户反馈进入产品Roadmap的通常生命周期更健康。6.3 冷热分层与对象存储会成为标配时序数据的价值随时间快速衰减冷热分层存储是2026年选型不可回避的考量。现在主流产品大多把热数据放在本地高性能磁盘把老数据下沉到S3/对象存储或廉价HDD上按需加载查询。这样既控制了存储成本又保留了全量历史数据的可查性。InfluxDB 3.x已经在架构上支持对象存储VictoriaMetrics也有配套的对象存储方案TDengine在冷热分离上也有明确策略。选型时不要只看“单机写入多快”更要在测试环境里验证“一年前的冷数据查询延迟”能否满足业务需求这个指标才贴近生产的真实感受。把这几条串起来我的个人结论其实很简单选型先选场景再选产品最后才是性能。监控告警场景优先走Prometheus兼容生态物联网海量点位优先看TDengine这类面向超级表模型的库业务与采样数据混合分析直接留在TimescaleDB这类SQL引擎里中小规模的快速落地可以继续信任InfluxDB。如果2026年让我重新做一遍选型我不会再盯着基准测试榜单看而是先画出数据模型再拿着真实采样数据跑一轮保留策略、压缩、查询延迟和高基数压力的测试最后用团队最熟的技术栈做收口——这套流程帮我避开了大多数数据库选型事故也分享给你参考。