許多用戶會有一個疑問，“落盤”倆字聽起來就很底層，似乎無法和手頭的性能問題聯(lián)系到一起，本篇文章的目的就是讓大家對它們倆建立起直觀的認識。

寫到數(shù)據(jù)庫的數(shù)據(jù)總要保存起來——所以時序數(shù)據(jù)庫（Time Series Database） TDengine 中經常提到的“落盤”，其實指的是內存中的數(shù)據(jù)持久化到存儲的過程。在 TDengine 中，對 vnode 的寫入流程如下。（不了解vnode的用戶，建議先移步?https://docs.taosdata.com/tdinternal/arch/）

根據(jù)圖中所示：內存和硬盤發(fā)生持久化的操作有兩部分，本文的“落盤”指的是右側標紅部分，即是時序數(shù)據(jù)持久化到 $DataDir/vnode/vnodeX/tsdb/ 下數(shù)據(jù)文件的過程。

一 . 觸發(fā)邏輯變化：

熟悉 2.0 版本的朋友們都知道，觸發(fā)落盤的機制有二：

1. 寫滿該 vnode 三分之一的緩沖池（建庫時指定，2.0 為建庫參數(shù) cache * blocks 的值， 3.0 替換為建庫參數(shù) buffer）；
2. 數(shù)據(jù)庫服務進程停止的時候；

在 3.0 版本，觸發(fā)落盤的機制變?yōu)椋?/p>

1. 寫滿該 vnode 三分之一的緩沖池之后，超過“落盤最小間隔”即可自動落盤。出于安全考慮，該參數(shù)沒有提供可配置選項；
2. 數(shù)據(jù)庫服務進程停止的時候；(3.0.4.0 版本數(shù)據(jù)庫單副本情況下提供)
3. 提供手動落盤的命令，flush database dbname。

二.架構優(yōu)化：

那么它具體都達成了哪些優(yōu)化呢？

首先，在設計上 3.0 對落盤功能和過期數(shù)據(jù)檢測做了解耦。

在 2.0 的時候，只有數(shù)據(jù)庫在落盤之后，才會觸發(fā)比對數(shù)據(jù)文件的時間范圍清理過期的文件數(shù)據(jù)的機制，從而釋放硬盤空間，詳情可參考：《五分鐘掌握TDengine時序數(shù)據(jù)的保留策略》。

自 3.0 版本開始，數(shù)據(jù)庫的過期文件清理依靠 trim database dbname 的命令來完成。到 3.0.3.0 版本，又增加了定時檢測來自動執(zhí)行 trim database。這讓 3.0 的磁盤空間回收變得更加高效及時。

其次，提供手動落盤的命令。令落盤控制更加靈活。此外，由于時序數(shù)據(jù)的壓縮是發(fā)生在落盤階段的，因此對于我們統(tǒng)計數(shù)據(jù)的磁盤實際占用，計算壓縮率都有很大的幫助。

三.配置優(yōu)化：

1. 落盤時，內存中的行式存儲的時序數(shù)據(jù)會被轉為列式存儲的數(shù)據(jù)塊，然后執(zhí)行壓縮。因此，形成數(shù)據(jù)塊的過程直接影響著后續(xù)的磁盤占用和查詢效率，這也是 TDengine 性能優(yōu)化最核心的部分之一，它是由數(shù)據(jù)庫的一系列參數(shù)決定的，具體可參考文章《關于 3.0 和 2.0 的數(shù)據(jù)文件差異以及性能優(yōu)化思路》。

2. TDengine 執(zhí)行落盤的任務是異步的，這樣當寫滿 1 塊緩沖池后，就可以無延遲地利用起來剩余的 2 塊緩沖池。但是如果 buffer 設置太小，就會導致落盤仍未結束時，但是已經用光了所有三塊緩沖池。這個時候數(shù)據(jù)庫就只能進入等待階段，寫入查詢都會受到影響，直到可用的緩沖池返回。

可以看出，在這個環(huán)節(jié)中，緩沖池的大小是十分重要的，這個值由建庫時的 buffer 參數(shù)指定，建庫后可修改（具體可參考：https://docs.taosdata.com/taos-sql/database/）。

3. 另外，如果是落盤線程這一側到達瓶頸導致沒有可用的緩沖池返回，則可以選擇增加 numOfCommitThreads 參數(shù)值，這個參數(shù)代表每個節(jié)點上的落盤線程數(shù)量，默認等于二分之一的cpu核數(shù)。

具體優(yōu)化方式需要結合自己的實際情況決定，如寫入頻率、表寬、性能需求等等。并沒有一項固定參數(shù)的單獨調試就可以調試到最優(yōu)狀態(tài)，大家可以結合歷史多期文章自行調試，也可以直接聯(lián)系企業(yè)版團隊做定制化的優(yōu)化方案。