6.1 四大 TSDB 选型决策表
6.1 四大 TSDB 选型决策表
本节摘要：选型看 写入模型（pull/push）、查询语言、SQL/JOIN 需求、长期保留、团队技能 五维，而非单一 benchmark。Prometheus 统治 K8s 监控；Influx 擅长 IoT push；Timescale 适合 PG 生态与维表 JOIN；QuestDB 适合高 ingest + SQL tick 分析。本节给出可打印决策表与场景推荐。
核心问题
阅读完本节，你应当能够：
- 用决策表解释为何金融 tick 慎选纯 Prometheus
- 写出 Remote Write + Timescale 混合架构理由
- 对比 Line Protocol 与 Prometheus exposition 适用边界
一、问题与直觉
「哪个 TSDB 最快？」是错误问题——VictoriaMetrics 在 Prom 兼容场景极快，但你要 JOIN ERP 维表时 Timescale 更合适。SOURCE 强调：产品差异是四维建模契约的分道——时间戳精度、tag/field 分离、一致性模型、分区与生命周期耦合。
二、核心原理
主决策表
| 维度 | Prometheus | InfluxDB | TimescaleDB | QuestDB |
|---|---|---|---|---|
| 写入 | pull scrape | push ILP | SQL INSERT/COPY | push ILP / PG |
| 查询 | PromQL | Flux/InfluxQL/SQL | PostgreSQL | ANSI SQL |
| 时间精度 | ms | ns | timestamptz | µs/ns |
| JOIN | 弱 | 弱 | 强 | 中 |
| 长期存储 | Remote Write | bucket + S3 | chunk + CA | partition drop |
| 生态 | K8s/Grafana 默认 | Telegraf/IoT | PG 扩展 | 金融 ingest |
| 运维复杂度 | 低（单机） | 中 | 中（DBA 熟悉） | 中低 |
场景推荐矩阵
| 场景 | 首选 | 备选 | 关键理由 |
|---|---|---|---|
| K8s 可观测性 | Prometheus + Thanos/VM | Grafana Mimir | 服务发现、PromQL 模板库 |
| 工厂 IoT push | InfluxDB 3 | QuestDB | 多 field batch、ILP |
| 已有 PostgreSQL | TimescaleDB | — | SQL、JOIN、企业接受度 |
| 高频 tick SQL | QuestDB | Timescale | 列式 ingest、SAMPLE BY |
| 混合监控+分析 | Prom + Remote Write → Timescale | VM + SQL | 各取所长 |
决策表怎么读：先看两个「一票否决」
决策表有七行，但实践里先看两个决定性问题：要不要原生 JOIN？ 要，就基本锁定 Timescale（或 QuestDB 的中等能力）；时间精度要不要到微秒/纳秒？ 要，就基本排除 Prometheus（毫秒精度封顶）。这两个问题可以砍掉一大半候选，剩下的维度（写入模型、长期存储、团队技能）再慢慢比较。
语法对照示例
P99 延迟（Prometheus）：
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))
5m QPS（Timescale）：
SELECT time_bucket('5 min', time), service, sum(count)/300.0 AS qps FROM http_requests GROUP BY 1, 2;
Influx Line Protocol：
http,method=GET,service=api requests=1027i 1717023456789000000
06-06-fig01-7
一个典型的反模式案例
某团队为了「统一技术栈」，把 K8s 监控、IoT 采集、金融行情分析全部塞进一个自建 Prometheus 集群，结果是：Prometheus 被迫处理高频 tick 写入（它不擅长 push 高频）、标签爆炸拖垮内存、SQL 分析需求无解。整改时拆成三套——监控留 Prometheus、IoT 走 Influx、tick 分析上 QuestDB——每套都回到自己擅长的场景，总成本反而下降。这个案例印证了本节标题下的结论：强行 All-in-One 通常比拆分更贵。
三、工程实践要点
混合架构：Prom scrape → remote_write → Timescale/VM 存 1y；Grafana 双 datasource 面板对照。
避免：为了统一而强行 All-in-One TSDB——监控与 tick 分析拆分常更便宜。
PoC 清单：ingest 峰值、top10 查询、retention 年数、是否要 JOIN、团队 PromQL vs SQL 技能。
30 天 PoC 的验收标准
选型结论不能停留在纸面，建议用 30 天 PoC 落地验证。验收标准可以定为：能承受业务峰值 2 倍的写入速率且 P99 写入稳定；top-10 查询全部在目标延迟内返回；跨 90 天与 2 年两级保留的数据都能查询；单次故障演练（节点宕机、WAL 恢复）不丢数据或 RPO 符合预期；团队两名成员能独立完成日常运维动作。任一条不满足，就回到决策表换备选。
二次选型：什么时候该换产品
选型不是一锤子买卖。下面几个信号出现时，值得启动一次二次评估：写入模型与最初假设发生偏移——例如监控指标后来开始承载 IoT 级高频 push，原来基于 pull 的产品就会吃力；查询语言需求升级——例如管理层开始要求与业务维表做 JOIN 的报表，PromQL 栈会越来越别扭；长期存储成本失控——例如保留年限从 1 年变成 7 年，对象存储冷层与聚合能力的重要性超过单机性能；团队技能结构变化——例如大量数据分析师加入，SQL 需求占比显著上升。二次评估不必推翻重来，常见做法是在边缘场景（如一个新的业务线）先试点新引擎，与现有栈双写双查一段时间，用实际数据对比后再决定是否全面切换。记住：换引擎的成本主要不在迁移代码，而在历史数据迁移、告警规则重写与团队学习曲线——所以能早评估就不必等到被逼切换。
⚠️ 常见坑：用 2018 年「Influx 无 SQL」印象——Influx 3/IOx 已 SQL 化，重新评估。
💡 关键直觉：匹配 技能栈 + 写入模型 比 benchmark 高 5% 更重要。
自测题
- 用「一票否决」逻辑论证：为什么金融 tick 场景不该选纯 Prometheus？
- 一个团队已有 5 年 PostgreSQL 经验、需要 JOIN 维表做月度分析——按决策表给首选与理由。
- 监控与 tick 分析为什么要拆分而不是 All-in-One？
把决策表落成一句话
最后把整张决策表压缩成一句可执行的话：监控与告警留给 Prometheus 系，IoT 多字段 push 优先 Influx，已有 PostgreSQL 且要 JOIN 就选 Timescale，高频 tick 与 SQL 分析交给 QuestDB，需要长期保留就用 Remote Write 接一个 SQL 或 Prom 兼容后端。 这四个「场景 → 首选」的映射覆盖了绝大多数真实项目；遇到边界场景时，再回到主决策表逐维比较，并用 30 天 PoC 验证。记住，任何决策表都只是起点，生产环境真正的裁判是「峰值写入下你的 P99 曲线」与「三年后你的运维账单」。
一节小结
- Prometheus：K8s pull + PromQL
- Influx：IoT push + ILP
- Timescale：PG SQL + JOIN
- QuestDB：ingest + SQL tick
- 混合 Remote Write 很常见
下一节展望时序原生计算与标准化趋势。