时序数据建模与存储选型

典型场景对比（1 亿点位）：
  关系型：聚合一次 GROUP BY + WHERE 时间窗  → 秒级
  时序库：同一查询（预聚合/列式扫描）        → 毫秒级

一条时序数据 = 时间戳 + 一组标签 + 指标值
  cpu_usage{host="web-01", region="cn-east"} = 47.5 @ 14:00:00

□ 标签用"高基数且查询频繁"的维度（host、region、app）
□ 低基数属性合并进值，不单独拆标签（避免序列爆炸）
□ 指标名保持稳定，慎用带版本号的名字（cpu_usage_v2 是坏味道）

序列爆炸示例：
  labels={a:10}×{b:10}×{c:10}×{d:10} → 1 万条序列 × 每秒采样 = 写入灾难

公式：
  每秒写入点位 = 采样间隔的倒数 × 序列总数
  序列总数 = 指标数 × 标签组合数

例：
  30 个指标 × 2000 台主机 × 5 个 region = 30 万条序列
  10 秒采样一次 → 每秒写入 = 30 万 / 10 = 3 万点位
  调整到 30 秒采样 → 每秒写入降到 1 万点位

原始：每 10 秒一个点（1 年 315 万点/序列）
降采样第 1 级：每分钟 MAX/AVG（约 52 万点）      → 保留 30 天
降采样第 2 级：每小时 AVG/P95（约 8.7 万点）     → 保留 365 天
原始数据：保留最近 7 天

存储成本大约下降 90%+，查询依然有统计意义。

-- 以 TimescaleDB 为例：连续聚合（continuous aggregate）
CREATE MATERIALIZED VIEW cpu_usage_1h
WITH (timescaledb.continuous) AS
SELECT time_bucket('1 hour', ts) AS bucket,
       host,
       avg(value) AS avg_val,
       percentile_cont(0.95) WITHIN GROUP (ORDER BY value) AS p95
FROM cpu_usage
GROUP BY bucket, host;

是否已有强 PG 生态？
  ├─ 是 → TimescaleDB（SQL 兼容，平滑迁移）
  └─ 否 ↓
是云原生监控指标？
  ├─ 是 → Prometheus + 长期存储（Thanos/Mimir）
  └─ 否 ↓
写入量每秒百万级 / 大规模 IoT？
  ├─ 是 → TDengine / ClickHouse
  └─ 否 → InfluxDB（通用、易上手）

迁移五步：
  1. 双写期：关系型照常写，同时写时序库（1~2 周）
  2. 对账：两边抽样对比，指标值、时间戳、标签一致
  3. 切读：新查询走时序库，老代码保留读关系型
  4. 追补：用导出工具回填历史数据（按天分批）
  5. 下线：确认无误后停关系型写入

回填注意：老数据时间戳要按「采集时间」而非「导入时间」写，
否则时间序列会被冲到错误的位置。

❌ 逐条写入：每次一条 SQL，网络开销 + 写放大
✅ 批量写入：一次写 1000~10000 个点位
✅ 相同时间戳重复值：取最新覆盖（upsert 语义）

# InfluxDB 行协议批量写入（一次性发 5000 行）
lines = []
for point in points[:5000]:
    lines.append(
        "cpu_usage,host=%s,region=%s value=%f %d"
        % (point.host, point.region, point.value, point.ts_ms)
    )
influx.write(lines, precision="ms")

-- TimescaleDB 示例：按时间分片 + 自动删除
SELECT create_hypertable('cpu_usage', 'ts', chunk_interval => INTERVAL '1 day');

-- 保留 30 天，老数据自动删除
SELECT add_retention_policy('cpu_usage', INTERVAL '30 days');

对比：同样 1 亿个点位
  关系型行式（裸存）   ：约 800MB~2GB
  时序库列式+编码压缩  ：约 80~300MB

查询优化核心：
  1. 时间范围下推：WHERE ts >= ... AND ts < ... → 只扫相关分区
  2. 标签过滤下推：WHERE host='web-01' → 利用倒排/索引
  3. 避免 SELECT *：按需要的指标/字段查询
  4. 聚合下推：GROUP BY 让存储层预聚合，而不是应用层

原始写入 → 后台连续聚合 → 预聚合结果表
查询"全网平均" → 命中预聚合表 → 毫秒返回
数据延迟容忍：聚合滞后 1~2 分钟即可覆盖绝大多数看板