共计 1495 个字符，预计需要花费 4 分钟才能阅读完成。
许多用户会有一个疑难，“落盘”俩字听起来就很底层，仿佛无奈和手头的性能问题分割到一起，本篇文章的目标就是让大家对它们俩建设起直观的意识。
写到数据库的数据总要保存起来——所以时序数据库（Time Series Database）TDengine 中常常提到的“落盘”，其实指的是内存中的数据长久化到存储的过程。在 TDengine 中，对 vnode 的写入流程如下。（不理解 vnode 的用户，倡议先移步 https://docs.taosdata.com/tdinternal/arch/）
依据图中所示：内存和硬盘产生长久化的操作有两局部，本文的“落盘”指的是右侧标红局部，即是时序数据长久化到 $DataDir/vnode/vnodeX/tsdb/ 下数据文件的过程。
一 . 触发逻辑变动：
相熟 2.0 版本的敌人们都晓得，触发落盘的机制有二：
- 写满该 vnode 三分之一的缓冲池（建库时指定，2.0 为建库参数 cache * blocks 的值，3.0 替换为建库参数 buffer）；
- 数据库服务过程进行的时候；
在 3.0 版本，触发落盘的机制变为：
- 写满该 vnode 三分之一的缓冲池之后，超过“落盘最小距离”即可主动落盘。出于平安思考，该参数没有提供可配置选项；
- 数据库服务过程进行的时候；(3.0.4.0 版本数据库单正本状况下提供)
- 提供手动落盘的命令，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 的磁盘空间回收变得更加高效及时。
其次，提供手动落盘的命令。令落盘管制更加灵便。此外，因为时序数据的压缩是产生在落盘阶段的，因而对于咱们统计数据的磁盘理论占用，计算压缩率都有很大的帮忙。
三. 配置优化：
- 落盘时，内存中的行式存储的时序数据会被转为列式存储的数据块，而后执行压缩。因而，造成数据块的过程间接影响着后续的磁盘占用和查问效率，这也是 TDengine 性能优化最外围的局部之一，它是由数据库的一系列参数决定的，具体可参考文章（文章：对于 3.0 和 2.0 的数据文件差别以及性能优化思路）。
- TDengine 执行落盘的工作是异步的，这样当写满 1 块缓冲池后，就能够无提早地利用起来残余的 2 块缓冲池。然而如果 buffer 设置太小，就会导致落盘仍未完结时，然而曾经用光了所有三块缓冲池。这个时候数据库就只能进入期待阶段，写入查问都会受到影响，直到可用的缓冲池返回。
能够看出，在这个环节中，缓冲池的大小是非常重要的，这个值由建库时的 buffer 参数指定，建库后可批改（具体可参考：https://docs.taosdata.com/taos-sql/database/）。 - 另外，如果是落盘线程这一侧达到瓶颈导致没有可用的缓冲池返回，则能够抉择减少 numOfCommitThreads 参数值，这个参数代表每个节点上的落盘线程数量，默认等于二分之一的 cpu 核数。
具体优化形式须要联合本人的理论状况决定，如写入频率、表宽、性能需求等等。并没有一项固定参数的独自调试就能够调试到最优状态，大家能够联合历史多期文章自行调试，也能够间接分割企业版团队做定制化的优化计划。