TDengine 写入性能优化最佳实践

高性能时序数据库TDengine

已于 2024-09-04 22:20:09 修改

阅读量908

点赞数 6

分类专栏：大数据文章标签： c语言时序数据库数据库性能优化 linux

于 2024-09-03 13:55:25 首次发布

本文链接：https://blog.csdn.net/ticktick999/article/details/141859568

版权

大数据专栏收录该内容

3 篇文章 0 订阅

订阅专栏

一、背景说明

TDengine 产品性能在调优前和调优后会产生十倍甚至几十倍的性能差距，做好 TDegnine 性能调优是一件非常重要且很有价值的事情

二、影响性能因素

以下列出了影响 TDengine 写入性能的全因素树：

三、调优整体思路

性能调优是一项复杂的系统工程，需根据不同硬件及软件环境条件，依据掌握知识及经验，恰当调整影响性能的各个参数，使其达到一个最佳性能状态

以下是我个人总结出的调优思路，分享给大家

基本思路性能调优三步走：先撸大肉、再吃小肉、最后剔碎肉

抓一条主线：加压力 -> 找瓶颈

四、三步走抓主线思路

思路核心是优先使用效果最好方法进行实践，快速提升写入速度至一个相对好的状态下，再通过其它参数微调使其达到最佳

第一步撸大肉手段

提速三架马车 + 一种选择：并发数，VGROUP 和批大小和一种写入模式的选择

这三参数任何一个配置有问题，都会出现严重性能问题

下面介绍这三个重要参数配置不足的现象及如何配置达到最优

1. 并发数

并发数是指客户端写入线程数量及写入客户端进程数量

现象识别：

当并发数过少时，现象是服务器及客户端 CPU 都非常低，网络流量不高，IO 压力不大，整体上处于资源闲置状态，此现象即是典型写入并发少，压力不足现象，是非常容易识别的

调优策略：

可按当前写入线程数 * 2 调大写入并发数，如果并发数短缺较严重，线程数翻倍可收获写入速度翻倍的效果

并发写入线程数量调优参考标准：

1）VGROUPS 数量远少于 CPU 核数情况，建议写入线程数可为 VGROUPS 数量 2 ~ 5 倍

2）VGROUPS 数量于 CPU 核数相当情况，建议写入线程数可为 VGROUPS 数量 0.7 ~ 1.3 倍

3）VGROUPS 数量远大于 CPU 核数情况，，建议写入线程数可为 VGROUPS 数量 0.2 ~ 0.6 倍

调整过度现象：

1）写入性能开始下降

2）客户端 CPU 超高，服务器端 CPU 上不去

3）网络IO 及磁盘 IO 都在下降

调整过度后线程之间会相互抢占资源，增加的能力被内耗吃掉了

2. VGROUPS

VGROUPS 是 TDegnine 数据库中数据分片技术，通过数据分片是提升数据库并发访问能力的重要技术手段

现象识别：

我们常见的是 VGROUPS 分配不足情况，很多企业使用 TDengine 在刚建库时分配了估算还算大的 VGROUP 数量, 后来随着业务越来越多，子表不断膨胀，一个 VGROUP上便被承载了上百万仍至千万子表的情况，由于性能急剧下降，出现了 TDengine 越用越慢的情况

典型现象 MNode 所在节点 CPU 非常高，其它节点 CPU 很低，说明管理节点已成为瓶颈，正常情况下管理节点很难会成为瓶颈点

调优策略：

建议一个 VNODE 上子表数控制在 100W 内，子表数过大时，存储子表的 B+ 树缺陷被放大，性能会急剧衰减，如果资源足够，控制在 10W 内性能可达到最佳。

若数据库已创建好，可通过运维命令 split vgroup 对一个 vgroups 上子表进行多次连续拆分

调整过度现象：

数据库 VGROUPS 分配过多时，每个 VGROUPS 都有自己一套文件组，落盘相同数据时要写入的文件数量就会膨胀，在 IO 固定情况下，便会出现相互排除等待磁盘资源的内耗现象，性能反而会下降

