小 T 導讀： 數據集的高基數（High-Cardinality）問題一直困擾著諸多主流的時序數據庫（Time Series Database，TSDB）產品。一些數(shu)(shu)據(ju)庫(ku)管理(li)系(xi)統，在基數(shu)(shu)較低(di)時表現良好；但是隨(sui)著基數(shu)(shu)的增加，數(shu)(shu)據(ju)庫(ku)的表現也會變差，這就給數(shu)(shu)據(ju)庫(ku)管理(li)員帶(dai)來了(le)很大的挑戰(zhan)，他們(men)需要通過相關設(she)計降低(di)基數(shu)(shu)，避免與之相關的問(wen)題。
TDengine 3.0 是第一個解決了高基數問題的時序數據庫，本文將(jiang)分享(xiang)其設計(ji)思(si)路。
何謂高基數問題？
講到高基(ji)數問題(ti)，首先，我們要理解什么是(shi)(shi)(shi)基(ji)數（Cardinality）。基(ji)數可(ke)以定義為一個(ge)數據(ju)集(ji)中(zhong)值的數量。數據(ju)集(ji)不同，基(ji)數可(ke)以很高，也可(ke)以很低。比(bi)如(ru)(ru)，如(ru)(ru)果(guo)是(shi)(shi)(shi)布爾數據(ju)，它的值只(zhi)能是(shi)(shi)(shi) true 或 false，則該數據(ju)集(ji)的基(ji)數為 2。但是(shi)(shi)(shi)如(ru)(ru)果(guo)是(shi)(shi)(shi)像設備(bei) ID 這樣(yang)的數據(ju)集(ji)，其(qi)基(ji)數就非(fei)常大(da)了。
對于時序數據，事情(qing)就更復雜了。時序數據(ju)總會關聯(lian)一些(xie)元(yuan)數據(ju)，比如標簽。因此，一個(ge)系(xi)統(tong)的(de)基(ji)數就是每個(ge)標簽的(de)基(ji)數的(de)叉乘。比如，以(yi)智能電表為例，它會關聯(lian)設(she)備 ID、城(cheng)市 ID、廠商 ID 和模型 ID 等標簽。幾百個(ge)城(cheng)市，百萬級設(she)備，再加上不同的(de)廠商、模型，基(ji)數輕(qing)松超(chao)過百億級。
高基數有什么問題呢？這會增加定位一個唯一的值所需要的時間。對于數據庫而言，延遲與基數直接相關。許多時序數據庫，如 InfluxDB、OpenTSDB 和 Prometheus，都采用了鍵值存儲模型(xing)，其中(zhong)的(de)(de)鍵是由(you)標(biao)簽組合唯一(yi)識別的(de)(de)。這種模式有(you)個(ge)副作用，它會極大(da)增(zeng)加數據集的(de)(de)基(ji)數。
那 TDengine 3.0 是如何(he)解決(jue)高基數問(wen)題的(de)呢？下面我(wo)們一起看一下它的(de)幾個核心設計。
數據模型：一個數據采集點一張表
特有(you)的(de)(de)數(shu)據模型，是(shi) TDengine 的(de)(de)一(yi)大核(he)心設計，即“一(yi)個(ge)數(shu)據采(cai)(cai)集(ji)(ji)點一(yi)張表”。也就是(shi)說，TDengine 建議(yi)為數(shu)據采(cai)(cai)集(ji)(ji)點創建一(yi)張單(dan)獨的(de)(de)表。一(yi)般情況(kuang)下，一(yi)個(ge)設備(bei)就是(shi)一(yi)個(ge)數(shu)據采(cai)(cai)集(ji)(ji)點；但是(shi)在更復雜的(de)(de)情況(kuang)下，一(yi)個(ge)設備(bei)可能包含多個(ge)數(shu)據采(cai)(cai)集(ji)(ji)點，而(er)且不同的(de)(de)采(cai)(cai)集(ji)(ji)點有(you)不同的(de)(de)采(cai)(cai)集(ji)(ji)頻率。
在設計上，TDengine 使用一致性哈(ha)希來(lai)確定(ding)哪個(ge)虛擬節點(dian)（vnode）負責存儲特點(dian)表（table）的數(shu)據。在 vnode 內部，系統(tong)會(hui)構建索引，以(yi)提升(sheng)定(ding)位 table 的速度。隨著表數(shu)量的增多(duo)，TDengine 會(hui)創建更多(duo) vnode，盡量減少(shao)定(ding)位到(dao)某個(ge) table 的時(shi)間，并(bing)支持系統(tong)輕松(song)伸縮。
這種設(she)計保證了向任何一(yi)個表插入數(shu)(shu)據(ju)或從任何一(yi)個表查詢數(shu)(shu)據(ju)的延(yan)遲(chi)，即使表的數(shu)(shu)量(liang)呈指數(shu)(shu)增長。因此，延(yan)遲(chi)不受 TDengine 中高基數(shu)(shu)的影(ying)響。
將元數據與時序數據分離
通過“一個(ge)數(shu)據采集點一張(zhang)表”的(de)(de)(de)設(she)計(ji)，TDengine 可以保(bao)證單(dan)一表的(de)(de)(de)延遲。但是，現實世界的(de)(de)(de)具體應用往(wang)往(wang)需要聚合多個(ge)表或設(she)備中的(de)(de)(de)數(shu)據。這是 TDengine 在設(she)計(ji)上要面對的(de)(de)(de)一個(ge)主要挑戰。
為(wei)了解決這個(ge)問題，TDengine 引(yin)入了超(chao)級表(biao)(biao)（supertable）。與(yu)標準的數據(ju)(ju)(ju)庫不(bu)同(tong)，超(chao)級表(biao)(biao)允許(xu)應用程(cheng)序將一(yi)組(zu)標簽關(guan)聯到(dao)每個(ge)表(biao)(biao)。TDengine 會(hui)(hui)將這些(xie)標簽與(yu)采(cai)集到(dao)的時(shi)序數據(ju)(ju)(ju)分開存儲：使用 B 樹為(wei)標簽建立索(suo)引(yin)，將其保(bao)存到(dao)元數據(ju)(ju)(ju)存儲中；而時(shi)序數據(ju)(ju)(ju)保(bao)存在(zai)一(yi)個(ge)單獨的時(shi)序數據(ju)(ju)(ju)存儲中。元數據(ju)(ju)(ju)存儲中的每張表(biao)(biao)只(zhi)有一(yi)行(xing)數據(ju)(ju)(ju)，而且可(ke)以根據(ju)(ju)(ju)需要更新。在(zai)時(shi)序數據(ju)(ju)(ju)存儲中，每個(ge)表(biao)(biao)都(dou)有許(xu)多行(xing)數據(ju)(ju)(ju)，而且數據(ju)(ju)(ju)集會(hui)(hui)隨(sui)著時(shi)間的推移而增長(chang)，直到(dao)其生命周期結束。
為了聚(ju)合多個表的(de)數(shu)(shu)據(ju)，應用程序(xu)可以通(tong)過(guo)(guo)(guo)標簽來過(guo)(guo)(guo)濾。當(dang)執(zhi)行時(shi)(shi)，TDengine 首先搜(sou)索元數(shu)(shu)據(ju)存儲，并(bing)(bing)獲得滿足(zu)過(guo)(guo)(guo)濾條件的(de)表的(de)列表，然后再來獲取存儲在時(shi)(shi)序(xu)數(shu)(shu)據(ju)存儲中(zhong)的(de)數(shu)(shu)據(ju)塊，并(bing)(bing)完成(cheng)聚(ju)合過(guo)(guo)(guo)程。
首先掃描(miao)元(yuan)數(shu)據(ju)存儲，因為這個(ge)數(shu)據(ju)集比時序(xu)數(shu)據(ju)存儲的規模要小(xiao)得(de)多，TDengine 就可以(yi)提(ti)供(gong)非(fei)常高效的聚合(he)能力。這個(ge)過(guo)程(cheng)可以(yi)用下圖表示。
分布式存儲元數據
在(zai) TDengine 2.x 的(de)(de)設計中，表的(de)(de)元數據，比如模(mo)式和標簽，都存儲在(zai)管理節點(dian)（mnode）上(shang)。如果(guo)創建的(de)(de)表的(de)(de)數量達到千萬級(ji)，這(zhe)就會成(cheng)為 TDengine 的(de)(de)一個(ge)瓶頸：過濾(lv)這(zhe)么多標簽的(de)(de)延遲會明顯增(zeng)加了(le)。
到(dao)(dao)了 TDengine 3.0，我們會將元數(shu)據存儲(chu)分(fen)布在 vnode 中(zhong)，而不再是集中(zhong)化存儲(chu)在 mnode 上。當一個(ge)應用想從多個(ge)表聚合(he)數(shu)據時，TDengine 會同(tong)時向所有(you)的 vnode 發送過濾條件。然后(hou)，每個(ge) vnode 并(bing)行工作，找到(dao)(dao)所要求的表，聚合(he)數(shu)據，最后(hou)將結果送回查詢(xun)節點或驅動，并(bing)在那里執行合(he)并(bing)操(cao)作。
現在，TDengine 3.0 的(de)分布式設計保證了標(biao)簽過濾操作(zuo)的(de)延遲，只(zhi)要系統(tong)資源充(chong)足，mnode 不再是(shi)瓶(ping)頸。隨(sui)著創(chuang)建的(de)表的(de)增(zeng)多(duo)，TDengine 只(zhi)需要為(wei)其分配更(geng)多(duo)資源，創(chuang)建更(geng)多(duo) vnode，以確保系統(tong)的(de)可擴展性。
總的(de)來說，通過(guo)創(chuang)新的(de)設計，TDengine 3.0 很好地解決了高基數問(wen)題。歡迎，為業務創(chuang)新提速。
