一、InfluxDB 与 TSM 文件初相识

**

在数字化时代，数据量呈爆发式增长，尤其是时间序列数据，如服务器监控指标、传感器读数、金融交易记录等，它们都带有时间戳，记录着事物随时间的变化。InfluxDB 作为一款高性能的开源时序数据库，在处理这些时间序列数据方面发挥着举足轻重的作用 ，被广泛应用于监控系统、物联网、实时分析、金融交易监控、环境监测等诸多场景。

InfluxDB 采用 Go 语言编写，这赋予了它出色的性能和跨平台特性，编译后生成的二进制文件无外部依赖，部署和运行都极为便捷。其独特的设计专为高效存储和查询时间序列数据而生，在性能、功能特性等方面都展现出卓越的优势。在性能上，它的时间结构合并树（TSM，Time-Structured Merge Tree）存储引擎基于日志结构化合并树（LSM，Log-Structured Merge Tree）演变而来，针对时间序列数据的特点进行了深度优化，能够实现高速的数据读写和高效的数据压缩。在单机环境下，每秒可支持数十万数据点的写入操作，轻松应对大规模数据的快速写入需求 。从功能特性来看，InfluxDB 支持类 SQL 的查询语言 InfluxQL，让熟悉 SQL 语法的开发者能迅速上手，方便地对时间序列数据进行查询和分析。同时，它允许对 tag 建立索引，通过标签可以灵活地对数据进行分组、过滤和查询，实现快速有效的数据检索。此外，InfluxDB 还具备丰富的聚合运算和采样能力，提供了一系列如 MIN、MAX、SUM、COUNT、MEAN、MEDIAN 等聚合函数，方便用户对数据进行统计分析；还支持连续查询（CQ，Continuous Query）功能，可以自动定时执行查询操作，并将结果存储起来，有效减少重复计算，提高查询效率。

在 InfluxDB 的存储体系中，TSM 文件扮演着核心角色。它是 InfluxDB 自研的一种存储引擎，将时序数据和索引数据一同存储在一个文件中。在 data 文件夹下，每个数据库都对应有一个子文件夹，而这个子文件夹里存储的正是该数据库的所有 TSM 文件 。这种独特的存储方式极大地减少了磁盘 I/O 的开销，进而提高了查询性能。当数据写入 InfluxDB 时，首先会被记录在内存中的写入缓冲区，待缓冲区满了或达到特定时间间隔后，数据就会被批量写入磁盘上的 TSM 文件 。在查询数据时，InfluxDB 会依据 TSM 文件中的索引快速定位到所需数据，从而实现高效查询。例如，在一个实时监控系统中，需要频繁查询服务器的 CPU 使用率、内存利用率等指标数据，TSM 文件的高效存储和查询机制就能确保系统快速响应，及时为运维人员提供准确的数据支持。

二、探秘 TSM 文件管理

（一）TSM 文件结构剖析

TSM 文件主要由头部信息（Header）、数据块（Blocks）、索引（Index）和页脚（Footer）这几个关键部分组成，它们各司其职，共同保障了 InfluxDB 高效的数据存储和查询功能。

• 头部信息：占据 5 个字节，其中 4 个字节用于存储识别文件类型的神奇数字，就像是文件的独特 “指纹”，能让系统快速知晓这是一个 TSM 文件；另外 1 个字节记录文件的版本号，便于系统在进行版本升级或兼容性处理时做出准确判断。比如当 InfluxDB 进行版本更新，引入了新的 TSM 文件格式特性时，通过版本号就能确定该文件是否符合新特性的要求，从而进行相应的处理 。

• 数据块：由一系列的 CRC32 校验和与数据对构成。CRC32 校验和就如同数据的 “保镖”，负责在数据传输和存储过程中检测错误，一旦数据出现损坏或丢失，通过 CRC32 校验和就能及时发现 。数据块中的数据是经过压缩处理后存储的，这大大减少了磁盘空间的占用，提高了存储效率。例如，在存储大量传感器采集的时间序列数据时，经过压缩的数据块能显著降低存储成本，同时在读取数据时，也能快速解压缩还原出原始数据 。

• 索引：索引部分按照键（包括测量名称、标签集和字段）然后按时间字典顺序排列索引条目序列。这种有序排列的方式，就像是一本精心编排的字典，让系统能通过索引快速定位到所需数据。例如，当我们要查询某个特定服务器在某段时间内的 CPU 使用率时，通过索引中键和时间的有序排列，系统能迅速定位到包含这些数据的索引条目，进而找到对应的数据块，大大提高了查询效率 。每个索引条目都包含键长度、键、块类型（如浮点型、整数型、布尔型、字符串等）、索引块条目数、最小时间、最大时间、偏移量和大小等信息 。这些详细的信息就像是数据的 “坐标”，通过它们可以准确地找到数据在 TSM 文件中的存储位置 。

