关于时序数据库:与-TDengine-性能直接相关30-的落盘机制优化及使用原则

35次阅读

共计 1495 个字符,预计需要花费 4 分钟才能阅读完成。

许多用户会有一个疑难,“落盘”俩字听起来就很底层,仿佛无奈和手头的性能问题分割到一起,本篇文章的目标就是让大家对它们俩建设起直观的意识。

写到数据库的数据总要保存起来——所以时序数据库(Time Series Database)TDengine 中常常提到的“落盘”,其实指的是内存中的数据长久化到存储的过程。在 TDengine 中,对 vnode 的写入流程如下。(不理解 vnode 的用户,倡议先移步 https://docs.taosdata.com/tdinternal/arch/)

依据图中所示:内存和硬盘产生长久化的操作有两局部,本文的“落盘”指的是右侧标红局部,即是时序数据长久化到 $DataDir/vnode/vnodeX/tsdb/ 下数据文件的过程。

一 . 触发逻辑变动:

相熟 2.0 版本的敌人们都晓得,触发落盘的机制有二:

  1. 写满该 vnode 三分之一的缓冲池(建库时指定,2.0 为建库参数 cache * blocks 的值,3.0 替换为建库参数 buffer);
  2. 数据库服务过程进行的时候;

在 3.0 版本,触发落盘的机制变为:

  1. 写满该 vnode 三分之一的缓冲池之后,超过“落盘最小距离”即可主动落盘。出于平安思考,该参数没有提供可配置选项;
  2. 数据库服务过程进行的时候;(3.0.4.0 版本数据库单正本状况下提供)
  3. 提供手动落盘的命令,flush database dbname。

二. 架构优化:

那么它具体都达成了哪些优化呢?

首先,在设计上 3.0 对落盘性能和过期数据检测做理解耦。
在 2.0 的时候,只有数据库在落盘之后,才会触发比对数据文件的工夫范畴清理过期的文件数据的机制,从而开释硬盘空间,详情可参考:https://mp.weixin.qq.com/s/uJEQwN0NnmSTBAMOecAtoA。

自 3.0 版本开始,数据库的过期文件清理依附 trim database dbname 的命令来实现。到 3.0.3.0 版本,又减少了定时检测来主动执行 trim database。这让 3.0 的磁盘空间回收变得更加高效及时。

其次,提供手动落盘的命令。令落盘管制更加灵便。此外,因为时序数据的压缩是产生在落盘阶段的,因而对于咱们统计数据的磁盘理论占用,计算压缩率都有很大的帮忙。

三. 配置优化:

  1. 落盘时,内存中的行式存储的时序数据会被转为列式存储的数据块,而后执行压缩。因而,造成数据块的过程间接影响着后续的磁盘占用和查问效率,这也是 TDengine 性能优化最外围的局部之一,它是由数据库的一系列参数决定的,具体可参考文章(文章:对于 3.0 和 2.0 的数据文件差别以及性能优化思路)。
  2. TDengine 执行落盘的工作是异步的,这样当写满 1 块缓冲池后,就能够无提早地利用起来残余的 2 块缓冲池。然而如果 buffer 设置太小,就会导致落盘仍未完结时,然而曾经用光了所有三块缓冲池。这个时候数据库就只能进入期待阶段,写入查问都会受到影响,直到可用的缓冲池返回。
    能够看出,在这个环节中,缓冲池的大小是非常重要的,这个值由建库时的 buffer 参数指定,建库后可批改(具体可参考:https://docs.taosdata.com/taos-sql/database/)。
  3. 另外,如果是落盘线程这一侧达到瓶颈导致没有可用的缓冲池返回,则能够抉择减少 numOfCommitThreads 参数值,这个参数代表每个节点上的落盘线程数量,默认等于二分之一的 cpu 核数。

具体优化形式须要联合本人的理论状况决定,如写入频率、表宽、性能需求等等。并没有一项固定参数的独自调试就能够调试到最优状态,大家能够联合历史多期文章自行调试,也能够间接分割企业版团队做定制化的优化计划。

正文完
 0