3. 批大小

每次批量向服务器提交数据量大小对写入性能影响很大，提交频繁但数据量小，会严重增加网络请求负担及服务器处理请求的负担

现象识别：

客户端与服务器的 CPU 都不低，但服务器 IO 上不去，写入速度上不去

调优策略：

单次写入数据量, 一般来讲，每批次写入的数据量越大越高效（但超过一定阈值其优势会衰减）。

使用 SQL 写入 TDengine 时，尽量在一条 SQL 中拼接更多数据，目前 TDengine 支持一条 SQL 最大长度为 1 MB，如果机器性能不差情况下，满格写入可获得不错的写入速度

4.写入模式

写入模式的选择对写入速度影响非常大，不同写入模式之间写入速度差别也很大，但写入模式与用户使用环境等制约因素密切相关，大部分情况下做不到哪个快选哪个

在写入模式性能上，一般为： Native > WebSocket > Restful

在写入接口上，一般为： STMT 快速写入 > SQL 方式 > schemaless 模式

大家记住这样的速度优先顺序即可，再根据自己业务环境可供选择的模式及接口去选择最适合的

通过以上指标调整，约大部分环境可让写入速度进入一个不错的范围内

第二步吃小肉

这些参数一般情况下使用默认值不会出现太大问题，但在特定写入场景下这些地方可能会成为瓶颈，及时调整后也会给性能带来不少提升

1. Vgroups 绑定写入

当写入一批数据中包括的子表来自不同的 VGroups 的时候，TDengine 引擎需要把这些子表按 VGroups 进行分组归类，然后再向各自的 VGROUP 发送写入请求。这样提交次数会变多，每次提交内容即会变少，效率就会降下来了

现象识别：

通过写入行为识别，一批写入中包括多个子表，且子表来自不同的 VGROUPS

调优策略：

把写入子表按 VGroups 进行分组，每组使用一个单独线程完成写入，调整后性能可提升 20% ~40%

2. 调整缓存 last 模式

设备产生的最后一条数据是工业监控领域使用最频繁的一个数值，TDengine 引擎使用了l缓存 last 值技术，在每台设备数据到达时实时写入 last 缓存以便查询可快速使用，这个实时更新缓存的过程会对写入性能产生一定影响

现象识别：

缓存 last 默认是关闭的，首先要确认此选项是否已打开，可通过系统表查询数据库是否打开了 cachemodel 开关，若已打开，那再确定是否此数据库中的表列数特别多或列的宽度都很大这样的特征，如果满足任意一个条件，那写入速度可能就是受到了这个 cachemodel 选项的严重影响了

调优策略：

通过 atler database dbname cachemodeal 'none' 关闭选项，再查看写入速度，可快速验证影响程度。如果要兼顾查询 last 性能，可通过把原来选项是 'both' 的调整为 ‘last_row’ 或 ‘last_value’ 来减轻影响，具体可参考官网文档介绍

3. stt_trigger

多表低频是指根据数据库的配置，一个 vnode 中单次数据落盘的单表数据条数普遍小于 minRows 时，可视为多表低频场景。stt_trigger 是解决多表低频场景引入的一个参数和一套机制，stt_trigger 等于 1 时，数据是从buffer 直接落到最终的 data 文件中，零散的写入 last 中，当 stt_trigger 大于 1 时，原来的直接落盘被分成两步来完成，第一步数据先写到 stt 文件中，第二步再从 stt 中写入到 data 文件完成最终落盘。stt_trigger 大于 1 的情况下 IO 是翻倍的，所以如果不是多表低频场景，还是配置为 stt_trigger = 1 性能更好

现象识别：

通过查询写入结果可识别，先查询子表数超过百分或有上千万，再查询最近1小时各子表写入数据条数及时间间隔，如果条数非常少间隔很大，就是典型的多表低频

同时可观察现象，服务器 IO 不高，CPU 不高，写入速度慢，stt 文件体积巨大

