时序数据库基础：TSDB核心概念与关系型数据库对比
大家好，我是你们的运维架构师。今天咱们聊聊时序数据库的基础。
说实话，我刚开始接触时序数据库时，也犯过迷糊。那时候公司日志量暴涨，MySQL 扛不住了，我才被迫去研究 TSDB。结果发现，这东西跟关系型数据库完全是两码事。
好，咱们直接进入正题。
一、TSDB 三大核心概念
时序数据库，说白了就是为时间序列数据量身定做的存储引擎。它有三个最核心的概念：时间线、数据点、保留策略。
1. 时间线（Time Series / Metric）
什么是时间线？我习惯这么理解：一个唯一标识的指标，随时间变化产生的数据流。
举个例子，你监控一台服务器的 CPU 使用率。这台服务器的 IP 是 10.0.0.1，指标名是 cpu_usage。那么 cpu_usage{host="10.0.0.1"} 就是一条时间线。
每条时间线由两部分组成：
- Metric（指标名）：比如
cpu_usage、memory_used - Tags/Labels（标签）：比如
host、region、service
标签的作用是区分不同的数据源。你想想看，如果只有指标名，那所有服务器的 CPU 数据就混在一起了，根本没法查。
关键点：时间线的数量决定了 TSDB 的规模。我见过一个客户，他们的时间线数量从 10 万涨到 100 万，查询性能直接掉了 80%。所以，设计标签时要克制，别滥用。
2. 数据点（Data Point）
数据点就是时间线上的一次采样。它包含三个要素：
- 时间戳：精确到毫秒或纳秒
- 值：可以是浮点数、整数、字符串等
- 标签：继承自所属的时间线
比如：
{
"metric": "cpu_usage",
"timestamp": 1710000000000,
"value": 78.5,
"tags": {
"host": "10.0.0.1",
"region": "cn-beijing"
}
}嗯，这里要注意：时间戳必须是单调递增的。我在项目中遇到过，有人把时间戳写错了顺序，结果查询时数据乱成一锅粥。后来我们加了校验，才解决这个问题。
3. 保留策略（Retention Policy）
保留策略决定了数据存多久、怎么存。说白了就是：旧数据要不要删？要不要降采样？
常见的保留策略有三种：
| 策略类型 | 说明 | 典型配置 |
|---|---|---|
| 原始数据保留 | 全量保存原始数据 | 7 天 |
| 降采样保留 | 聚合后保存（如 1 分钟 -> 1 小时） | 30 天 |
| 全量删除 | 超过期限直接删除 | 90 天 |
我的经验：保留策略不是越久越好。我曾经帮一个客户优化，他们保留了 3 年的原始数据，结果磁盘爆了，查询也慢。后来我们改成：原始数据 7 天，降采样 1 年，全量删除 3 年。性能提升了 5 倍。
二、TSDB 与关系型数据库的对比
很多人问我：为什么不用 MySQL 存时序数据？
我直接说结论：能存，但不好用。咱们来对比一下。
1. 数据模型
| 维度 | 关系型数据库 | 时序数据库 |
|---|---|---|
| 核心实体 | 表、行、列 | 时间线、数据点 |
| 主键 | 自增 ID 或业务主键 | 时间戳 + 标签组合 |
| 索引方式 | B+ 树 | 倒排索引 + LSM-Tree |
| 写入模式 | 随机写入 | 顺序写入 |
你想想看，MySQL 的 B+ 树索引，写入一条数据就要更新索引。如果每秒写入 10 万条时序数据，MySQL 的索引更新会直接把磁盘 IO 打满。而 TSDB 用 LSM-Tree，写入是顺序的，性能高得多。
2. 查询能力
关系型数据库擅长的是：点查询和关联查询。
时序数据库擅长的是：范围查询和聚合查询。
举个例子：
- MySQL 擅长：查某个用户最近 10 条订单
- TSDB 擅长：查所有服务器过去 1 小时的 CPU 平均值
为什么会这样？因为 TSDB 的存储结构是按时间分片的。数据按时间顺序排列，范围查询时只需要扫描连续的数据块，不需要全表扫描。
避坑指南：我曾经用 MySQL 存过监控数据，写了个 SQL 查过去 24 小时的平均值。结果跑了 30 秒才出结果。换成 InfluxDB 后，同样的查询 0.5 秒就搞定了。这就是设计理念的差距。
3. 存储效率
时序数据有个特点：重复率高。比如标签 host="10.0.0.1"，在 100 万条数据里可能重复了 100 万次。
关系型数据库会原样存储这些字符串，浪费空间。而 TSDB 会做编码压缩：
- 字典编码：把重复的字符串映射成整数
- 差值编码：时间戳只存差值，不存绝对值
- 浮点压缩：用 Gorilla 算法压缩浮点数
我实测过，同样的数据量，MySQL 占用 100GB，TSDB 只需要 10GB 左右。压缩比能达到 10:1 甚至更高。
4. 写入性能
这是 TSDB 的绝对优势。关系型数据库为了支持事务，写入时要做很多额外工作：
- 写 WAL 日志
- 更新 B+ 树索引
- 维护 MVCC 版本链
而 TSDB 的写入流程简单得多：
- 数据先写入内存中的 MemTable
- MemTable 满了后，刷到磁盘上的 SSTable
- 后台异步合并 SSTable
说白了，TSDB 牺牲了事务能力，换来了极致的写入性能。我见过单机 TSDB 每秒写入 50 万数据点，而 MySQL 到 1 万就开始报警了。
三、核心逻辑图
下面这张图，是我自己画的 TSDB 核心逻辑。你看一眼就能明白整体架构。
四、总结
好了，咱们把核心内容捋一遍：
- 时间线：唯一标识的指标流，由 Metric + Tags 组成
- 数据点：时间线上的单次采样，包含时间戳和值
- 保留策略：控制数据生命周期，包括原始保留、降采样、删除
- 与关系型数据库对比：TSDB 在写入、存储、范围查询上全面碾压，但牺牲了事务和关联查询能力
我个人习惯，选型时先看时间线数量。如果少于 10 万条，用 MySQL 也能凑合。但如果超过 50 万条，或者写入量超过每秒 1 万点，那就必须上 TSDB 了。
嗯，今天就聊到这儿。下一节咱们会深入讲讲常见的 TSDB 产品选型对比，到时候我会分享一些踩坑经历。