許多用戶會有一個疑(yi)問，“落盤”倆(lia)字(zi)聽起來就很底層(ceng)，似乎無(wu)法和手頭的(de)性能問題(ti)聯系到一起，本(ben)篇文章的(de)目(mu)的(de)就是讓大(da)家對(dui)它(ta)們倆(lia)建立起直觀的(de)認識。

寫到數據庫的數據總要保存起來——所以時序數據庫（Time Series Database） TDengine 中經常提到的(de)(de)“落(luo)盤”，其(qi)實指(zhi)的(de)(de)是(shi)內(nei)存(cun)(cun)中的(de)(de)數(shu)據持(chi)久(jiu)化到存(cun)(cun)儲的(de)(de)過程。在 TDengine 中，對 vnode 的(de)(de)寫入流程如下。（不了解vnode的(de)(de)用戶(hu)，建(jian)議先(xian)移步?）

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

一 . 觸發邏輯變化：

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

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

在(zai) 3.0 版本，觸發(fa)落盤的機(ji)制變(bian)為：

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

二.架構優化：

那(nei)么(me)它(ta)具體(ti)都(dou)達成了哪些優(you)化呢(ni)？

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

在 2.0 的(de)時候，只(zhi)有(you)數據(ju)庫在落盤之后，才會觸發比對數據(ju)文(wen)件(jian)的(de)時間范圍(wei)清理(li)過期(qi)的(de)文(wen)件(jian)數據(ju)的(de)機制，從而釋放硬(ying)盤空間，詳情可(ke)參考：。

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

其次，提供手動(dong)落(luo)盤(pan)的(de)(de)命令(ling)。令(ling)落(luo)盤(pan)控制(zhi)更(geng)加靈活。此(ci)外(wai)，由于時序數(shu)據的(de)(de)壓縮(suo)是發生在落(luo)盤(pan)階段的(de)(de)，因此(ci)對于我(wo)們統計數(shu)據的(de)(de)磁盤(pan)實際占用，計算(suan)壓縮(suo)率都有(you)很大的(de)(de)幫助。

三.配置優化：

1. 落盤時，內存中的行式存儲的時序數據會被轉為列式存儲的數據塊，然后執行壓縮。因此，形成數據塊的過程直接影響著后續的磁盤占用和查詢效率，這也是 TDengine 性能優化最核心的部分之一，它(ta)是由數(shu)據庫(ku)的一系列參數(shu)決定的，具體可參考文章。

2. TDengine 執行落盤(pan)的(de)任務是異步的(de)，這樣當(dang)寫滿 1 塊緩(huan)(huan)沖(chong)(chong)池后(hou)，就可以無(wu)延遲地利用起來剩余的(de) 2 塊緩(huan)(huan)沖(chong)(chong)池。但(dan)是如(ru)果 buffer 設置(zhi)太小(xiao)，就會導(dao)致落盤(pan)仍(reng)未結束時，但(dan)是已經用光了所有三塊緩(huan)(huan)沖(chong)(chong)池。這個時候數據庫(ku)就只能(neng)進(jin)入等(deng)待階(jie)段，寫入查(cha)詢都會受到影響，直到可用的(de)緩(huan)(huan)沖(chong)(chong)池返回。

可(ke)以(yi)看出，在這(zhe)個環節中，緩沖池的大小(xiao)是十分(fen)重要的，這(zhe)個值(zhi)由建(jian)庫(ku)時的 buffer 參數指定(ding)，建(jian)庫(ku)后可(ke)修改（具體可(ke)參考：）。

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

具體(ti)優化(hua)方式需(xu)要結合(he)自己的(de)實(shi)際情(qing)況(kuang)決定，如寫(xie)入(ru)頻率、表(biao)寬、性能需(xu)求等等。并沒有(you)一項固(gu)定參數的(de)單(dan)獨調試(shi)就可以調試(shi)到最優狀態，大家可以結合(he)歷史多期文章自行調試(shi)，也可以直接聯系企業(ye)版(ban)團隊做定制(zhi)化(hua)的(de)優化(hua)方案(an)。