时序数据库与NewSQL：InfluxDB时序数据模型与TSM存储引擎

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

时序数据特征

排水监控中心的雨量计不是“每隔一周交一份周报”，而是每一秒都递来一张小天条。一分钟积累六十条，一台设备一天就是八万六千多条；整座城市有上万台设备，数据量会像暴雨后的积水一样迅速上涨。更关键的是，这些数据几乎不会回头修改：传感器只追加新记录，很少去更新昨天那条水位值，这是一种典型的“顺序追加型写入”。

如果把时序数据当成银行账户流水来管理，数据库会为随机更新付出大量锁和索引开销；但这里的数据天然按时间排列，查询也天然带着时间范围：“三分钟前”“最近一小时”“上周二”。于是 InfluxDB 把时间戳当作第一公民，围绕时间轴来组织一切。数据越新越常被访问，越老越少被访问，形成明显的冷热分层，这为后续的分片和压缩提供了线索。

规划存储规模时，可以先做一个简单估算：

一旦理解了这种高频、海量、按时间聚合的数据特征，就能明白 TSM 存储引擎为什么要把“批量顺序写”和“时间分片”作为头等大事——不是偶然选择，而是被数据形态逼出来的。

数据模型基础

档案室的每一条雨水记录都装在一个信封里：信封正面写明它属于哪个档案柜，这是 measurement；信封上贴着五颜六色的标签，用于快速检索，这是 tag；信封里装的实测数据，这是 field；信封右上角的邮戳时间，则是 timestamp。InfluxDB 中一条 point，就是这样一个完整信封。

measurement 相当于关系数据库里的表，例如 rain；tag 是键值对，如 area=east、type=bridge，它默认被建索引；field 也是键值对，如 level=1.2、temperature=23.5，保存真正的测量值，默认不建索引；timestamp 是纳秒级时间戳，与 tag 一起决定这条数据“属于哪个序列的哪个时刻”。

这个数据模型可以浓缩成一个式子：

把四者拆开，InfluxDB 就能在写入时知道该给哪些内容建索引、把哪些内容送去压缩，而不会像普通表格那样对每一列都一视同仁。

标签索引设计

档案管理员要回答“东城区所有立交桥的积水记录”，不会挨个打开档案盒翻。他会先看一本标签台账：area=east 指向一批序列，type=bridge 指向另一批序列，两批求交集，就能迅速锁定候选档案盒。这本台账，就是 InfluxDB 的倒排索引。

倒排索引的思路是：为每个标签值建立一条“哪些序列包含这个标签值”的列表。例如 floor=3 对应序列 A、B、C，host=web-2 对应序列 B、D。查询时先通过标签定位序列，再结合时间范围扫描具体数据块，而不是从第一条记录开始遍历。

查询条件组合可以看作集合的交运算：

标签设计不能贪多：如果给每个设备唯一编号都做成标签，基数会爆炸，倒排索引占用的内存也会疯涨。所以 InfluxDB 社区的黄金法则是：低频变化、常作为查询条件的放 tag；高频变化、不需要索引的数值放 field。

时间分片机制

档案室不会把所有年份的档案混在一个大仓库，而是按月装箱：1 月一个货架区，2 月一个货架区。这样要查“上周二”的记录，只需走进对应的一个月盒，而不是把十年档案都翻一遍。InfluxDB 的 shard（分片）就是这种“时间箱”。

每个 shard 覆盖一个确定的时间区间，例如 7 天。在一个 shard 内部，数据按序列组织，并对应一组 TSM 数据文件。保留策略（retention policy）的删除也以 shard 为单位：数据过期时，直接丢弃整个 shard，而不是逐条删除记录，这让清理成本极低。

一个数据库会有多少个 shard，可以用除法估算：

分片不能拍脑袋定大小：太小会产生大量小文件，太大又会让查询扫过太多无关数据。实际部署时通常结合写入速率、查询时间范围和保留策略共同决定。

TSM引擎基础

档案室的收件系统有一条流水线：新送来的便条先放到“临时收件台”上，同时登记员在一本“收件登记簿”上写一笔，防止便条丢失；当收件台堆满后，工作人员把它们按时间排好序，封进一个只读的“档案砖”；以后档案砖积累多了，再被后台合并成大砖。这就是 TSM 引擎的骨架，也是 LSM 树思想在时序数据上的变体。

LSM 树的核心智慧是：把昂贵的随机写变成廉价的顺序写。数据先写内存结构，达到阈值后一次性刷到磁盘，生成不可变文件；后续查询需要读多层文件，因此还要定期合并，减少数据版本。InfluxDB 的 TSM 文件继承了这种“先攒批，再落盘”的节奏，但每个文件内部不是普通键值对，而是按时间序列组织的列式数据块。

为什么 LSM 宁愿多做合并，也要坚持顺序写？因为磁盘随机访问的代价远大于顺序访问：

理解了这套“先内存、再落盘、后合并”的节奏，再看 TSM 的 WAL、快照和压缩流程，就不会觉得它们是零散技巧，而是同一思想的不同环节。

列式存储压缩

