3、核心概念解析:时间戳、度量、标签、字段、数据精度与保留策略

各位同学,欢迎来到第三章。这一章我们不讲安装,也不讲配置。咱们先聊聊那些最基础、但最容易搞混的概念。

我见过不少团队,时序数据库用了一年多,数据也存了几个TB,结果一问「时间戳和字段有什么区别?」—— 答不上来。嗯,这其实挺危险的。概念不清,后面做查询优化、做数据建模,全都会踩坑。

今天我们就把这六个核心概念彻底掰扯清楚。你想想看,搞懂了它们,后面学什么都会顺很多。

3.1 时间戳(Timestamp)—— 数据的灵魂

时序数据,说白了就是「带时间标签的数据」。这个时间标签,就是时间戳。

我个人习惯把时间戳比作数据的「出生证明」。没有它,数据就只是一堆孤立的数字,毫无意义。

核心要点: 时间戳必须唯一标识一条数据在时间轴上的位置。同一个度量下,不允许出现两条完全相同时间戳的数据(除非你用了特殊的去重策略)。

时间戳的格式,常见的有两种:

  • Unix 时间戳(整数型):比如 1712563200,表示从1970年1月1日到现在的秒数。机器喜欢这种,计算快。
  • 字符串时间格式:比如 2025-04-08T10:00:00Z,人类看着舒服,但解析慢一些。

我在项目中遇到过一个问题:某团队把时间戳存成了字符串,结果查询时做范围过滤,性能惨不忍睹。后来改成整数型纳秒时间戳,查询速度提升了近10倍。所以我的建议是 —— 能用整数就别用字符串。

3.2 度量(Metric)—— 你在测量什么?

度量,就是你想要监控或分析的「指标名称」。比如 CPU 使用率、股票收盘价、传感器温度。

说白了,度量就是数据的「主语」。你问「今天大盘涨了多少?」—— 这个「大盘指数」就是一个度量。

在时序数据库中,度量通常对应一张逻辑表。比如:

-- 创建一个度量(以 InfluxDB 为例)
CREATE MEASUREMENT stock_price
-- 或者用 Prometheus 的写法
metric_name: stock_price

注意,度量名不要起得太随意。我见过有人用 m1m2 这种名字,三个月后自己都看不懂了。建议用有意义的英文单词,下划线分隔。

3.3 标签(Tag)—— 给数据打上「属性标签」

标签是用来描述度量「是谁的」、「从哪里来的」。比如同样是「CPU使用率」这个度量,标签可以是 host=web-server-01region=us-east

标签有两个重要特性:

  • 会被索引:查询时按标签过滤,速度极快。
  • 值通常是离散的:比如主机名、机房、股票代码。不会频繁变化。
我的经验: 标签设计是时序数据库建模中最关键的一环。我曾经帮一个客户优化,他们把所有信息都塞进了字段里,查询慢得像蜗牛。后来把「主机名」「区域」这些高频过滤条件改成标签,查询性能直接起飞。

举个反例:

-- 错误做法:把标签信息放到了字段里
stock_price,value=150.25,host=web-01,region=us-east

-- 正确做法:标签单独列出来
stock_price,host=web-01,region=us-east value=150.25

3.4 字段(Field)—— 真正的数值

字段,就是度量对应的具体数值。比如股票价格 150.25、CPU使用率 87.5

字段不会被索引,所以不要用字段来做过滤条件。你想想看,如果每条数据的数值都不一样,建索引也没意义,反而浪费空间。

字段可以包含多个值。比如一条数据同时记录「最高价」和「最低价」:

stock_price,code=000001 high=152.30,low=148.75

这里 highlow 就是两个字段。

注意: 字段的数据类型要统一。同一个字段名,不能一会存浮点数,一会存字符串。否则查询时会报类型冲突错误。我早期就吃过这个亏,数据写进去了,查出来全是 null,排查了半天。

3.5 数据精度(毫秒/微秒/纳秒)—— 时间颗粒度

数据精度,指的是时间戳的「最小刻度」。毫秒、微秒、纳秒,一个比一个精细。

精度 单位 1秒内刻度数 适用场景
毫秒 (ms) 10⁻³ 秒 1,000 普通监控、股票分钟级数据
微秒 (μs) 10⁻⁶ 秒 1,000,000 高频交易、传感器高速采集
纳秒 (ns) 10⁻⁹ 秒 1,000,000,000 极高频交易、科学实验

精度越高,存储空间越大,查询也越慢。所以不要盲目追求高精度。我见过有人把普通物联网数据存成纳秒级,结果磁盘空间一个月就爆了。

我的建议是:够用就好。股票交易数据,毫秒级足够了;高频量化交易,微秒级也够了。纳秒级?除非你在做光速级别的交易。

3.6 数据保留策略(Retention Policy)—— 自动清理过期数据

时序数据有个特点:越老的数据,价值越低。你很少会去查三年前的 CPU 使用率,对吧?

保留策略就是用来「自动删除旧数据」的。它包含三个要素:

  • 数据保留时长:比如 30 天、90 天、1 年。
  • 数据分片规则:按时间分片,方便删除和归档。
  • 副本数:保留几份数据副本,防止丢失。

举个例子,在 InfluxDB 中:

-- 创建一个保留策略:数据保留 30 天,副本 1 份
CREATE RETENTION POLICY "30_days" ON "mydb" DURATION 30d REPLICATION 1 DEFAULT

设置好之后,数据库会自动把超过 30 天的数据清理掉。你完全不用操心。

避坑指南: 我曾经帮一个金融客户排查问题,发现他们的历史数据查询越来越慢。一查,原来保留策略设了「永久保留」,数据量已经超过 10TB。后来改成 90 天自动清理,查询速度恢复了,磁盘也省了一大半。

另外,有些场景下,你不想删数据,而是想「降采样」。比如把秒级数据聚合成分钟级数据,然后删除原始秒级数据。这属于保留策略的进阶用法,我们后面会专门讲。

3.7 知识体系总览

说了这么多,我画了一张图,帮你把六个概念串起来:

时序数据库核心概念体系 一条时序数据点 ⏰ 时间戳 📊 度量 🏷️ 标签 📝 字段 🔬 数据精度 🗑️ 保留策略 每个概念都有明确的职责,组合起来构成一条完整的时序数据 一条完整的数据示例 stock_price,code=000001,exchange=SZSE high=152.30,low=148.75 1712563200000000000 度量: stock_price | 标签: code, exchange | 字段: high, low | 时间戳: 1712563200000000000 (纳秒)

你看,一条时序数据,本质上就是「在某个时间点,某个度量下,带有一组标签和字段的数值记录」。数据精度决定了时间戳的刻度粗细,保留策略决定了这条数据能活多久。

这六个概念,就像盖房子的六根柱子。搞懂了它们,后面学查询、学聚合、学数据建模,都会轻松很多。

好了,这一章就到这里。记住我今天说的这些坑,后面写代码的时候能少走不少弯路。

专注资料整理