调优策略：

根据多表低频的严重程度调整 stt_trigger 的大小，越严重值调越大。一般情况下调整到 8 以下就足够了，最大值为 16。

调整过度现象：

stt_trigger 调整过大，会导致大量 IO 消耗，同时会生成更多碎小的 STT 文件，在这些碎小的 STT 文件合并时会消耗大量 IO ，不建议调整过大

4. Buffer 大小

此参数是分配给 VNODE 用于写入数据缓存的，客户端提交写入数据请求，数据写入至此缓存后便会返回客户端数据写入成功，客户端收到写入成功的返回

虽然客户端收到写入成功返回，实际数据还在写入缓存 Buffer中，未真正落至时序数据 DATA 文件中，还需要后续 vnode-commit 线程从缓存中取出来写入最终 DATA 文件中算最终完成

所以 Buffer 大小决定了能保存未落盘数据的大小，BUFFER 过小时会被瞬间写满，后面写入请求只能排队等待 vnode-commit 线程把 Buffer 的内容写到磁盘中，才能腾出 Buffer 供后面排队的写入请求完成写入落盘缓存中返回给客户端

现象识别：

客户端在瞬间高流量写入一段时间后，写入延时 P99 中发现有非常夸张的大延时，大概率是缓存过小原因，尖峰写入瞬间打满缓存，导致后面写入请求出现高延时的典型现象，大缓存可缓解这种现象出现。

调优策略：

根据自己机器内存配置情况配置一个恰当的值，默认是 256M, 内存充足可适当调整到 512M 或 1024M

调整过度现象：

此参数不宜调整过大，假设配置到 9G ，那按缓存满 2/3后落盘的规则，9 * 2/3 = 6G, 一次落盘需要把 6G 数据写入磁盘，磁盘 IO 压力会非常大，而没有触发落盘时 IO 却未被使用，人为加大落盘 IO 洪峰值。

5.numOfCommitThread

numOfCommitThread 表示落盘线程 vnode-commit 数量，这组线程负责数据最终落盘至 data文件中的任务，此参数同时可控制另一组 vnode-merge 线程数量, 这两线程组共用同一参数。vnode-merge 线程组负责合并所有 stt 文件，合并后对于满足不小于minirows 且不大于 maxrows 的数据块，会交给 vnode-commit 线程永久写入磁盘保存起来

现象识别：

使用 top H -p taosd-pid 查看 taosd 进程中线程执行情况，如果发现标识为 vnode-merge 或 vnode-commit 的线程 CPU 占用长时间居高不下时，表明这两环节资源非常吃紧，成为了瓶颈，需扩大

调优策略：

保证这两线程的 CPU 占用保持在 50% 以下，尖峰值不超过 80%，是一个比较理想的状态，如果管理员为解决 IO 瓶颈在一级上增加多块硬盘挂载，要适当调大此参数来配合增加的磁盘。

第三步剔碎肉

以下涉及的方法及参数，虽没有上面参数调整带来较大的效果，但也能给写入性能带来一些意外的收获

1. Minrows Maxrows

这两个参数是控制最终入库数据块大小的参数，在写入过程中，控制入库数据块在一个比较理想大小范围内，能够在一定程度上提升写入效率，同时在后面的查询中也可获取较好查询速度

现象识别：

通过统计指标识别， show table distributed 可以查看已写入的超级表中 BLOCK 行数统计分布，表的列数在 100 列以内的 BLOCK 行数大部分能控制在 3000 行左右是最佳状态，使用 minirows maxrows 默认参数顺序批量写入基本上能够达到这个状态。如果大部分 BLOCK 行数只有100~200 行，这里就需要进行调整。

调优策略：

调整 minrows 和 maxrows 的控制范围，同时要适当结合 stt_trigger 参数进行调整，如调高了 minrows 后，可能很多块会滞留在 stt 文件中，此时如果 stt 文件过大，也会给写入性能带来一定影响，可以适当调大 stt_trigger 来缓存这个影响