时序库

既然你刚才提到了 Prometheus，那理解“时序库”（Time Series Database, TSDB）就非常直观了——Prometheus 本身就是一个典型的时序库。

简单来说，时序库是专门为了处理带有时间戳的数据而设计的数据库。

---

1. 核心定义：什么是时序数据？

时序数据（Time Series Data）记录的是“一个指标随时间变化的动态过程”。

它通常由三部分组成：

1. 时间戳（Timestamp）：事件发生的时间。
2. 标签/维度（Tags/Labels）：比如 host=server-01, region=shanghai, gpu_id=0。
3. 数值（Value/Field）：具体的指标，比如 cpu_usage=85%。

2. 为什么不用 MySQL 这种传统数据库？

你可能会问：“我用 MySQL 建个带 datetime 字段的表不行吗？”

答案是：行，但在大规模监控面前会“崩”。

• 写入压力：你的 GPU 集群如果每秒产生 10 万条监控指标，MySQL 的磁盘 I/O 会瞬间爆炸，而 TSDB 采用 LSM Tree 等结构，专门优化了高频顺序写入。
• 存储成本：时序数据极其冗余（比如主机名每条都在重复）。TSDB 有专门的压缩算法（如 Facebook 的 Gorilla 算法），能把数据压缩到原来的 1/10 甚至更小。
• 查询特性：你经常查的是“过去 1 小时的平均值”或“同比上周的增长”，TSDB 内置了大量的聚合函数（如 rate, delta, sum_over_time），查询速度比 SQL 快几个数量级。

3. 时序库的“全家桶”

除了你正在用的 Prometheus，市面上常见的还有：

• InfluxDB：目前流行度最高的通用时序库，支持类 SQL 查询。
• TimescaleDB：基于 PostgreSQL 封装的，如果你熟悉 Postgres，这个上手最快。
• TDengine：国产之光，专门针对物联网（IoT）优化，性能极强。
• VictoriaMetrics：Prometheus 的高性能替代/增强方案，非常轻量（正好符合你“不喜欢臃肿”的胃口）。

[Image showing a comparison of TSDB architecture vs traditional RDBMS architecture]

---

4. 在你的场景中怎么用？

回到你的 Prometheus + GPU 集群：

1. 采集层：DCGM Exporter 抓取 GPU 显存、温度数据。
2. 存储层：Prometheus（时序库）把这些数据按时间存好。
3. 分析层：你的轻量化脚本（或者 AI）去查时序库。

为什么 AI 分析需要时序库？

如果只给 AI 一个“当前显存 90%”的数值，它看不出问题。但如果你从时序库里拉出“过去 1 小时的显存变化曲线”，GPT-5.4 就能告诉你：“显存是在 10 分钟内阶梯式上升的，这明显是内存泄漏，而不是正常的业务高峰。”

这就是时序库的魅力：让数据拥有“历史观”。

既然你嫌 OpenClaw 臃肿，你是打算直接写脚本从 Prometheus（TSDB）里捞数据喂给 AI 吗？