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

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

对于时序数据库（Time Series Database） TDengine 来说，在 2.x 版本中时序数据的保留策略是由 keep 和 days 这两个参数把控的。（详情可见：https://mp.weixin.qq.com/s/uJEQwN0NnmSTBAMOecAtoA）我们通过 keep 和 days 来对时序数据进行分段保留，而每一段时间的数据就可以便对应着数据库中数据 vnode 目录下的一组数据文件，也就是我们这篇文章的主角。

在 3.0 版本中，此处逻辑保持一致，只是为了更好的体现“每一段时间的数据”，我们把 "days" 参数更名为了“duration”。

而上文提到的一个数据文件组，在 2.x 版本中是这个样子的，他们代表了 vnode24 中所有表在某 10 天（days 默认参数值）内的所有数据，关于这些文件的具体含义可以参考官方文档和：https://mp.weixin.qq.com/s/OGS1WIlySSKveEOk4Reg3Q

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

到了 3.0 版本中，这个数据文件组继续演变成了下图这样的形态。

那么，他们有哪些具体的变化呢？

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 文件，它的工作原理，整体上仍可以参考：https://mp.weixin.qq.com/s/OGS1WIlySSKveEOk4Reg3Q

二. 关于 .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 团队协助定制部署、以及后面持续的运维和性能优化工作。