TDengine 3.0 雖(sui)然對底(di)層做了大(da)規模的優化重構，但是相(xiang)對于數據(ju)文(wen)件的工作(zuo)邏輯和(he) 2.0 相(xiang)比是整體保持(chi)不變的。本系列(lie)文(wen)章的主(zhu)旨(zhi)在于幫助(zhu)用戶深入理解產品，并(bing)且擁有基本的性能調試(shi)思路，從而獲得更好的產品體驗。

本期文章會在講解 TDengine 時序數據庫 (Time Series DataBase)的(de)(de)索引文(wen)(wen)件(jian)（.head 文(wen)(wen)件(jian)）工(gong)作原理的(de)(de)同時，介紹索引文(wen)(wen)件(jian)在最新的(de)(de) TDengine 3.0.2.5 中的(de)(de)優化。而在下一期的(de)(de)文(wen)(wen)章中，會(hui)對兩大版本數據文(wen)(wen)件(jian)的(de)(de)差(cha)異做一個總(zong)結(jie)式(shi)的(de)(de)說(shuo)明(ming)。

如下是 TDengine 的數據文件的結(jie)構(gou)——也就(jiu)是這個四位一體(ti)的文件組。

在此前的(de)文章，主(zhu)要講述(shu)的(de)是 .data 和(he) .last（3.0 中已(yi)經更(geng)名(ming)為 .stt 文件(jian)）文件(jian)的(de)工作原(yuan)理。詳情可(ke)見(jian)：

接下來，我們將(jiang)和大家一起以產品使(shi)用者的視角繼續向前(qian)探索(suo)，揭開.head 文件的原(yuan)理。

.head 類文件存儲了 .data 文件中的數據塊的索引信息。在.data文件中的每個數據塊的 BRIN 索引信息在 .head 類文件中以表為分組，按照時間順序遞增，形成索引塊組。（注：硬盤上的數據用的是 BRIN 索引，在落盤之前的內存數據用的是 skiplist 索引。）在查詢的時候，會先加載這個 .head 文件中的索引信息，從而找到 .data 文件中的時序數據返回給用戶。

（注：BRIN 索引指的是 Block Range Index，主要適用(yong)于有著天然順序的數(shu)據集，由于不需要再做排序，所以資源耗費(fei)少，十分契合(he)時(shi)序數(shu)據的查(cha)詢，也是 TDengine 和關系型數(shu)據庫的核心區別之一。）

一個清晰可見(jian)的(de)邏輯是(shi)——索引的(de)作(zuo)用(yong)是(shi)幫助我(wo)們(men)快(kuai)速(su)定位(wei)數(shu)據的(de)位(wei)置，但當(dang)你操作(zuo)索引的(de)時間變(bian)得特別(bie)長的(de)時候(hou)(hou)，索引的(de)價值(zhi)無形之中就會變(bian)低了。所(suo)以，在 .head 文件較(jiao)大的(de)時候(hou)(hou)就可能(neng)會出現影響查詢性能(neng)的(de)瓶頸。

而影(ying)響 .head 文件大小的因素(su)有(you)兩個：

• 一是 maxrows 和 minrows 這兩個參數。很好理解，同樣1000行數據，maxrows=200需要 5 個數據塊，maxrows為 1000，只需要 1 塊。每個數據塊都需要一條索引信息存儲在 .head 文件中。（詳情可參考：）
  
• 另一個會讓 .head 文件非常大的參數是 duration （ 即 2.0 中的 days）。我們知道 duration 是控制單個數據文件存儲數據天數的參數 ( 詳情可參考：)。所以假如 duration 很大的話，單個數據文件存儲的數據量就一定也很大，數據塊就會很多。

