> 小 T 導讀： 資料集的高基數（High-Cardinality）問題一直困擾著諸多主流的[時序資料庫]( "https://www.taosdata.com/時序資料庫")（Time Series Database，TSDB）產品。一些資料庫管理系統，在基數較低時表現良好；但是隨著基數的增加，資料庫的表現也會變差，這就給資料庫管理員帶來了很大的挑戰，他們需要透過相關設計降低基數，避免與之相關的問題。

[TDengine]( https://www.taosdata.com/"TDengine") 3.0 是第一個解決了高基數問題的時序資料庫，本文將分享其設計思路。

**何謂高基數問題？**
講到高基數問題，首先，我們要理解什麼是基數（Cardinality）。基數可以定義為一個資料集中值的數量。資料集不同，基數可以很高，也可以很低。比如，如果是布林資料，它的值只能是 true 或 false，則該資料集的基數為 2。但是如果是像裝置 ID 這樣的資料集，其基數就非常大了。

對於[時序資料]( https://www.taosdata.com/"時序資料")，事情就更復雜了。時序資料總會關聯一些後設資料，比如標籤。因此，一個系統的基數就是每個標籤的基數的叉乘。比如，以智慧電錶為例，它會關聯裝置 ID、城市 ID、廠商 ID 和模型 ID 等標籤。幾百個城市，百萬級裝置，再加上不同的廠商、模型，基數輕鬆超過百億級。

高基數有什麼問題呢？這會增加定位一個唯一的值所需要的時間。對於資料庫而言，延遲與基數直接相關。許多時序資料庫，如 InfluxDB、[OpenTSDB]( https://www.taosdata.com/opentsdb"OpenTSDB") 和 Prometheus，都採用了鍵值儲存模型，其中的鍵是由標籤組合唯一識別的。這種模式有個副作用，它會極大增加資料集的基數。

那 TDengine 3.0 是如何解決高基數問題的呢？下面我們一起看一下它的幾個核心設計。

**資料模型：一個資料採集點一張表**
特有的資料模型，是 TDengine 的一大核心設計，即“一個資料採集點一張表”。也就是說，TDengine 建議為資料採集點建立一張單獨的表。一般情況下，一個裝置就是一個資料採集點；但是在更復雜的情況下，一個裝置可能包含多個資料採集點，而且不同的採集點有不同的採集頻率。

在設計上，TDengine 使用一致性雜湊來確定哪個虛擬節點（vnode）負責儲存特點表（table）的資料。在 vnode 內部，系統會構建索引，以提升定位 table 的速度。隨著表數量的增多，TDengine 會建立更多 vnode，儘量減少定位到某個 table 的時間，並支援系統輕鬆伸縮。

這種設計保證了向任何一個表插入資料或從任何一個表查詢資料的延遲，即使表的數量呈指數增長。因此，延遲不受 TDengine 中高基數的影響。

**將後設資料與時序資料分離**
透過“一個資料採集點一張表”的設計，TDengine 可以保證單一表的延遲。但是，現實世界的具體應用往往需要聚合多個表或裝置中的資料。這是 TDengine 在設計上要面對的一個主要挑戰。

為了解決這個問題，TDengine 引入了超級表（supertable）。與標準的資料庫不同，超級表允許應用程式將一組標籤關聯到每個表。TDengine 會將這些標籤與採集到的時序資料分開儲存：使用 B 樹為標籤建立索引，將其儲存到後設資料儲存中；而時序資料儲存在一個單獨的時序資料儲存中。後設資料儲存中的每張表只有一行資料，而且可以根據需要更新。在時序資料儲存中，每個表都有許多行資料，而且資料集 會隨著時間的推移而增長，直到其生命週期結束。

為了聚合多個表的資料，應用程式可以透過標籤來過濾。當執行時，TDengine 首先搜尋後設資料儲存，並獲得滿足過濾條件的表的列表，然後再來獲取儲存在時序資料儲存中的資料塊，並完成聚合過程。

首先掃描後設資料儲存，因為這個資料集比時序資料儲存的規模要小得多，TDengine 就可以提供非常高效的聚合能力。這個過程可以用下圖表示。
![](http://img.blog.itpub.net/blog/2022/12/05/eaa0724203385527.png?x-oss-process=style/bb)

**分散式儲存後設資料**
在 TDengine 2.x 的設計中，表的後設資料，比如模式和標籤，都儲存在管理節點（mnode）上。如果建立的表的數量達到千萬級，這就會成為 TDengine 的一個瓶頸：過濾這麼多標籤的延遲會明顯增加了。

到了 TDengine 3.0，我們會將後設資料儲存分佈在 vnode 中，而不再是集中化儲存在 mnode 上。當一個應用想從多個表聚合資料時，TDengine 會同時向所有的 vnode 傳送過濾條件。然後，每個 vnode 並行工作，找到所要求的表，聚合資料，最後將結果送回查詢節點或驅動，並在那裡執行合併操作。

現在，TDengine 3.0 的分散式設計保證了標籤過濾操作的延遲，只要系統資源充足，mnode 不再是瓶頸。隨著建立的表的增多，TDengine 只需要為其分配更多資源，建立更多 vnode，以確保系統的可擴充套件性。

總的來說，透過創新的設計，TDengine 3.0 很好地解決了高基數問題。歡迎下載試用，為業務創新提速。

歡迎新增小T（VX：TDengine），加入物聯網技術討論群，第一時間瞭解TDengine 官方資訊，與關注前沿技術的同學們共同探討新技術、新玩法。
------------
想了解更多 [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)")

TDengine3.0：解決高基數問題的時序資料庫設計思路

相關文章