TDengine 3.0 尽管对底层做了大规模的优化重构，然而绝对于数据文件的工作逻辑和 2.0 相比是整体放弃不变的。本系列文章的宗旨在于帮忙用户深刻了解产品，并且领有根本的性能调试思路，从而取得更好的产品体验。
本期文章会在解说 TDengine 时序数据库 (Time Series DataBase) 的索引文件（.head 文件）工作原理的同时，介绍索引文件在最新的 TDengine 3.0.2.5 中的优化。而在下一期的文章中，会对两大版本数据文件的差别做一个总结式的阐明。如下是 TDengine 的数据文件的构造——也就是这个四位一体的文件组。
在此前的文章，次要讲述的是 .data 和 .last（3.0 中曾经更名为 .stt 文件）文件的工作原理。详情可见：https://mp.weixin.qq.com/s/OGS1WIlySSKveEOk4Reg3Q
接下来，咱们将和大家一起以产品使用者的视角持续向前摸索，揭开.head 文件的原理。
.head 类文件存储了 .data 文件中的数据块的索引信息。在.data 文件中的每个数据块的 BRIN 索引信息在 .head 类文件中以表为分组，依照工夫程序递增，造成索引块组。（注：硬盘上的数据用的是 BRIN 索引，在落盘之前的内存数据用的是 skiplist 索引。）在查问的时候，会先加载这个 .head 文件中的索引信息，从而找到 .data 文件中的时序数据返回给用户。
（注：BRIN 索引指的是 Block Range Index，次要实用于有着人造程序的数据集，因为不须要再做排序，所以资源消耗少，非常符合时序数据的查问，也是 TDengine 和关系型数据库的外围区别之一。）
一个清晰可见的逻辑是——索引的作用是帮忙咱们疾速定位数据的地位，但当你操作索引的工夫变得特地长的时候，索引的价值无形之中就会变低了。所以，在 .head 文件较大的时候就可能会呈现影响查问性能的瓶颈。
而影响 .head 文件大小的因素有两个：
- 一是 maxrows 和 minrows 这两个参数。很好了解，同样 1000 行数据，maxrows=200 须要 5 个数据块，maxrows 为 1000，只须要 1 块。每个数据块都须要一条索引信息存储在 .head 文件中。（详情可参考：https://mp.weixin.qq.com/s/OGS1WIlySSKveEOk4Reg3Q）
- 另一个会让 .head 文件十分大的参数是 duration（即 2.0 中的 days）。咱们晓得 duration 是管制单个数据文件存储数据天数的参数 (详情可参考：https://mp.weixin.qq.com/s/uJEQwN0NnmSTBAMOecAtoA)。所以如果 duration 很大的话，单个数据文件存储的数据量就肯定也很大，数据块就会很多。
以上的实践场景是实在产生过的——之前咱们在反对某企业用户的时候，就曾遇到过生产环境上 duration 参数设置为 1000 多天导致数据查问性能重大降落的状况。然而因为 duration 参数建库后不能批改，所以最初只能导出数据，从新建库批改为正当的 duration 后再导回，这样问题才得以解决。（所以，默认值取 duration 为 10 就是一个折中的抉择，理论应用时能够依据查问类型和机器性能灵便调试。）另外一个用户则是查问时间跨度大，查问并发量大，导致大量的服务器资源被用于读取 .head 文件影响了查问性能。
如果说前者还属于参数使用不当的话，第二个场景的查问并发量则是由用户的业务场景所决定的，因而咱们针对后者的潜在瓶颈，在最新的 TDengine 3.0.2.5 中，针对 .head 文件做了一项重磅的优化——对于罕用的表索引数据，会被放在缓存中（LRU 算法）。
这样一来，即使是不同的查问工作，只有所查问的表索引还在池子中缓存着，便不须要反复地读取 .head 文件了。因为波及已落盘数据的查问根本都须要去首先拜访 .head 文件，因而，该优化使得整体查问性能都失去了晋升，而在特定场景下（如高并发）造成了较大幅度的冲破。
结语
联合之前的几篇文章能够看到：keep，duration，maxRows，minRows 这些参数非亲非故，牵一发而动全身，是不能够轻易改变的，它们的数值不管过大还是过小都会引起应用问题。如果因为孤立地对待某个参数而带来了问题，用户可能会误以为这是产品自身的问题。因而，很多时候默认配置也是“很香”的。
而对于性能要求较高的用户，也能够通过熟读文档、代码、技术文章、视频等材料来调整参数以达到最佳性能，也欢送分割 TDengine 时序数据库 (TSDB) 官网征询企业版，以取得全方位的技术支持。
在最新公布的 3.0.2.5 上，咱们还做了很多其余优化，稳定性和性能进一步晋升。因为 3.0.2.x 是以后 3.0 的稳定版，因而版本号越大各方面都是越好的，倡议大家能够尽快更新至最新版本。