1.2 发展历程与产品分类
1.2 发展历程与产品分类
本节摘要：TSDB 演进经历三阶段：关系库补丁（2005–2012）、专用引擎（2013–2018）、云原生融合（2019–今）。OpenTSDB 用 HBase RowKey 编码 metric+tags+time；InfluxDB TSM 与 Prometheus 本地 TSDB 将时间升为一级原语；TimescaleDB 与 QuestDB 则分别走 PostgreSQL 扩展与列式 SQL 路径。本节按时间线对照四家产品定位。
本节目标
阅读完本节，你应当能够：
- 说明 OpenTSDB RowKey 设计如何利用时间局部性
- 对比 InfluxDB TSM 与 Prometheus 内存模型的差异
- 将 InfluxDB/Prometheus/TimescaleDB/QuestDB 放入同一分类坐标
一、问题与直觉
每个团队都曾重复造轮子：MySQL 按月分区、自研压缩、应用层降采样——直到 OpenTSDB（2010）证明 HBase 稀疏列族 适合「多标签、稀疏写入」的 metrics。但 ZooKeeper + HBase 运维门槛高，催生出 单机专用内核 时代：InfluxDB（2013）的 TSM 文件、Prometheus（2012 开源，2015 爆发）的 WAL+内存哈希表，把「时间结构」写进引擎基因。
二、核心原理
| 阶段 | 代表 | 核心突破 | 代价 |
|---|---|---|---|
| 烟囱自建 | MySQL 分区 | 无，应用层聚合 | 写入与查询双瓶颈 |
| 分布式早期 | OpenTSDB | RowKey=metric tags time | HBase 运维复杂 |
| 专用引擎 | InfluxDB TSM | 列式+按时间窗口文件 | 集群版演进曲折 |
| 极简监控 | Prometheus | 内存 series 表+PromQL | 长期存储需 Thanos/VM |
| SQL 扩展 | TimescaleDB | PG hypertable+chunk | 写入专优化弱于原生 |
| 列式 SQL | QuestDB | mmap 列式+向量化 | 生态小于 Prometheus |
OpenTSDB 的关键洞察
RowKey 将 metric_name{tagk=tagv,...} 与时间戳编码进 HBase，同一 series 的前缀相同，时间范围扫描具有 Region 局部性——这是「时间作为结构要素」的第一次大规模工程验证。
RowKey 的编码思路可以简化理解：假设我们按 metric + tags + 时间桶 拼成 RowKey，那么同一个 series 的数据会落在 HBase 中连续的 Region 上。查询「某个指标最近一小时」，本质上是一次按前缀的顺序扫描，而不是全表随机翻。代价是把 HBase 的运维复杂度（Region 分布、Compaction、HDFS 副本）转嫁给了用户——这也是它没能成为通用方案的原因。
专用引擎时代
InfluxDB TSM：每个 TSM 文件对应时间窗口，内部按时间排序列存；时间戳列用 delta-of-delta 编码，浮点用 Gorilla 压缩，实测压缩比可达 1:10 以上。
Prometheus：(metric, labels) 哈希到内存表，PromQL 编译为 Go 闭包直接扫时间点数组；Pull 模型 + 服务发现定义云原生监控范式，本地磁盘只是短期缓存。
TimescaleDB：在 PostgreSQL 上挂 hypertable，INSERT 自动路由到 time+space chunk；查询 time > now() - interval '1 hour' 只扫相关分片，保留完整 SQL 窗口函数。
QuestDB：纯 SQL 接口 + 列式 mmap 时间索引，主打 ingest 与 ad-hoc 查询低延迟，兼容 Influx line protocol 与 PostgreSQL wire。
为什么是这三条路线
把四家放进同一张坐标纸，横轴是「引擎自主 vs 生态复用」，纵轴是「查询语言专用 vs 通用」：
| 路线 | 代表 | 引擎 | 语言 | 核心理由 |
|---|---|---|---|---|
| 自研专用引擎 | Prometheus / Influx | 自研（TSDB/TSM） | PromQL / Flux | 极致控制时间结构 |
| 寄生成熟生态 | TimescaleDB | 复用 PostgreSQL | 标准 SQL | 企业接受度与生态 |
| 列式 SQL 内核 | QuestDB | 自研列式 | ANSI SQL | 低延迟分析 |
这条分化说明：架构选择即战略宣言。选择寄生生态，等于接受「写入专优化弱于原生」；选择自研引擎，等于承担「查询语言生态自成一体」的迁移成本。
2019 年后的 SQL 复兴
三股力量在 2019 年后交汇：InfluxDB 3/IOx 基于 DataFusion 全面支持 SQL；QuestDB 坚持纯 SQL 接口并做列式向量化；TimescaleDB 原本就是 SQL。TSDB 行业出现了一个重要收敛——时序计算原语向标准 SQL 靠拢。对使用者来说，这意味「会 SQL 就会时序」越来越接近现实，跨产品迁移的学习成本在下降。
01-01-fig01-4
01-01-fig01-4
三、工程实践要点
| 选型倾向 | 优先考虑 | 典型理由 |
|---|---|---|
| K8s 监控栈 | Prometheus ± Thanos/VM | 生态、PromQL、Pull 服务发现 |
| 自定义 IoT push | InfluxDB 2.x/3.x | line protocol、多 field |
| 已有 PostgreSQL | TimescaleDB | SQL、JOIN 维表、企业接受度 |
| 高频 tick + SQL 分析 | QuestDB | 列式 ingest、低延迟查询 |
演进背后的共性规律
把三个阶段的共性拎出来，会看到一条清晰的主线：每一代产品都在回答「时间如何更廉价地成为结构」。MySQL 补丁阶段靠应用层硬拼；OpenTSDB 把时间编码进 RowKey；Influx/Prometheus 让引擎原生感知时间窗口；Timescale/QuestDB 则把时间分区与 SQL 语义融合。相应地，硬件也在变——SSD 普及让顺序写优势放大，列式 mmap 与向量化让查询不再是瓶颈。理解这条主线后，再遇到新出的时序引擎，你可以先问三个问题：它把时间放在存储的哪一层？它的写入是顺序还是随机？它的查询语言与标准 SQL 的距离有多远？
版本迭代与选型现实
最后提醒一点：本节所有产品描述都基于各家的当前 major 版本（Prometheus 2.x/3.x、InfluxDB 3.x、TimescaleDB 2.x、QuestDB 长期演进版）。这些产品迭代极快，历史上被反复改写的部分包括 Influx 的查询语言（InfluxQL→Flux→SQL 化）、Timescale 的压缩与分层存储、QuestDB 的复制与高可用。做选型结论时，务必以当下官方文档为准，本节提供的坐标系不会变，但具体功能清单会变。
从历史学到的三条教训
第一，先有正确的问题，才有正确的架构。OpenTSDB 解决的痛点是「横向扩展」，所以它选 HBase；2015 年 Prometheus 崛起的痛点是「K8s 场景下要极简部署与稳定采集」，所以它选单机 + pull。第二，运维复杂度是隐性成本。再强的架构若运维门槛过高，最终会被生态边缘化。第三，语言与生态的锁定效应很强。PromQL 模板库与 Grafana 生态让 Prometheus 系在监控场景占据绝对心智，后来者要替代的不是引擎而是生态。
⚠️ 常见坑：用 2014 年的「Influx 只能 NoSQL」印象否定其 2023+ IOx/SQL 路线——选型应看当前 major 版本能力。
💡 关键直觉：架构选择即战略宣言——追求极致监控体验选 Prometheus 系，追求 SQL 与事务邻接选 Timescale，追求 ingest 吞吐选 Influx/QuestDB。
自测题
- OpenTSDB 的 RowKey 为什么能让时间范围扫描有 Region 局部性？
- Prometheus 本地存储只当「短期缓存」，那长期数据靠什么？
- 在「引擎自主」与「生态复用」之间，TimescaleDB 选择了哪边，代价是什么？
补充一句小结：产品分化不是缺陷，而是不同 workload 的镜像——理解「谁在什么约束下选了哪条路」，比记住谁支持什么特性更有迁移价值。
核心回顾
- 三阶段：补丁 → 专用引擎 → 云原生融合
- OpenTSDB：RowKey 时间局部性
- Influx TSM：delta-of-delta + Gorilla
- Prometheus：内存 series + Pull
- Timescale：hypertable chunk on PG
- QuestDB：列式 SQL 低延迟
下一节用场景矩阵把上述产品映射到监控、IoT 与金融 workload。