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

TDengine 3.0 是第一個解決了高基數問題的時序數據庫，本文將分享其設計思路。

何謂高基數問題？

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

對于時序數據，事情就更復雜了。時序數據總會關聯一些元數據，比如標簽。因此，一個系統的基數就是每個標簽的基數的叉乘。比如，以智能電表為例，它會關聯設備 ID、城市 ID、廠商 ID 和模型 ID 等標簽。幾百個城市，百萬級設備，再加上不同的廠商、模型，基數輕松超過百億級。

高基數有什么問題呢？這會增加定位一個唯一的值所需要的時間。對于數據庫而言，延遲與基數直接相關。許多時序數據庫，如 InfluxDB、OpenTSDB 和 Prometheus，都采用了鍵值存儲模型，其中的鍵是由標簽組合唯一識別的。這種模式有個副作用，它會極大增加數據集的基數。

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

數據模型：一個數據采集點一張表

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

在設計上，TDengine 使用一致性哈希來確定哪個虛擬節點（vnode）負責存儲特點表（table）的數據。在 vnode 內部，系統會構建索引，以提升定位 table 的速度。隨著表數量的增多，TDengine 會創建更多 vnode，盡量減少定位到某個 table 的時間，并支持系統輕松伸縮。

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

將元數據與時序數據分離

通過“一個數據采集點一張表”的設計，TDengine 可以保證單一表的延遲。但是，現實世界的具體應用往往需要聚合多個表或設備中的數據。這是 TDengine 在設計上要面對的一個主要挑戰。

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

為了聚合多個表的數據，應用程序可以通過標簽來過濾。當執行時，TDengine 首先搜索元數據存儲，并獲得滿足過濾條件的表的列表，然后再來獲取存儲在時序數據存儲中的數據塊，并完成聚合過程。

首先掃描元數據存儲，因為這個數據集比時序數據存儲的規模要小得多，TDengine 就可以提供非常高效的聚合能力。這個過程可以用下圖表示。

分布式存儲元數據

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

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

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

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