DBPA · 15.3

时序数据库与时间窗口查询

时序数据库围绕时间写入和窗口查询组织数据

VER. 2608.3 Built with impress.js

学习目标

完成本节后，你应该能够

01判断普通 timestamp 字段为何不自动构成时序模型
02用实体、指标、序列 ID、时间戳和值描述时序模型
03区分点、记录和时间段批量写入等抽象写入类型
04区分时间范围、整体聚合、窗口聚合和降采样
05说明多序列对齐、迟到数据和窗口结果的新鲜度边界
06解释 TsFile 的层次、索引和统计信息如何支持时间范围访问

2/13

LEARNING OBJECTIVES

时序数据按事件时间连续记录对象状态

实体与指标形成序列，窗口查询再把连续点转成统计结果

车辆速度和胎压形成多条序列并按固定时间窗口计算统计结果 — 速度序列按固定窗口计算平均值；边界窗口只示意查询范围未覆盖完整窗口

实体＋指标／标签→序列 ID→事件时间戳和值→时间窗口统计时序模型要求实体和指标形成序列，普通记录的 timestamp 字段本身不够

3/13

TIME SERIES

序列 ID 把实体和指标绑定到一条观测流

tsid 是序列身份，timestamp 是数据点的时间坐标

TEXT

01
02
03
04
05
06<tsid, <time, value>*>

LFV5001.speed
(10:00, 62.0)  (10:01, 63.5)
LFV5001.pressure
(10:00, 2.4)   (10:05, 2.5)

逻辑上按事件时间组织观测；到达顺序可能不同

4/13

MODEL

抽象写入类型对应不同的设备上报形态

Point、Record、Tablet 是三种抽象写入类型，具体产品的接口可能不同

点写入 Point

表示单个速度点补报或实时上报

同刻记录 Record

表示同一实体同一时刻写入速度与胎压

时间段批量 Tablet

表示一条序列批量上传一段时间的数据

Takeaway

批量通常减少调用次数；实际存储收益取决于系统实现

5/13

WRITE PATTERNS

时间范围、聚合与降采样

先问返回原始点、一个统计值，还是每个固定窗口的统计值

查询或操作	返回	例子	主要边界
时间范围	指定区间的原始点	过去 24 小时的速度点	只限制时间区间
整体聚合	一个或少数统计值	过去 24 小时平均速度	聚合整个范围
窗口聚合	每个固定窗口的统计值	每 1 小时一个平均值	结果保留窗口边界
降采样	降低时间分辨率的窗口结果	每分钟平均速度用于长期趋势	通常保留窗口边界
多序列汇聚	按时间语义组合结果	速度与胎压对比	需要先处理对齐

Takeaway

过去 24 小时平均速度与过去 24 小时每分钟平均速度是两种不同结果

6/13

TIME QUERIES

多序列查询需要先约定时间语义

不同采样频率和缺失时间点会改变对齐结果与成本

速度：t1、t2、t4　＋　胎压：t1、t3、t4→共同时间轴→缺失点处理／重采样／窗口对齐

JOIN on timestamp 只用于类比关系操作；具体系统的多序列对齐不一定执行字面 SQL JOIN

事件时间决定数据属于哪个位置；到达时间反映系统何时看到它

Takeaway

采样频率不同、时间点缺失或重采样都会增加对齐成本

7/13

ALIGNMENT COST

TsFile 层次与索引

数据区保存序列值，索引区先缩小需要读取的数据范围

序列→Chunk Group→Chunk→Page

结构	保存内容	访问作用
Chunk Group	相关序列的 Chunk	按实体和时间组织协同读取
Chunk	一条序列的一段数据	连续时间访问
Page	一小段序列值与编码数据	最小读取单元
元数据索引	时间范围与数据位置	先定位相关 Chunk Group 或 Chunk

Takeaway

列式组织与时序编码压缩通常减少存储量和读取量；向量化可以批量处理值

长期时序数据还会形成冷热管理压力，近期数据与历史数据需要不同存储策略

8/13

TSFILE

页头统计支持剪枝与聚合

时间范围和值范围帮助排除无关页面，但是否能直接汇总取决于覆盖条件

时间／值范围→排除无关页面；页面完整覆盖窗口→可用 SUM 与 count 汇总；部分覆盖→读取原始点

时间范围和值范围主要用于定位和过滤；SUM 与点数只有在页面完整覆盖且聚合适用时才可能直接支持平均值

Takeaway

统计信息帮助剪枝，压缩帮助降低存储与读取成本，二者不是同一件事

9/13

STATISTICS

顺序/乱序写入与迟到代价

事件时间决定数据属于哪个窗口，到达时间决定系统何时看到它

事件时间递增到达→顺序空间；迟到事件→乱序空间→后台整理

以 IoTDB 为代表的实现可以采用这种组织方式；其他时序数据库的结构可能不同

迟到数据可能修正已经显示的窗口结果

Takeaway

实时结果可能因迟到数据修正；分片、路由和副本会进一步影响跨节点查询

10/13

ORDER AND OUT OF ORDER

写入、对齐与窗口判断链

时序系统的专用优化来自持续观测和时间访问，不是因为表里出现 timestamp

序列模型

实体、指标、tsid、事件时间和值组成持续观测流

写入与查询

Point、Record、Tablet 对应上报形态；范围、整体聚合与窗口降采样对应访问任务

对齐与迟到

不同采样频率需要时间语义；迟到数据可能改变已显示结果

存储取舍

TsFile、统计剪枝与顺序／乱序组织服务时间访问；冷热管理仍是背景压力

Takeaway

序列模型 → 写入与查询 → 对齐与迟到 → 文件层次与存储取舍

11/13

RECAP

本节知识地图

12/13

KNOWLEDGE MAP

本节问题

01速度、胎压、油耗如何设计序列 ID？实体、指标、标签各起什么作用？
02同时上报、单点补报、一小时批量上传分别适合哪种写入类型？
0324 小时平均速度与每分钟平均速度分别属于什么操作？
04不同采样频率的速度与胎压如何对齐？缺失点有何代价？
05完整窗口平均值何时可由页头统计避免读取原始值？压缩解决什么问题？
06迟到数据为何改变窗口结果？影响属于写入/乱序还是窗口/聚合？

13/13

CHECK YOUR UNDERSTANDING