TDengine 3.0.2.5 查询再优化！揭秘索引文件的工作原理

涛思数据（TDengine）

于 2023-02-14 15:35:56 发布

阅读量700

点赞数

分类专栏： TDengine技术解密文章标签： tdengine 大数据时序数据库 Powered by 金山文档

本文链接：https://blog.csdn.net/taos_data/article/details/129027926

版权

TDengine技术解密专栏收录该内容

96 篇文章 29 订阅

订阅专栏

文章详细介绍了TDengine时序数据库的.index文件（.head文件）的工作原理，特别是3.0.2.5版本中的优化，包括BRIN索引和缓存策略的改进，以提高查询性能。优化包括将常用表索引数据缓存在内存中，减少对.head文件的读取，尤其在高并发查询场景下效果显著。文章强调了参数如maxRows、minRows和duration对性能的影响，并鼓励用户根据需求调整参数或寻求专业支持。

摘要由CSDN通过智能技术生成

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 的稳定版，因此版本号越大各方面都是越好的，建议大家可以尽快更新至最新版本。

想了解更多TDengine Database的具体细节，欢迎大家在GitHub上查看相关源代码。