• 页脚：虽然只有 4 个字节，但却保存着索引的偏移量，这个偏移量就像是通往索引的 “钥匙”，系统通过它可以快速定位到索引部分，从而开启查询数据的大门 。

（二）TSM 文件的写入流程

数据写入 InfluxDB 到最终写入 TSM 文件，需要经历一系列严谨的步骤。

1. 写入 WAL：当数据进入 InfluxDB 时，首先会被写入预写日志（WAL）。WAL 就像是一个数据的临时 “保险柜”，它采用追加写入的方式，将数据以固定格式存储，确保写入操作的持久性 。即使系统突然崩溃，也能从 WAL 中恢复未持久化到 TSM 文件的数据 。例如，在一个实时监控系统中，大量的服务器性能数据不断涌入 InfluxDB，这些数据首先被安全地存入 WAL，为后续的处理提供了可靠保障 。每个 WAL 文件被划分为固定大小的段，当一个段的大小达到 10MB 时，就会关闭当前段并打开一个新的段继续写入 。数据在写入 WAL 时，会先进行序列化处理，然后使用 Snappy 压缩算法进行压缩，以减少存储空间占用，压缩后的数据按照 TLV 标准存储，即单个字节表示条目的类型（写入或删除）、4 个字节的 uint32 表示压缩块的长度，然后是压缩块 。

1. 写入内存缓存：在数据写入 WAL 的同时，也会被写入内存缓存（Cache）。Cache 是 WAL 中数据在内存中的副本，它按照键（测量值、标签集和唯一字段）对数据进行组织，每个字段都按自己的时间顺序范围保存 。Cache 就像是一个高速的数据 “缓冲区”，查询操作可以直接在 Cache 中进行，提高了查询响应速度 。当查询运行时，写入操作不会影响 Cache 中的数据副本，保证了查询结果的一致性 。Cache 还设置了一些内存阈值和时间阈值来控制数据的写入和快照操作。当 Cache 的内存使用量超过 cache - snapshot - memory - size（下限）时，会触发将 Cache 中的数据快照写入 TSM 文件，并删除相应的 WAL 段；当 Cache 的内存使用量超过 cache - max - memory - size（上限）时，Cache 将拒绝新的写入，以防止内存不足 。此外，如果在指定的时间间隔（cache - snapshot - write - cold - duration）内没有收到写入操作，也会强制将 Cache 中的数据快照保存到 TSM 文件 。

1. 批量合并到 TSM 文件：当满足一定条件时，比如 Cache 达到内存阈值或者经过一定的时间间隔，Cache 中的数据会被批量合并到 TSM 文件中 。这个过程就像是将分散的文件整理成一个大文件，将多个小的数据块合并成一个大的数据块，减少了文件数量和磁盘 I/O 操作，提高了存储和查询效率 。在合并过程中，还会对数据进行压缩和优化处理，进一步减少磁盘空间占用 。例如，在每天凌晨系统负载较低时，将当天积累在 Cache 中的数据批量合并到 TSM 文件中，为后续的查询和分析做好准备 。

（三）TSM 文件的查询机制

InfluxDB 通过索引实现对 TSM 文件中数据的快速定位和查询，这一过程依赖于高效的索引结构和查询算法。

1. 索引定位：当接收到查询请求时，InfluxDB 首先会根据查询条件在内存索引中查找对应的索引条目。内存索引就像是一个快速检索的 “目录”，它存储了测量名称、标签集和系列等信息的索引，能快速定位到可能包含所需数据的 TSM 文件 。例如，当查询某个特定设备在某段时间内的温度数据时，内存索引会根据设备的标签信息快速定位到对应的 TSM 文件 。找到对应的 TSM 文件后，会根据索引中的键和时间信息，在 TSM 文件的索引部分进行二分查找，进一步缩小数据范围 。由于 TSM 文件索引中的条目是按键和时间字典顺序排列的，二分查找能够快速定位到包含所需数据的索引条目，从而确定数据所在的数据块位置 。

1. 数据读取：确定数据块位置后，通过索引条目中记录的偏移量和大小信息，就可以从 TSM 文件中读取相应的数据块 。读取到的数据块是经过压缩的，需要使用相应的解压缩算法进行解压缩，还原出原始数据 。在读取数据时，还会根据 CRC32 校验和对数据进行校验，确保数据的完整性和准确性 。如果校验失败，说明数据可能在存储或传输过程中出现了错误，会采取相应的处理措施，如重新读取数据或返回错误信息 。

