关于 3.0 和 2.0 的数据文件差异以及性能优化思路

如果需要对数据库性能优化,了解数据文件的存储方式和工作原理是必要的。

对于时序数据库(Time Series Database) TDengine 来说,在 2.x 版本中时序数据的保留策略是由keep和days这两个参数把控的。(详情可见:《五分钟掌握TDengine时序数据的保留策略》)我们通过 keep 和 days 来对时序数据进行分段保留,而每一段时间的数据就可以便对应着数据库中数据vnode目录下的一组数据文件,也就是我们这篇文章的主角。

在 3.0 版本中,此处逻辑保持一致,只是为了更好的体现“每一段时间的数据”,我们把 “days” 参数更名为了“duration”。而上文提到的一个数据文件组,在 2.x 版本中是这个样子的,他们代表了 vnode24 中所有表在某 10 天(days 默认参数值)内的所有数据,关于这些文件的具体含义可以参考文章:《五分钟掌握TDengine数据文件的工作原理

关于 3.0 和 2.0 的数据文件差异以及性能优化思路 - TDengine Database 时序数据库

在 2.x 的后期版本中,为了提升预计算(sum、max、min)的性能,又把 .data/.last 文件中所有数据块的预计算结果抽离出来形成了 smad/smal 文件,于是文件组变成了如下 5 个文件:

关于 3.0 和 2.0 的数据文件差异以及性能优化思路 - TDengine Database 时序数据库

到了 3.0 版本中,这个数据文件组继续演变成了下图这样的形态。那么,他们有哪些具体的变化呢?

关于 3.0 和 2.0 的数据文件差异以及性能优化思路 - TDengine Database 时序数据库

1.数据文件(.data)

其中,.data类文件逻辑保持不变,存储的是实际入库的时序数据,为多个数据块构成。一个数据块只属于一张表,除此之外,每一个数据块也都记录着预计算中的行数数据,属于预计算中的count 函数计算结果。

2.索引文件(.head)

.head 文件和此前逻辑保持不变,存储的是 .data 文件中数据块的索引信息。查询请求正是通过这些索引信息,来迅速定位表,定位时间范围,从而在 .data 文件中找到对应的数据返回给用户。

3.预计算文件(.sma)

.sma 文件:存储数据块中每列数据预计算数据的文件。文件中只存储了 .data 文件中数据块的预计算。预计算是为了加速查询,尽可能避免从硬盘中读取原始数据。.sma 等于 2.x 后期版本中的 smad 文件,而 smal 则被移除了。

4.碎片文件(.stt)

.stt 文件则是取代了 2.x 版本的 .last 文件,他们的大体功能保持一致,简单来说就是保存每一张表从内存落盘到磁盘时的碎片数据(小于 minrows),但是他们的运行机制有了一些区别:

在 2.x 版本中,当.last文件小于32k的时候,即便是当中某表的碎片数据已经满足行数(大于等于 minrows)要求合并到了.data文件,但是.last 文件仍然只是会被追加写入,而并不会清理掉这部分数据,该 32k 的限制是为了防止对文件频繁的操作影响性能。

而到了 3.0 的时候,在 .stt 文件中,属于同一个超级表的数据会存储在同一个数据块中,且数据块中的数据按照 (uid(表的唯一标识), timestamp, version)递增排列。每次落盘,数据文件组都会生成一个新的 stt 文件,用来放本次落盘中的散碎数据。当 .stt 文件个数超过一定的阈值 (由建库参数:stt_trigger 控制),则首先将多个 .stt 文件的碎片数据合并后,就会根据实际情况来决定写入 .data 文件,或写入新的 .stt 文件中。

5.性能影响:

在刨除函数本身的性能问题,和数据本身质量问题(如数据版本过多),硬件资源不足问题,数据建模不科学等因素之外。上述几个数据文件的配置对数据库性能的影响是根本性的。

整体的性能影响因素包括:

一. 关于 .data 文件,它的工作原理,整体上仍可以参考:《五分钟掌握TDengine数据文件的工作原理

二. 关于 .head 文件,它记录的是.data 文件中数据块的索引,因此数据块的数量会直接影响索引块的数量,也就会直接影响到查询性能,细节可以参考这篇文章:TDengine 3.0.2.5 查询再优化!揭秘索引文件的工作原理

三. 关于 .stt 文件,记录的是碎片化数据,对于性能的影响因素大致如下:

  1. 数据库级别 buffer 参数 (2.x 中,cache 和 block 的乘积) 的设置是否合理,如果buffer过小,导致落盘数据行数少,便会形成大量碎片影响性能。相对的,如果表过宽,导致单行数据过大,同样会导致落盘行数变少,同样影响性能,两者原理相同。
  2. minrows 设置过大,符合标准的数据块变少,导致碎片增多。
  3. 关于上文的 STT_TRIGGER 这个参数 https://docs.taosdata.com/taos-sql/database/:它代表触发 .stt 文件合并时的个数。默认为 1,范围 1 到 16。对于少表高频写入频繁触发落盘的场景,此参数建议使用默认配置,或较小的值;而对于多表场景,此参数建议配置较大的值。核心思想是会经常合并size较大的 .stt 会比较浪费磁盘io影响写入。

四. 关于 .sma 文件,预计算的聚合查询性能主要受 .sma 文件大小所影响。所以表宽/buffer/minRows/maxRows 参数都会影响,具体优化逻辑可以结合上述内容反复调试。

性能调优是十分复杂的工作,尤其是对于场景特殊,比如宽列、多表、并发、大字段等情况,各有不同的优化思路。开源版用户可以结合文章与文档进行调试,企业版用户可以直接由TDengine 团队协助定制部署、以及后面持续的运维和性能优化工作。