普通档案室会把一份报告的日期、地点、数值、备注都放在同一张纸上；而 TSM 档案室更聪明：它把同一段时间内同一种数值单独装订成册。比如把一万个传感器在五分钟内的水位值单独列成一张表，而不是和温度、湿度混在一起。这种“按列集中存放”的布局，让压缩算法能发现更多规律。

时序数据最有规律的字段是时间戳：同一序列的时间戳严格递增，相邻差值往往很小且稳定。于是 InfluxDB 不直接存储完整时间戳，而是存储相邻时间戳的差值，用更少的字节表达同样的信息；如果差值重复出现，还能进一步用游程编码压缩。

一次典型的差分编码是这样的：

列式布局加差分编码，是 TSM 磁盘占用低的关键。这也是为什么它擅长处理“很多传感器、每隔几秒写一条”的场景：数据规律越强，压缩率越高。

写入合并流程

档案室的收件流程有明确顺序：便条到达后，登记员先在“收件登记簿”（WAL）上写一笔，再把便条放在临时收件台（内存缓存）。这样做的好处是，即使档案馆突然停电，也能靠登记簿找回还没归档的便条。当收件台放满到阈值，工作人员便把台面上的便条按时间排好序，封进一个新的 TSM 档案砖。

此后，后台的合并程序会周期性检查档案砖数量。小砖太多，查询就要读太多文件，所以合并程序把多个小砖合并成大砖，同时清理已经被标记删除的旧数据。这个“合并”动作不是随手做，而是有触发条件的。

内存缓存何时刷盘，可以写成：

每个 TSM 文件还带一份稀疏索引，记录数据块的最小、最大时间和序列范围。查询时先看这份“目录”，能直接跳过无关文件和数据块，避免全文扫描。

查询优化思路

现在回到最开始的难题：找出东城区所有立交桥过去五分钟水位超过一米二的点。聪明的档案管理员不会搬出整座档案库，而是执行三步：先查标签台账，锁定“东城区”和“立交桥”对应的序列；再查每个时间箱的封面，只打开最近五分钟那个 shard；最后在 TSM 文件里，只看水位这一列的数据块，而不是把湿度、温度也全读出来。

这套流程对应 InfluxDB 的查询优化：时间范围裁剪负责跳过过期 shard，标签过滤负责缩小序列集合，列式存储让系统只解压需要的字段，聚合下推则把最大值、平均值等计算尽量下沉到数据块层面。

一次查询的耗时可以粗略拆解为：

所以，设计表结构时多花心思选好标签、定好分片时长，实际上是在为查询优化铺路：让系统能跳过更多文件、解码更少数据，最终用更短时间回答“过去五分钟发生了什么”。

AI 应用场景

Python 演示

from collections import defaultdict  class Point:    def __init__(self, measurement, tags, fields, ts):        self.measurement = measurement        self.tags = tags        self.fields = fields        self.ts = ts     def to_line(self):        tag_str = ",".join(f"{k}={v}" for k, v in sorted(self.tags.items()))        field_str = ",".join(f"{k}={v}" for k, v in sorted(self.fields.items()))        return f"{self.measurement},{tag_str} {field_str} {self.ts}"  class MiniTSM:    def __init__(self, max_mem=4):        self.max_mem = max_mem        self.mem_count = 0        self.segments = []        self.series_index = defaultdict(set)     def write(self, point):        self.mem_count += 1        key = point.measurement + "|" + ",".join(f"{k}={v}" for k, v in sorted(point.tags.items()))        self.series_index[key].add(point.ts)        if self.mem_count >= self.max_mem:            self.flush()     def flush(self):        self.segments.append(self.mem_count)        self.mem_count = 0     def compact(self):        if len(self.segments) >= 3:            total = sum(self.segments)            self.segments = [total]     def query(self, measurement, tag_query, start, end):        hits = []        key = measurement + "|" + tag_query        for point_ts in self.series_index.get(key, []):            if start <= point_ts <= end:                hits.append(point_ts)        return hits  def main():    engine = MiniTSM(max_mem=4)    p1 = Point("rain", {"area": "east", "type": "bridge"}, {"level": 1.2}, 100)    p2 = Point("rain", {"area": "east", "type": "bridge"}, {"level": 1.5}, 200)    p3 = Point("rain", {"area": "west", "type": "road"}, {"level": 0.8}, 150)    p4 = Point("rain", {"area": "east", "type": "bridge"}, {"level": 2.1}, 300)    for p in (p1, p2, p3, p4):        engine.write(p)        print("write:", p.to_line())    engine.compact()    print("segments:", engine.segments)    print("query:", engine.query("rain", "area=east,type=bridge", 100, 250))  if __name__ == "__main__":    main()

1. key = point.measurement + "|" + ",".join(f"{k}={v}" for k, v in sorted(point.tags.items()))把表名和排序后的标签拼接成序列键，保证相同标签集一定对应同一个索引项。
2. self.series_index[key].add(point.ts)在倒排索引中记录该序列出现过的所有时间点，等价于标签台账。
3. if self.mem_count >= self.max_mem:内存计数达到阈值，触发一次刷盘。
4. self.segments.append(self.mem_count)把当前内存中的记录数封存为一个只读段，模拟 TSM 文件生成。
5. if len(self.segments) >= 3:小段数量达到三个，就触发合并，模拟后台 compact。

常见误区

面试题