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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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