以(yi)(yi)上(shang)的(de)理(li)論場(chang)景是(shi)(shi)真實(shi)發(fa)生過的(de)——之前我們(men)在支(zhi)持某企業(ye)用(yong)戶的(de)時(shi)候，就曾遇到(dao)過生產環(huan)境(jing)上(shang) duration 參數(shu)設置(zhi)為(wei) 1000 多天導(dao)致數(shu)據查(cha)詢性能(neng)嚴重下降的(de)情況。但(dan)是(shi)(shi)由于 duration 參數(shu)建庫后(hou)不能(neng)修(xiu)改(gai)，所以(yi)(yi)最后(hou)只能(neng)導(dao)出數(shu)據，重新(xin)建庫修(xiu)改(gai)為(wei)合理(li)的(de) duration 后(hou)再(zai)導(dao)回，這樣(yang)問題才得以(yi)(yi)解決。（所以(yi)(yi)，默認(ren)值(zhi)取(qu) duration 為(wei) 10 就是(shi)(shi)一(yi)(yi)個(ge)折中的(de)選擇，實(shi)際使用(yong)時(shi)可以(yi)(yi)根據查(cha)詢類型和機器性能(neng)靈活調試。）另(ling)外一(yi)(yi)個(ge)用(yong)戶則是(shi)(shi)查(cha)詢時(shi)間跨(kua)度大，查(cha)詢并發(fa)量大 ，導(dao)致大量的(de)服務器資(zi)源被用(yong)于讀取(qu) .head 文(wen)件影響了查(cha)詢性能(neng)。

如果說前者還(huan)屬(shu)于參數使(shi)用不(bu)當(dang)的話(hua)，第二(er)個場(chang)景的查詢(xun)并發量則(ze)是由用戶的業務場(chang)景所決定的，因此我(wo)們針對(dui)后者的潛在瓶頸，在最(zui)新的 TDengine 3.0.2.5 中，針對(dui) .head 文件(jian)做了一(yi)項重磅的優化——對(dui)于常(chang)用的表(biao)索引數據(ju)，會被放在緩存中（LRU 算法）。

這(zhe)樣一來，即便是不同的查(cha)詢任務，只(zhi)要(yao)所(suo)查(cha)詢的表索引還在池子(zi)中緩(huan)存著，便不需(xu)要(yao)重復地讀(du)取 .head 文(wen)件了。由(you)于涉及已落盤數據的查(cha)詢基本都(dou)需(xu)要(yao)去首先訪問(wen) .head 文(wen)件，因此，該優(you)化使得整體查(cha)詢性(xing)能都(dou)得到(dao)了提(ti)升，而在特定場景下（如高(gao)并(bing)發）形成了較大幅度的突破(po)。

結語

結合之前的(de)幾篇文章(zhang)可以看到：keep，duration，maxRows，minRows 這(zhe)些參數(shu)息息相關，牽一發而動全身，是(shi)不可以隨便(bian)改動的(de)，它們的(de)數(shu)值不論過大還是(shi)過小都會(hui)引起使(shi)用問題(ti)。如(ru)果因(yin)為孤立地看待(dai)某個參數(shu)而帶來了問題(ti)，用戶可能(neng)會(hui)誤(wu)以為這(zhe)是(shi)產品本身的(de)問題(ti)。因(yin)此，很(hen)(hen)多時(shi)候(hou)默認配(pei)置也是(shi)“很(hen)(hen)香”的(de)。

而對于性能要求較高的用戶，也可以通過熟讀文檔、代碼、技術文章、視頻等資料來調整參數以達到最佳性能，也歡迎聯系 TDengine時序數據庫(TSDB) 官方(fang)咨詢企(qi)業(ye)版，以獲得全方(fang)位的技術支持。

在最新發布的 3.0.2.5 上，我們(men)還做(zuo)了(le)很多其(qi)他(ta)優(you)化，穩定性(xing)和性(xing)能進一步提升。由于 3.0.2.x 是當前 3.0 的穩定版(ban)，因此(ci)版(ban)本(ben)號越(yue)(yue)大(da)各方(fang)面都(dou)是越(yue)(yue)好的，建議(yi)大(da)家(jia)可以(yi)盡快更新至最新版(ban)本(ben)。