核心特性解析：数据时效性、高并发写入、时序数据模型、数据压缩与过期策略
好，咱们直接进入正题。实时数据库选型，说白了就是看它能不能扛住这几个核心场景。我这些年踩过的坑，十有八九都跟这几个特性有关。今天咱们一个一个拆开聊。
数据时效性：别让数据「凉」了
实时系统的第一要义是什么？数据要「热」。你想想看，监控系统里延迟5秒的CPU数据，跟延迟5分钟的数据，完全是两个世界。
时效性通常用P99延迟来衡量。比如你要求99%的数据在100毫秒内写入并可见。我见过不少团队，选型时只看平均延迟，结果上线后P99直接崩到秒级。嗯，这里要注意：平均延迟是骗人的，P99才是真相。
关键指标：
- 写入到可查询的延迟（端到端）
- P99/P999 延迟分布
- 数据分片间的同步延迟
我个人习惯，在压测时直接看P999。为什么？因为P99可能还藏着一些慢查询，P999才是系统真正的「短板」。我在项目中遇到过，某数据库P99只有50ms，但P999直接飙到2秒——后来发现是GC停顿导致的。
高并发写入：扛住百万级TPS
时序数据的写入模式跟传统OLTP完全不同。它不是一条一条插，而是一批一批来。你想想看，一台服务器每秒采集1000个指标，1000台服务器就是每秒100万条数据。
高并发写入的核心挑战：
- 写入吞吐：单节点能扛多少TPS？集群能线性扩展吗？
- 写入一致性：强一致还是最终一致？
- 写入冲突：时序数据几乎无冲突，但索引更新可能有瓶颈
我曾经踩过一个坑：选了个号称支持「百万级写入」的数据库，结果上线后发现，它的写入性能跟数据点的时间戳顺序强相关。乱序写入一多，性能直接腰斩。所以，一定要用真实业务的数据模式去压测，别信厂商的benchmark。
避坑指南：我曾经以为所有时序数据库都支持乱序写入，直到某次压测发现写入延迟从10ms涨到500ms。后来查文档才发现，那个数据库的LSM-Tree对乱序数据有严重的写放大问题。选型前，务必确认你的数据是「顺序到达」还是「乱序到达」。
时序数据模型：时间戳+标签+值
时序数据的模型其实很简单，就三个要素：
- 时间戳：数据产生的时间，精度从毫秒到纳秒不等
- 标签（Tags）：描述数据来源的维度，比如机器ID、机房、服务名
- 值（Fields）：实际的测量值，可以是数值、字符串甚至布尔值
但简单归简单，设计不好照样翻车。我见过一个团队，把机器ID、机房、服务名、CPU型号、内存大小全部塞进标签里。结果呢？标签基数爆炸，索引膨胀到比数据本身还大。
标签设计原则：
- 低基数标签：取值数量在几千以内的，适合做标签
- 高基数属性：比如请求ID、用户ID，别放标签里，放字段里
- 标签组合：每个时间序列由标签组合唯一标识，组合数不能太大
举个例子：
// 好的设计
measurement: cpu_usage
tags: host="web-01", region="us-east-1"
fields: usage_percent=75.2
timestamp: 2024-01-01T00:00:00Z
// 坏的设计
measurement: cpu_usage
tags: host="web-01", region="us-east-1", request_id="abc123"
fields: usage_percent=75.2
timestamp: 2024-01-01T00:00:00Zrequest_id 是高基数标签，会导致索引爆炸。正确的做法是把它放到 fields 里，或者干脆不存。
数据压缩：省的不只是存储成本
时序数据有个特点：相邻数据点的值变化很小。比如CPU使用率，上一秒75.2%，下一秒75.3%。这种规律性，让时序数据的压缩率可以非常高。
常见的压缩算法：
| 算法 | 适用场景 | 压缩比 | 特点 |
|---|---|---|---|
| 差值编码 | 整数型数据 | 5:1 ~ 10:1 | 只存相邻值的差值，适合稳定变化的数据 |
| 游程编码 | 重复值多的数据 | 10:1 ~ 50:1 | 比如状态码200连续出现1000次，只存一次 |
| 浮点数压缩 | 浮点型数据 | 3:1 ~ 8:1 | Facebook的Gorilla算法，专为时序数据设计 |
| 字典压缩 | 字符串标签 | 5:1 ~ 20:1 | 把重复的字符串映射成整数ID |
我个人习惯，选数据库时先看它用什么压缩算法。如果只用了通用压缩（比如Snappy、Zstd），那压缩率大概率不够。真正优秀的时序数据库，会针对时序数据的特点做定制压缩。
小技巧：我在项目中测试过，同样的数据，用Gorilla算法压缩后只有原始大小的1/10，而用Snappy只能压到1/3。但Gorilla的压缩和解压速度比Snappy慢一些。所以，如果IO是瓶颈，选高压缩率；如果CPU是瓶颈，选快压缩。
数据过期策略：自动清理，别让存储爆炸
时序数据有个天然属性：越老的数据，价值越低。你想想看，谁会关心一年前某台服务器的CPU使用率？除非在做容量规划或者故障复盘。
常见的过期策略：
- TTL（Time To Live）：给数据设置一个存活时间，到期自动删除。比如保留30天。
- 降采样（Downsampling）：老数据不删，但降低精度。比如1秒粒度的数据保留7天，之后聚合为1分钟粒度保留30天，再之后聚合为1小时粒度保留1年。
- 分区删除：按时间分区，直接删除整个分区文件。比逐条删除快得多。
我建议的实践方案：
- 热数据（最近7天）：原始精度，全量保留
- 温数据（7天~30天）：降采样到1分钟粒度
- 冷数据（30天~1年）：降采样到1小时粒度
- 归档数据（1年以上）：导出到廉价存储，比如对象存储
注意：我曾经在项目里只设置了TTL，没做降采样。结果30天前的数据直接删了，做容量规划时发现历史趋势全没了。后来加了降采样策略，既保留了长期趋势，又控制了存储成本。记住：删除容易，恢复难。
总结一下
这四个特性，是实时数据库的「四根柱子」。缺一根，系统就站不稳。
- 数据时效性：别被平均延迟骗了，盯紧P99和P999
- 高并发写入：用真实数据模式压测，别信benchmark
- 时序数据模型：标签设计要克制，高基数属性放字段里
- 数据压缩与过期：压缩算法选对，存储成本降一半；过期策略要分层，别一刀切
嗯，这些就是我这些年摸爬滚打总结出来的经验。下一章咱们聊聊具体的选型对比，看看市面上主流的时序数据库到底谁强谁弱。
公众号:蓝海资料掘金营，微信deep3321