小?T?導讀：在《這幾個神秘參數，教你TDengine集群的正確使用方式》這篇文章中，我們講到了如何利用合理的配置vnode完成TDengine Database的數據分片，本期我們來繼續(xù)講講TDengine如何從時間維度去對數據進行管理。

首先，先看看官網的相關描述：

“TDengine除vnode分片之外，還對時序數據按照時間段進行分區(qū)。每個數據文件只包含一個時間段的時序數據，時間段的長度由DB的配置參數days決定。這種按時間段分區(qū)的方法還便于高效實現數據的保留策略，只要數據文件超過規(guī)定的天數（系統配置參數keep)，將被自動刪除。而且不同的時間段可以存放于不同的路徑和存儲介質，以便于大數據的冷熱管理，實現多級存儲。”

可以看出，時序數據的保留策略是由keep和days這兩個參數牢牢把控的。但是，如果我們想更加深入地理解TDengine時序數據的存儲邏輯，從而優(yōu)化性能的話，只知道上面這些是不夠的。

官方文檔關于keep和days的描述是這樣的：

keep：數據庫中數據保留的天數，單位為天，默認值：3650

days：一個數據文件存儲數據的時間跨度，單位為天，默認值：10

TDengine通過keep和days嚴格控制插入數據的時間戳范圍：對于過去的數據，不可以超出當前時間減去keep的時間戳值；對于未來的數據，不可以超出當前時間加上days的時間戳值。

我們假設某數據庫的keep參數為7，days參數為3，當前時間為某月9日的0點0分。

由于keep為7，所以2日（9-7）之前的數據一定是不可以寫入的。再加上限制未來時間數據的插入，12日（9+3）之后的數據也是不可以插入的。通過這樣的方式，就有了TDengine當前可處理數據的時間范圍time range（彩色范圍），當你試圖寫入位于灰色時間區(qū)域的數據時——就會看到“timestamp out of time range”的提示了。

這組圖代表了隨著當前時間軸的移動，數據文件的分布情況和可寫入數據范圍的變化。

隨著時間的推移，數據的時間戳會與系統時間做計算，一旦超過keep天數，就會被識別為過期數據，等到這個數據文件內的所有數據都過期后，這個數據文件才會被從計算機上清除。

以上述組圖為例，由于2日和4日的數據是在同一個數據文件（Data File 1）中，4日的數據最多可以保留到11日結束，所以2日的數據同樣也要保留到11日結束。所以我們可以看到，12日的時候，Data File 1已經被刪除掉了。

細心的讀者可能會問，假如我寫入3日的數據，我是如何知道這個數據會落在345這個區(qū)間，還是123，或是234呢。其實是這樣——TDengine是從1970年1月1日0時0分0秒起（EpochTime）開始，每3天劃一個分區(qū)。因此，對任何一個時間戳都是“劃到哪一片就算到哪一片”。

由于上述的機制刪除粒度較粗，所以為了優(yōu)化用戶的體驗，在2.1.5.0版本后，我們通過默認設置SQL查詢的where timestamp的起始時間大于過期時間來實現用戶側完全可控的“過期數據刪除”。所以，現在凡是過期的數據對用戶都是不可見的。

雖然在物理層面上，數據仍然是以數據文件為單位刪除的。但是除了對存儲空間有極其精細要求的用戶，絕大多數用戶都是沒有感知的。本次優(yōu)化過后，用戶不再需要為刪除粒度的粗細而產生顧慮。只要安心根據自己的業(yè)務類型，靈活設置days參數的大小以找到性能最優(yōu)的狀況就好了。

此外，由于給定了可寫入數據的時間范圍（now-keep到now+days），給定了數據切分的時間范圍（days），所以只要vnode目錄下面的數據文件組數量小于等于keep/days向上取余+1，就可以認為自動刪除機制是在正常工作的。

以上就是官方文檔上所說的：“給定days與keep兩個參數，一個vnode總的數據文件數目最多為：keep/days+2”的含義。

從概念上來說，“TDengine是通過vnode以及時間兩個維度，對大數據進行切分，便于并行高效的管理，實現水平擴展?！钡侨绾巫尶菰锏母拍钅苻D化成自己正確的理解，還是需要學習的。《這幾個神秘參數，教你TDengine集群的正確使用方式》與本文正是分別從這兩個維度切入TDengine原理的，可以說是比較核心的知識點了。

對于TDengine Database，我們希望大家可以知其然，也知其所以然。