1. 查询算法优化：为了进一步提高查询性能，InfluxDB 还采用了一些查询算法优化策略。例如，谓词下推（Predicate Pushdown）技术，它会将查询条件尽可能地提前应用到数据读取阶段，只读取满足查询条件的数据，减少不必要的数据传输和处理 。在查询某个时间段内温度大于某个阈值的数据时，谓词下推技术会在读取 TSM 文件数据块时，就过滤掉不符合温度阈值条件的数据，只返回满足条件的数据，大大提高了查询效率 。此外，InfluxDB 还支持向量化执行（Vectorized Execution），它将数据按列进行批量处理，利用现代 CPU 的 SIMD（Single Instruction Multiple Data）指令集，一次处理多个数据元素，进一步加速查询操作 。在进行聚合计算时，向量化执行可以同时对多个数据点进行计算，减少了指令执行次数和数据访问次数，提高了计算效率 。

三、InfluxDB 空间回收大揭秘

（一）空间回收的重要性

在 InfluxDB 的实际应用中，随着数据不断写入和删除，磁盘空间的管理变得至关重要。如果不能及时回收被删除数据所占用的空间，磁盘空间会逐渐被填满，不仅会影响系统的正常运行，还可能导致数据写入失败或查询性能急剧下降 。在一个实时监控大量服务器的场景中，每天会产生海量的监控数据，同时也会根据数据保留策略删除旧数据。若空间回收不及时，磁盘空间很快就会被占满，新的监控数据无法写入，服务器的实时状态无法被准确监测，运维人员也就无法及时发现和解决服务器可能出现的问题 。此外，合理的空间回收还能提高存储资源的利用率，降低存储成本，让有限的存储资源发挥更大的价值 。通过及时回收空间，可以将释放出来的空间用于存储更有价值的数据，避免了因存储不足而需要购买额外存储设备的成本支出 。

（二）数据删除与墓碑文件

在 InfluxDB 中，当执行数据删除操作时，并不会立即将数据从磁盘上的 TSM 文件中物理删除 。这是因为直接物理删除数据会涉及到复杂的文件操作和数据重排，会严重影响系统的性能和稳定性 。InfluxDB 采用了一种更为高效的方式，即生成墓碑文件（Tombstone File） 。当用户执行删除操作时，InfluxDB 会在 WAL 中写入删除条目，并更新内存中的索引，标记相应的数据为已删除 。同时，会为包含这些被删除数据的 TSM 文件生成一个墓碑文件 。墓碑文件就像是一个特殊的 “标记”，它记录了被删除数据在 TSM 文件中的位置和范围等信息 。在 InfluxDB 启动时，会读取墓碑文件，忽略掉被标记为删除的数据块，从而避免读取这些无效数据 。在进行数据合并（Compaction）操作时，墓碑文件中的信息会被用来移除已删除的数据，真正释放磁盘空间 。例如，在一个存储传感器历史数据的 InfluxDB 数据库中，当删除某段时间内的传感器数据时，并不会立即清空 TSM 文件中的这些数据，而是生成墓碑文件标记它们 。这样在后续的查询中，系统会自动跳过这些被标记的数据，而在数据合并时，这些被标记的数据会被彻底移除，实现空间回收 。

（三）压缩与合并：释放空间的关键

InfluxDB 通过压缩和合并 TSM 文件来回收空间，这是其空间回收机制的核心环节 。

• 压缩算法的选择：InfluxDB 采用了专门针对时间序列数据设计的压缩算法，如 Gorilla 压缩算法 。这种算法充分利用了时间序列数据的特点，即数据在时间上具有连续性和相关性，相邻数据点之间的变化通常较小 。Gorilla 算法通过对整数和浮点数进行编码，能够实现高压缩比，有效减少数据存储所需的磁盘空间 。在存储大量传感器采集的温度数据时，由于温度变化相对平稳，Gorilla 算法可以将这些数据压缩到很小的体积，大大节省了存储空间 。同时，这种算法在读取数据时的解压速度也非常快，能够满足实时查询对数据读取速度的要求 ，确保系统能够快速响应查询请求，将解压后的数据及时返回给用户 。

• 合并策略：InfluxDB 会定期对 TSM 文件进行合并操作 。当系统中存在多个小的 TSM 文件时，合并操作会将这些小文件合并成一个大的 TSM 文件 。在合并过程中，会对数据进行重新组织和优化，移除墓碑文件标记的已删除数据，从而实现空间的回收 。合并操作还能减少文件数量，降低文件系统的管理开销，提高查询性能 。因为在查询数据时，需要遍历的文件数量减少了，数据定位和读取的速度也就更快了 。例如，在每天夜间系统负载较低时，InfluxDB 会自动触发 TSM 文件的合并操作，将当天生成的多个小 TSM 文件合并成一个或几个大的 TSM 文件，在释放磁盘空间的同时，也为第二天的数据写入和查询做好了准备 。