1. 为什么2026年的时序数据库选型又变难了
我之前在好几个团队里做过时序数据相关的基础设施建设，也在选型班上踩过不少坑。每次遇到有人问“现在用哪个时序数据库最好”，我都先反问一句：你手里的数据长什么样、你每天要写多少点、你的查询是给大屏看的还是给告警系统用的、你团队里有几个能玩数据库的人。这几个问题没聊清楚，直接谈排名就是耍流氓。
到2026年，这个问题的复杂程度比两三年前又上了一个台阶。一方面，物联网设备、车联网终端、边缘网关的数量持续膨胀，单套系统的采集点位从几万跳到几百万很正常；另一方面，Prometheus监控体系在云原生环境里几乎成了标配，可监控数据只是时序数据的一种，金融行情、工业数采、能源计量、用户行为漏斗这些场景也全都往时序库上靠。结果是，市面上的产品在底层存储架构上出现了明显的分岔——有的走列存加对象存储，有的坚持LSM Tree原地升级，有的干脆站在PostgreSQL的肩膀上做扩展。同一个“时序数据库”的帽子，底子里可能完全是两套思路。
这时候做选型，本质上是给自己的数据挑一个长期同居的伙伴。数据一旦灌进去，迁移成本是非常真实的痛苦。我在后面的内容里会用五个主流产品横向展开，讲清楚它们的取舍、适合哪里、不适合哪里，最后给出一套我自己一直在用的选型决策框架。
2. 评估维度与场景分层：选型前先统一坐标系
选型最忌讳看参数表直接下结论。厂商公布的性能数字用的大多是“友好测试”，硬件、并发模型、采样频率都经过微调。真正决定成败的往往是几个容易被忽略的维度。
2.1 六大评估维度：写入、查询、压缩、生态、运维、成本
我先把我自己在选型时固定会拉开的评估维度列出来，你可以直接拿来当checklist用。
写入吞吐与稳定性。时序数据几乎没有闲着的时候，设备一开机就在产数。评估写入不要只看单点峰值，要看持续写入下的P99延迟，以及大批量写入时是否会产生明显的线程阻塞或内存抖动。对物联网场景，还要特别留意数据乱序写入的处理能力——设备断网上报、网络延迟导致旧数据晚到，这些在真实环境里太常见了。
查询能力与延迟。不同场景的查询模式差异极大。监控告警通常是近实时的小查询，几百毫秒能出结果就行；但数据分析可能是几小时的聚合扫描，需要秒级或更低的响应，比如“昨天全部风机每小时的发电量均值”。支持哪些查询语法，是InfluxQL、PromQL、标准SQL还是只有自定义API，直接决定了开发成本和生态兼容性。
压缩率与存储成本。时序数据最大的成本瓶颈往往不是计算而是存储。不同库的压缩算法差别很大，同一条时间线，有的库压缩后能到2%以下，有的只能压到10%上下。磁盘成本和后续的备份、归档成本都跟这个比例直接挂钩。
生态完整度。数据采集层有没有现成的采集器，可视化能不能对接Grafana，告警有没有内置规则引擎，数据导出有没有开放的HTTP/命令行接口。这些看起来不起眼，但在落地时能帮你省掉大量写胶水代码的时间。
运维复杂度。是单机开箱即用，还是需要部署ZooKeeper、NameNode之类的外部依赖，扩缩容是自动的还是手工的，备份恢复流程是否简单。对于团队里没有专职DBA的场景，运维简单性有时候比性能权重更高。
协议合规与成本模型。开源库要注意License是Apache、AGPL还是SSPL，商用库要搞清楚是按节点、按容量还是按写入量计费。2026年了，License合规和云厂商绑定风险必须纳入考量，不然后面很容易被动。
2.2 从数据特征反推场景：不是所有时序数据都一样
上面六个维度是横向参考线，但真正让我决定“该用谁”的，是先把业务场景按数据特征分好类。我常用的分类方法是看三个问题：数据模型是强结构化的标签序列，还是自由文本的半结构化事件；查询是以单条时间线为主，还是以跨时间线的聚合为主；数据是只增不改的流水账，还是需要频繁更新和事务一致性的业务数据。
拿这个标准去套，大部分场景可以收敛成下面几类。
第一类，云原生监控与告警。数据模型天然是Metrics风格，一组标签键值对加一个数值，如cpu_usage{host="web-01", core="0"} 42。这类数据在基数和聚合维度上要求极高，但一条数据本身很小，基本不需要更新。Prometheus生态、VictoriaMetrics这类产品就是为此设计的。
第二类，物联网设备数据与工业数采。数据规模非常大，单点整秒采集，一天就能积累几亿条记录，而且按设备、站点分组的标签查询特别多，比如“查某个站点本周全部逆变器的日发电量”。这种场景要求写入性能突出，同时数据模型能高效表达“设备对象+多测点”的层次结构。
第三类，金融、业务系统里的时序数据。比如K线、订单流、优惠券核销趋势，往往要求强一致性和SQL聚合能力，还要和客户表、订单表做关联查询。这类数据本质上是“带时间属性的关系数据”，更适合在SQL引擎上做扩展。
第四类，大规模历史分析与数据洞察。比如用户行为日志、传感器历史库分析，数据量以PB计，查询模式通常是范围内的批量分析，很少做高频点查。这种场景优先考虑列式存储引擎的OLAP能力，而不是专门的时序存储效率。
这些分类不必强求唯一答案，比如监控场景里也可能会用到ClickHouse做历史回放，物联网数据也可能喂给Prometheus生态。但拥有这个坐标系之后，再去对比五个产品，你看到的就不再是“谁更快”，而是“谁更贴合我这边的数据脾气”。
3. 五款主流产品深度拆解
下面进入重头戏，逐一拆解我选定的五款产品：InfluxDB、TDengine、TimescaleDB、VictoriaMetrics、ClickHouse。选这五个是因为它们分别代表了时序领域的几种主要技术路线，而不仅仅是市场排名。
3.1 InfluxDB 3.x：老牌王者的彻底重构
InfluxDB 在时序圈子里算是家喻户晓的名字，很多人第一次接触时序数据库就是通过它。老版本InfluxDB 1.x用WAL加TSM文件的方式，单机体验很顺，尤其在开发者本机跑通整套采集、存储、查询链路非常快。但规模上去之后，问题也藏不住：内存占用偏高，索引和数据写放大明显，长时间运行后压缩任务老是和写入抢资源。到了2.x时代，引入Flux查询语言和Bucket概念后，功能丰富了，团队抱怨却更多了，特别是在跨大时间范围的聚合查询上，性能和易用性都有点尴尬。
到了InfluxDB 3.x，这是架构上的一次完全重写，底层用Rust实现，存储引擎转向列式Parquet格式，并且把数据放在对象存储上。这个方向等于把时序库做成了湖仓一体风格：写入路径先进内存，周期性落盘为Parquet文件，元数据单独管理，查询时可以只扫描相关列，数据压缩率也上去了。用对象存储作为主存储的一个明显好处是，存储和计算可以分开扩展，本地磁盘不够用不再是一个单点瓶颈。
但3.x的选型一定要先看License和产品线。当前InfluxDB走的是类似“核心开源加云服务商业化”的路线，开源版本和云版本之间存在功能差异，如果团队计划长期自建，务必提前确认你想要的功能（比如某些高可用、多租户能力）在开源版本里是否可用。我自己体验下来，3.x对开发者依然友好，采集器生态（Telegraf）也依然好用，适合中小团队、快速原型、一次性把数据接入的事情干完。
适合场景：开发者主导的采集监控项目、中小规模物联网平台、快速原型验证。不适合的场景：对事务能力要求高、需要复杂子查询关联、追求极低硬件成本的超大规模自建场景。
3.2 TDengine 3.x：为物联网而生的高性能选手
TDengine是近些年成长很猛的一款国产开源时序数据库，名字里的“TD”强调Time-series Data，定位非常聚焦，就是物联网和工业场景。它有一个非常核心的概念叫“超级表”，相当于把同一类设备的所有测点组织成一张逻辑表，然后在表上挂标签（设备型号、位置、所属站点等）。这样查询“某某站点所有设备过去一天的平均温度”，SQL一句就能搞定，而底层会自动按标签做数据分布和过滤，性能和易用性平衡得不错。
3.x版本把整体架构推向更云原生的方向，支持多副本、对象存储对接，也补强了流式计算能力，可以边写入边做窗口聚合，减少下游实时计算链路的复杂度。在写入性能上，TDengine在普通服务器上能到百万点每秒的级别，这种规模的写入在以往的通用SQL数据库上是很难想象的。
不过TDengine有一些需要提前适应的点。首先是时序模型和关系模型的差异，超级表、子表、标签这套概念虽然有文档支撑，但对习惯了传统数据库的团队还是有一个学习曲线；其次，它强项在结构化时序数据，如果你要存的是半结构化的JSON日志或者标签维度特别灵活的Metrics，用起来会有点别扭；最后是open-source与企业版在集群能力、部分高级功能上有区分，生产部署前要看清楚你需要的特性具体属于哪种版本。
适合场景：设备量大的物联网平台、工业数采、车联网、能源电力、动环监控。不适合的场景：需要复杂JOIN和事务处理的分析业务、特别自由的KV式查询模式。
3.3 TimescaleDB：站在PostgreSQL肩膀上的时序扩展
TimescaleDB不是独立数据库，而是一个PostgreSQL扩展。这一点是它最大的差异化优势：继承PostgreSQL的所有能力，标准SQL、事务、外键、窗口函数、GIS支持，要什么有什么。它对时序数据做了“超级表”（Hypertable）的抽象，底层自动按时间维度和空间维度把数据切成Chunk，用户看到的还是一张普通SQL表。处理老化数据时可以通过压缩策略将历史Chunk做列式压缩，空间占用明显降低。
它的连续聚合功能也特别好用。你在普通表上定义一个1小时粒度的连续聚合视图，之后查询这段历史的1小时均值，走的不是原始数据全扫，而是从聚合视图里取数，速度非常可观。PostgreSQL生态里现成的连接池、备份工具、监控系统、BI工具统统可以沿用，对已经重度使用PostgreSQL的团队来说几乎是零额外认知成本。
代价也很直观：写入吞吐和专用时序库比起来有差距。批量写入场景下，TimescaleDB的P99延迟更容易受到索引更新和表结构约束的影响，如果每天要灌几十亿条记录，你要认真做好批量批处理调优、分片键设计。高可用分布式方面，虽然从2.0开始引入多节点能力，但和云原生原生的分布式时序库比起来，部署和运维复杂度略高，常规团队一般还是跑在单机或一主多读模式。
适合场景：金融业务数据、订单流水、系统运营指标、需要和业务库做关联查询的SQL重度场景。不适合的场景：超大规模物联网采集、纯监控指标海量写入。
3.4 VictoriaMetrics：轻量与高性价比的监控优选
VictoriaMetrics在云原生监控圈里的口碑一直很好，很多人把它看作Prometheus的持久化存储替代方案。它兼容Prometheus的remote write协议和PromQL，也就是你原来配好的Prometheus规则、Grafana面板几乎不用改，就能把数据写到VictoriaMetrics上。它对大基数数据（高基数标签）的处理能力比原生Prometheus好很多，内存控制也相当出色。
部署上它极其友好，单个二进制文件就能跑起来，默认配置下已经能扛住比较可观的数据量。集群版（vmcluster）的架构也不复杂，由vmstorage、vminsert、vmselect三个组件组成，可以按读写需求单独扩容。对SRE团队来说，这套东西的资源占用和运维成本，是前面几款里几乎最低的。
但它只擅长一件事，就是Metrics类型的监控数据。它使用标签对数据的KV模型，虽然每个标签的值支持任意文本，但存储模型并不适合存长文本、JSON、事件日志一类的数据，也几乎不提供事务更新能力。如果你的目标是“一个库同时存监控指标、设备日志、业务流水”，VictoriaMetrics会很快让你碰到墙。
适合场景：Kubernetes集群监控、Prometheus超大规模存储、SRE自运维监控平台。不适合的场景：日志事件存储、业务事务数据、需要SQL做复杂分析的数据场景。
3.5 ClickHouse：披着OLAP外衣的时序分析利器
严格说起来，ClickHouse不是时序数据库，但它在大数据领域处理时序分析实在太常被用了，选型会里不聊它说不过去。ClickHouse的MergeTree表引擎在设计上天然适合按时间排序写入和按时间范围扫描的数据模式，每列独立存储，向量化执行，压缩比极高。几十亿行数据在上面做按小时的聚合，跑秒级查询是常态。
它对标签和维度列的处理也很灵活，任何列都可以作为过滤条件，也可以建跳数索引、布隆过滤器来加速，根本不需要你按时序库的规矩把维度拆分成标签。这让它在那些“数据虽然带时间戳，但分析维度千变万化”的场景里非常吃香。我见过不少团队把ClickHouse放在OLAP层，一边接Kafka里的行为日志，一边接其他时序库导出的历史快照，做跨域分析。
代价也清清楚楚。第一，ClickHouse不是为高频单点查询设计的，比如“查询某个设备某个参数在10秒前的值”，这活它干得不够快也不划算；第二，它的更新和删除能力比较弱，虽然提供了轻量删除和突变操作，但频繁modify数据很容易引发后台任务堆积；第三，想要扛住大数据量，节点数和内存规格会迅速膨胀，运维门槛和成本明显高于VictoriaMetrics和TDengine。不是一个让人省心的“小数据库”，更像一个重型分析引擎。
适合场景：海量历史时序数据的OLAP分析、日志分析平台、用户行为时序特征、数据湖场景。不适合的场景：高频点查、监控告警低延迟链路、需要事务更新的业务时序。
4. 场景适配与选型决策框架
产品拆完了，核心问题来了：面对自己的项目，怎么选？我会先画一张场景推荐表，然后给一套可复制的决策流程。
4.1 六类典型场景推荐速查
| 业务场景 | 首选方案 | 备选方案 | 理由一句话 |
|---|---|---|---|
| 云原生监控告警 | VictoriaMetrics | InfluxDB 3.x | PromQL兼容，部署轻，运维成本低 |
| 物联网大规模设备接入 | TDengine 3.x | InfluxDB 3.x | 超级表模型贴合设备组，写入吞吐高 |
| 金融/业务强SQL场景 | TimescaleDB | 无 | 标准SQL和事务能力不可替代 |
| 开发者快速原型/单机 | InfluxDB 3.x | TDengine | 生态顺手，动手成本低 |
| PB级历史数据分析 | ClickHouse | 无 | 向量化执行和列压缩效率极高 |
| 混合负载：监控+分析 | 主用VM，分析走ClickHouse | 分库叠加 | 避免单库既要低延迟点查又要高吞吐分析 |
这张表不是万能解药，但基本能覆盖九成以上的常见情况。你可以把自己的场景往里面套，再调整细节。
4.2 六步选型决策流程（直接照做）
第一步，写清楚三个数字：日增数据量、保留时长、活跃查询并发量。这三个数决定了一切硬件评估和产品筛选的下限。日增十个GB和日增十个TB，走的路完全不一样。
第二步，确认查询模式。抽十个核心业务查询，写下来它们的查询类型、返回行数、目标延迟。用这些查询作为基准，在候选库上做压测，这一步一定不能省。
第三步，考察团队能力。团队熟悉SQL还是更愿意写类PromQL？有没有人能维护ClickHouse集群？没有专职DBA的时候，优先选择单机开箱能跑的方案，而不是每个组件都要排错。
第四步，算总成本。不光看软件授权费，还要看需要多少台机器、多少磁盘、备份容灾怎么算，以及后续维护需要几个人天。有时候一款性能看起来差一点的库，三年总拥有成本反而低很多。
第五步，做小规模原型。用三个工作日的真实数据做双写，把后两周的查询都接到新库上跑，观察写入延迟、查询响应、内存走势和磁盘占满速度。原型阶段发现的问题，远远便宜于全量迁移后再发现的问题。
第六步，签署最后决定的时候，明确退出成本。如果这个库三个月后不满意，数据怎么导出来？有没有标准导出工具？上面这句听起来像废话，我见过不止一个团队因为数据格式锁定而硬着头皮继续用一款不合适的库，那才是最痛苦的状况。
4.3 混合使用是不是好主意
很多项目最后会走到混合架构。我个人很支持这种务实的做法。比如监控数据走VictoriaMetrics，保持告警链路的稳定和低成本；设备本身的业务数据走TDengine，方便业务查询；历史分析再定时同步一份到ClickHouse，给数据分析师做灵活的OLAP掏数。各取所长，互不拖累。
但混合架构的问题在于组件多了、链路易断。你必须把同步任务做成可观测、可重放的管道，一旦源库写坏了，下游要能对账追数据。团队规模小于五六人的情况下，我不建议一上来就搞三库混用的宏大设计，推荐先把一个核心库用熟，再按需接一个分析引擎。
5. 落地阶段的迁移方案与避坑经验
选型不是终点，把数据平稳切过去才是真的落地。时序库的迁移和业务库迁移有很多相似之处，但也有不少专属的坑。
5.1 迁移三步走：双写、回放、校验
我在实际项目里反复用的迁移方案是这样的。
第一步是双写过渡。在新旧两个库上同时写入业务数据，持续一到两周。双写阶段的价值不是让新库追上线，而是让真实业务流量去检验新库的写入能力，观察它在真实压力下的表现。
第二步是历史数据回放。从旧库按时间范围批量导出历史数据，写入新库。时序数据量通常很大，回放要设计好并发度，避免一次性把新库写入线程打满。我一般会按天或按小时分片，慢速、稳定、错峰执行。
第三步进行全面校验。对账的方式是随机抽样时间线，分别从旧库和新库查同一时间段的数据，比较聚合值差值和数据点数量差。对不上就要查回放任务的日志，看是否有写入失败或超时丢弃。数据校验没有捷径，只能把抽样的范围尽量做大一点。
5.2 数据模型设计里最容易被忽略的三个细节
第一，标签基数别上来就打满。标签值只有几种甚至一种，也千万不要为了“灵活”把所有字段都设成标签。标签基数太大会直接拖垮索引和压缩效率，时间线的数量等于标签组合的笛卡尔积，随随便便就从百万膨胀到亿。
第二，保留策略和降采样要提前想。很多团队先在库上把TTL配好，后来发现历史数据的聚合查询一夜回到解放前。更合适的做法是提前定义好原始数据存多久、5分钟降采样数据存多久、1小时降采样数据存多久，用连续聚合或流计算把它们物化成独立表。
第三，时间字段统一用UTC。设备分布在多个时区，业务查询也总想用本地时间，但存储层强烈建议统一按UTC时间写入，展示层再做时区转换。否则夏令时一换，时间线直接错位，历史数据对不齐。
5.3 常见故障与排查速查表
| 现象 | 可能原因 | 处理方向 |
|---|---|---|
| 写入P99突然飙升 | 大批量乱序写入触发合并、磁盘IO饱和 | 检查写入批次大小和并发；为乱序窗口做缓存降载 |
| 查询越来越慢，但是数据量没涨 | 缺少降采样，聚合全扫原始数据 | 增加连续聚合或物化视图；用预聚合结果替代实时聚合 |
| 磁盘空间快速被占满 | TTL未生效、压缩任务未配置 | 检查保留策略是否覆盖到库/表；开启压缩 |
| 节点重启后数据缺失 | 副本数不够、同步延迟 | 补副本；检查同步状态，做全量对账 |
| 高基数标签查询OOM | 时间线数量爆炸 | 拆分标签策略或启用布隆过滤器特性 |
| 对象存储存量不断增长 | 回收策略未配置 | 设置生命周期策略，在对象存储侧清理孤儿Parquet文件 |
6. 写在最后的选型心得
这些年在时序选型上踩过的坑，有个绕不开的共性：多数失败不是“选了一个差的库”，而是“没用对选型方法”。数据规模、查询模式、团队能力和成本预算，各有各的权重，照搬别人的POC数据来决策，往往会忽略掉自己场景里的隐藏需求。我现在的习惯是在选型立项初期，用真实业务数据跑三个候选库的小规模原型，然后把候选库的测试报告和成本估算放在一张表里给团队看。数据自己会说话，比任何人的口头推荐都更可靠。
另外，时序数据库选型不是一锤子买卖。2026年这个节点上，各家产品迭代速度依然很快，不管是InfluxDB 3.x的架构演进，还是TDengine的云原生能力，都还在快速变动。选定之后保持跟踪，库版本升级前一定先做兼容性测试，不要盲目追新。给业务一个稳定底座，同时留好平滑演进的能力，这才是选型真正要交出的答卷。
