[TDengine]( https://www.taosdata.com/"TDengine") 3.0 雖然對底層做了大規模的最佳化重構，但是相對於資料檔案的工作邏輯和 2.0 相比是整體保持不變的。本系列文章的主旨在於幫助使用者深入理解產品，並且擁有基本的效能除錯思路，從而獲得更好的產品體驗。

本期文章會在講解 TDengine [時序資料庫]( https://www.taosdata.com/"時序資料庫") (Time Series DataBase)的索引檔案（.head 檔案）工作原理的同時，介紹索引檔案在最新的 TDengine 3.0.2.5 中的最佳化。而在下一期的文章中，會對兩大版本資料檔案的差異做一個總結式的說明。

如下是 TDengine 的資料檔案的結構——也就是這個四位一體的檔案組。

![](http://img.blog.itpub.net/blog/2023/02/14/cce9b07505dfcad8.png?x-oss-process=style/bb)

在此前的文章，主要講述的是 .data 和 .last（3.0 中已經更名為 .stt 檔案）檔案的工作原理。詳情可見：https://mp.weixin.qq.com/s/OGS1WIlySSKveEOk4Reg3Q

接下來，我們將和大家一起以產品使用者的視角繼續向前探索，揭開.head 檔案的原理。

.head 類檔案儲存了 .data 檔案中的資料塊的索引資訊。在.data檔案中的每個資料塊的 BRIN 索引資訊在 .head 類檔案中以表為分組，按照時間順序遞增，形成索引塊組。（注：硬碟上的資料用的是 BRIN 索引，在落盤之前的記憶體資料用的是 skiplist 索引。）在查詢的時候，會先載入這個 .head 檔案中的索引資訊，從而找到 .data 檔案中的時序資料返回給使用者。

（注：BRIN 索引指的是 Block Range Index，主要適用於有著天然順序的資料集，由於不需要再做排序，所以資源耗費少，十分契合時序資料的查詢，也是 TDengine 和關係型資料庫的核心區別之一。）

一個清晰可見的邏輯是——索引的作用是幫助我們快速定位資料的位置，但當你操作索引的時間變得特別長的時候，索引的價值無形之中就會變低了。所以，在 .head 檔案較大的時候就可能會出現影響查詢效能的瓶頸。

而影響 .head 檔案大小的因素有兩個：

- 一是 maxrows 和 minrows 這兩個引數。很好理解，同樣1000行資料，maxrows=200需要 5 個資料塊，maxrows為 1000，只需要 1 塊。每個資料塊都需要一條索引資訊儲存在 .head 檔案中。（詳情可參考：https://mp.weixin.qq.com/s/OGS1WIlySSKveEOk4Reg3Q）
- 另一個會讓 .head 檔案非常大的引數是 duration （ 即 2.0 中的 days）。我們知道 duration 是控制單個資料檔案儲存資料天數的引數 ( 詳情可參考：https://mp.weixin.qq.com/s/uJEQwN0NnmSTBAMOecAtoA)。所以假如 duration 很大的話，單個資料檔案儲存的資料量就一定也很大，資料塊就會很多。

以上的理論場景是真實發生過的——之前我們在支援某企業使用者的時候，就曾遇到過生產環境上 duration 引數設定為 1000 多天導致資料查詢效能嚴重下降的情況。但是由於 duration 引數建庫後不能修改，所以最後只能匯出資料，重新建庫修改為合理的 duration 後再導回，這樣問題才得以解決。（所以，預設值取 duration 為 10 就是一個折中的選擇，實際使用時可以根據查詢型別和機器效能靈活除錯。）另外一個使用者則是查詢時間跨度大，查詢併發量大 ，導致大量的伺服器資源被用於讀取 .head 檔案影響了查詢效能。

如果說前者還屬於引數使用不當的話，第二個場景的查詢併發量則是由使用者的業務場景所決定的，因此我們針對後者的潛在瓶頸，在最新的 TDengine 3.0.2.5 中，針對 .head 檔案做了一項重磅的最佳化——對於常用的表索引資料，會被放在快取中（LRU 演演算法）。

這樣一來，即便是不同的查詢任務，只要所查詢的表索引還在池子中快取著，便不需要重複地讀取 .head 檔案了。由於涉及已落盤資料的查詢基本都需要去首先訪問 .head 檔案，因此，該最佳化使得整體查詢效能都得到了提升，而在特定場景下（如高併發）形成了較大幅度的突破。

**結語**

結合之前的幾篇文章可以看到：keep，duration，maxRows，minRows 這些引數息息相關，牽一髮而動全身，是不可以隨便改動的，它們的數值不論過大還是過小都會引起使用問題。如果因為孤立地看待某個引數而帶來了問題，使用者可能會誤以為這是產品本身的問題。因此，很多時候預設配置也是“很香”的。

而對於效能要求較高的使用者，也可以透過熟讀檔案、程式碼、技術文章、影片等資料來調整引數以達到最佳效能，也歡迎聯絡 TDengine時序資料庫([TSDB]( https://www.taosdata.com/tsdb"TSDB")) 官方諮詢企業版，以獲得全方位的技術支援。

在最新發布的 3.0.2.5 上，我們還做了很多其他最佳化，穩定性和效能進一步提升。由於 3.0.2.x 是當前 3.0 的穩定版，因此版本號越大各方面都是越好的，建議大家可以儘快更新至最新版本。

------------

想了解更多 [TDengine Database]( https://www.taosdata.com/?zh"TDengine Database")的具體細節，歡迎大家在[GitHub]( https://github.com/taosdata/TDengine"GitHub")上檢視相關原始碼。
[![](http://img.blog.itpub.net/blog/2022/05/11/0fd59db1207fc97f.jpeg?x-oss-process=style/bb)](https://www.taosdata.com/?zh "![](http://img.blog.itpub.net/blog/2022/05/11/0fd59db1207fc97f.jpeg?x-oss-process=style/bb)")

TDengine 3.0.2.5 查詢再最佳化！揭秘索引檔案的工作原理

相關文章