1.3 典型应用场景矩阵

1.3 典型应用场景矩阵

本节摘要：运维监控、IoT 与金融三类场景对写入模式、时间精度、查询形态要求不同。Kubernetes 监控 99% 查询是 sum(rate(...[5m])) by (job)；IoT 网关批量 push 多 field；金融 tick 要求微秒时间戳与低 jitter。本节用矩阵对照四家 TSDB 的适配度。

你能学到什么

阅读完本节，你应当能够：

1. 区分监控、IoT、金融三类 workload 的核心 SLA
2. 为给定场景推荐首选 TSDB 及备选
3. 说明为何金融场景慎把 nanoid 作 Prometheus label

一、问题与直觉

TSDB 不是单一产品品类。运维监控关心「最新 5 分钟是否异常」；IoT 关心「百万设备 append 与边缘带宽」；金融 关心「tick 顺序与回放精度」。同一套「P99 写入延迟」口号无法同时满足三者——VictoriaMetrics 案例显示：启用 ZSTD 后写入吞吐降 37%，但 P99 查询延迟降 62%，说明 freshness 与压缩 本身就在拉扯。

二、核心原理

场景的核心 SLA 拆解

三类的差异其实可以量化到一张 SLA 表，选型时对着打勾即可：

这张表说明：没有一款产品能在所有 SLA 上同时拿满分，选型是找到「与你的 SLA 最匹配」而非「绝对最快」的产品。

监控：Prometheus 的主场

Pod 每 5s 上报 container_cpu_usage_seconds_total，本质是 cgroup counter 差分求 rate。查询高度模板化：sum(rate(http_requests_total[5m])) by (service)。Prometheus 强制 server-side 时间戳（毫秒），避免客户端时钟漂移搞乱因果序——这与 IoT 设备自带 timestamp 的 push 模型形成对比。

IoT：push 与多 field

OPC UA 网关一次 batch 47 个电池单体温度 field，适合 Influx line protocol 或 QuestDB ILP：单 measurement 多 field，避免 Prometheus「一值一 metric」的 label 膨胀。

边缘侧的正确做法是「先聚合再上云」。假设一个网关每 5 秒上报一次，云上只需要 1 分钟均值：

# 网关侧：Telegraf 配置示意（aggregation + 降采样）
[[inputs.exec]]
  commands = ["/usr/local/bin/read_sensors.sh"]
  data_format = "influx"
  interval = "5s"

[[processors.aggregate]]
  period = "1m"
  drop_original = true

[[processors.aggregate.aggregations]]
  method = "mean"
  name_append = "_avg"
​

这样云端收到的是一条 temp_avg，而不是 12 条原始点，带宽与存储同时下降一个数量级。这个模式在 10⁴–10⁶ samples/s 的工业现场几乎是标配。

金融：精度与顺序

订单流时间精度逼近 ±37ns 时钟抖动（SOURCE 金融场景描述）；需要 append-only 顺序与 asof join，TimescaleDB 的 timestamptz 与 QuestDB 的 designated timestamp 更常见，Prometheus 毫秒精度通常不够。

三、工程实践要点

监控栈组合：Prometheus 本地 15d + Thanos/VictoriaMetrics 长期存储，是 CNCF 可观测性事实标准；OpenTelemetry metrics 经 OTLP 可写入多种后端。

IoT 边缘：先在网关做 batch 与降采样，避免把 device_serial 级标签直通云端——工业现场单厂可达 10⁴–10⁶ samples/s。

金融合规：保留原始 tick 与聚合层分离；热数据 QuestDB/专用引擎，温冷数据 Parquet + Timescale 外表。

金融 tick 的查询形态示例

以「求每只股票过去 1 分钟的最高成交价」为例，对比 QuestDB 与 Timescale 的写法，能直观感受 SQL 在金融场景的威力：

-- QuestDB：SAMPLE BY 对齐固定窗口
SELECT symbol, max(price)
FROM trades
WHERE ts > dateadd('h', -1, now())
SAMPLE BY 1m ALIGN TO CALENDAR;

-- TimescaleDB：time_bucket 等效
SELECT time_bucket('1 minute', ts) AS minute, symbol, max(price)
FROM trades
WHERE ts > now() - interval '1 hour'
GROUP BY minute, symbol;
​

两者都能在秒级内扫完数百万条 tick 并给出窗口聚合。若用 Prometheus 表达「窗口内最大值」会相对别扭——它不是为这种多列、多符号、需要对齐的 tick 查询设计的，这正是「按场景选产品」的直观例证。

三分钟选型决策流程

遇到一个真实项目时，按下面这个流程走，通常十分钟内能给出合理结论：

1. 写数据流图：生产者（Pod/传感器/交易系统）→ 传输（pull/push/OTLP）→ 存储 → 查询/告警。
2. 量化写与查：峰值 samples/s、series 数、top-5 查询形态、保留年数。
3. 对齐 SLA：用上面的 SLA 表，圈出最敏感的三项。
4. 落到产品：监控模板化 → Prometheus 系；IoT 多字段 push → Influx/QuestDB；SQL 分析 + JOIN → Timescale；tick 高精度 → QuestDB。
5. 补一层长期存储：本地短保留 + Remote Write 到对象存储或分析库。

⚠️ 常见坑：把订单号、trace_id 写进 Prometheus label——active series 爆炸，告警引擎本身先 OOM。

💡 关键直觉：场景决定「pull vs push」「毫秒 vs 纳秒」「PromQL vs SQL」——先画数据流图，再选产品，而非反过来。

自测题

1. 一个设备每 5 秒上报 47 个 field，云端只需 1 分钟均值——这条链路该做哪两步优化？
2. 为什么金融场景「顺序」与「精度」缺一不可？
3. 用 SLA 表给「某工厂 500 台设备、需要 SQL 月报」打分并给出首选与备选。

本节速览

• 监控：Pull、rate 聚合、Prometheus 系
• IoT：Push batch、多 field、Influx/QuestDB
• 金融：高精度 timestamp、顺序与回放
• 无万能 TSDB：矩阵选型，可组合 Remote Write
• Cardinality：场景间第一共性风险

下一章深入 metric-tags-time 模型与分区压缩机制。