存儲成本僅為 OpenTSDB 的 1/10 ，TDengine 的最大殺手锏是什么？

Yu Chen

2021-06-09 / Chinese, 技術文章 - 時序數據庫

在《這幾個神秘參數，教你TDengine集群的正確使用方式》中，我們(men)告訴了大家：如(ru)何才能讓數據均勻的分布在節點(dian)中。接下來，我們(men)和大家一起以產(chan)品使用者的視角繼(ji)續向前探索。

如果說讓數(shu)(shu)據均勻分(fen)布的(de)(de)目的(de)(de)是為(wei)了(le)最(zui)大化地(di)使(shi)用CPU資源的(de)(de)話，那(nei)么充分(fen)地(di)利用數(shu)(shu)據壓縮能力就(jiu)是為(wei)了(le)最(zui)大化地(di)駕馭存儲資源了(le)。

我(wo)只能(neng)說，在這個方(fang)面 TDengine Database 做(zuo)得棒極了。

在官網(wang)上，有這樣的描述：

TDengine 相對(dui)于通用數據庫，有超高的(de)壓縮(suo)比，在(zai)絕大多數場(chang)景下，TDengine 的(de)壓縮(suo)比不會低于 5 倍，有的(de)場(chang)合，壓縮(suo)比可達到 10 倍以上。

下(xia)面就(jiu)是(shi) TDengine Database 在最近三(san)個(ge)月(yue)內(nei)打(da)出的成績。

在順豐科技的應用案例中，TDengine輕松替換掉(diao)了 OpenTSDB + HBase：

服務端(duan)物理(li)機(ji)由 21 臺(tai)降至 3 臺(tai)，每日所需(xu)存儲空間為 93 G（2 副本(ben)(ben)），同(tong)等副本(ben)(ben)下(xia)僅為 OpenTSDB + HBase 的約 1/10 ，在降低成本(ben)(ben)方面(mian)相對通用(yong)性大數據平臺(tai)有(you)非常大的優(you)勢。

在得物APP的應用案例中(zhong)，TDengine通過(guo)10%的壓(ya)縮率為對(dui)方(fang)節約了大量存(cun)儲資源：

目前 Sentinel 的數據沒有使用副(fu)本，全量數據分散在三臺機器中，根據計算得知 TDengine 對于 Sentinel 監控數據的壓縮(suo)率達(da) 10 %，相當可觀。

一是開源產品(pin)免(mian)費，二是能(neng)白(bai)白(bai)給自己(ji)省(sheng)下那(nei)么多服務器(qi)，三是讀寫(xie)性能(neng)都不(bu)錯——這種(zhong)降本增效的工(gong)具誰(shui)不(bu)喜歡(huan)呢。

于是一些用戶開始安裝產品，并開始使用官方推薦的壓測工具 taosdemo 造數寫入，想看看是(shi)不是(shi)真的可以做到宣傳(chuan)的效果。

但是測試過后(hou)，很(hen)多用戶感覺 TDengine 的(de)壓縮率并沒有達到(dao)自己的(de)預期。可(ke)另(ling)一方面，順(shun)豐和得物(wu)這些大企業(ye)又實實在(zai)在(zai)地得到(dao)了非常可(ke)觀的(de)成本降(jiang)低，那么問題到(dao)底出(chu)在(zai)哪里呢？

大家(jia)都(dou)知道 IoT 數(shu)據(ju)的特點之一就是(shi)(shi)，對于同一監測量而言(yan)，相互之間(jian)相差小且有(you)規律，即便是(shi)(shi)字符型也(ye)會有(you)相當(dang)大數(shu)據(ju)重(zhong)復(fu)出現(xian)或者類似的可(ke)能。正是(shi)(shi)這樣的數(shu)據(ju)模(mo)型才給(gei)了 TDengine 的列式壓縮廣(guang)闊(kuo)的發揮空間(jian)。

但是呢，如(ru)果(guo)僅以 taosdemo 默(mo)認(ren)配(pei)(pei)置(zhi)的(de)(de)隨機數據來做測試，生成的(de)(de)數據未必(bi)具有這樣(yang)的(de)(de)特點。比如(ru)，默(mo)認(ren)的(de)(de)配(pei)(pei)置(zhi)有一個長度(du)為16的(de)(de)nchar字符類(lei)型，每(mei)個 nchar 字符占用 4 bytes 的(de)(de)存儲(chu)空間4*16占據了幾(ji)乎一半的(de)(de)行長度(du)又不好壓縮，所(suo)以就(jiu)顯(xian)得壓縮效率有點低。

為了(le)優化(hua)這(zhe)個體驗，在2.1版本的(de)(de) taosdemo 里(li)默認(ren)的(de)(de)寫入數(shu)據換(huan)成了(le)四列INT。但如果(guo)大(da)家想(xiang)寫入自(zi)定義格式的(de)(de)數(shu)據，只要(yao)根據這(zhe)個博(bo)客操作(zuo)就好了(le)。

那么(me)回到(dao)真(zhen)實(shi)生產環境(jing)上，又(you)會是什(shen)么(me)情(qing)況呢。換言之，TDengine到(dao)底(di)是如何幫助順(shun)豐與得物這(zhe)樣的獨角獸企業降低存(cun)儲成本的呢？

接下來，我們就來看看——什么叫贏在起跑線上：超級表建表語句和普通表建表語句的區別就只在這一個地方——Tag（標簽）。超級表多了它就可以管理百萬千萬級別(bie)的子表，充(chong)分地說明了它的重要性(xing)。

正是因為TDengine把每(mei)個設備的(de)標簽都提(ti)取(qu)出來放在了內(nei)存里，所以才讓設備的(de)裸數據量天(tian)生就(jiu)少(shao)了很多。所以，如(ru)果(guo)你(ni)想(xiang)(xiang)測試一樣的(de)業務場(chang)景下的(de)性(xing)能(neng)時，在生成數據的(de)那(nei)一刻你(ni)就(jiu)會發現TDengine已(yi)經贏了。因為想(xiang)(xiang)要(yao)營造出一樣的(de)場(chang)景，它(ta)根本不需(xu)要(yao)造出那(nei)么多數據。

假設(she)(she)一(yi)個(ge)設(she)(she)備光是標簽數就(jiu)和測點數差不(bu)多(duo)甚至(zhi)更多(duo)的時候，那(nei)在原始(shi)數據(ju)上你就(jiu)可能(neng)已經省下(xia)了(le)至(zhi)少一(yi)半的磁盤占用。

接下來，我們來看看 TDengine 的數據壓縮流程：當數據寫入內存的時候，為了防止斷電等特殊情況帶來的數據丟失，TDengine 會把數據先寫入WAL(Write Ahead Log)文件。

當落盤(pan)機制(zhi)被觸(chu)發，數(shu)據(ju)開(kai)始(shi)持久化到存儲之前，COMP 參數(shu)就(jiu)開(kai)始(shi)生效了。根據(ju)這(zhe)個參數(shu)的(de)值（0 1 2），TDengine 會分別選擇是做(zuo)不壓(ya)(ya)縮(suo)(suo)(suo)(suo)，一(yi)階(jie)段(duan)壓(ya)(ya)縮(suo)(suo)(suo)(suo)，還(huan)是二階(jie)段(duan)壓(ya)(ya)縮(suo)(suo)(suo)(suo)：一(yi)階(jie)段(duan)壓(ya)(ya)縮(suo)(suo)(suo)(suo)會根據(ju)數(shu)據(ju)的(de)類(lei)型進行(xing)了相應的(de)列壓(ya)(ya)縮(suo)(suo)(suo)(suo)，壓(ya)(ya)縮(suo)(suo)(suo)(suo)算法(fa)包括delta-delta編(bian)碼(ma)、simple 8B方法(fa)、zig-zag編(bian)碼(ma)、LZ4等算法(fa)。所以，總結一(yi)下：

1.對于特定列有特定算法的針對性壓縮
2.物聯網場景下數據的普遍規律性

這(zhe)兩點(dian)共同(tong)造就了TDengine超(chao)強的壓縮能力。

接下來，二階段壓(ya)(ya)縮(suo)又在(zai)一階段壓(ya)(ya)縮(suo)的基礎上(shang)用(yong)通用(yong)壓(ya)(ya)縮(suo)算法(fa)進行了壓(ya)(ya)縮(suo)，壓(ya)(ya)縮(suo)效果(guo)更高。關于(yu)TDengine壓(ya)(ya)縮(suo)算法(fa)的說明見如(ru)下鏈接。

最后，我們再來看看，到底要如何估(gu)算出壓縮率：

首先，我們要算出(chu)裸數(shu)據的大(da)小，官網上提供的計算公式為(wei)：

Raw DataSize = numOfTables * rowSizePerTable * rowsPerTable

rowSizePerTable（每行長(chang)(chang)度(du)(du)(du)）可以根據(ju)每個(ge)數據(ju)類型的(de)長(chang)(chang)度(du)(du)(du)來(lai)計算(suan)。describe table你會看到表的(de)結構以及各(ge)個(ge)字(zi)段的(de)大小。其中(zhong)binary和nchar類的(de)長(chang)(chang)度(du)(du)(du)為最大長(chang)(chang)度(du)(du)(du)。實際(ji)占(zhan)用要以真實數據(ju)長(chang)(chang)度(du)(du)(du)為準（下(xia)面示范中(zhong)binary和nachar占(zhan)滿全(quan)部(bu)空間(jian)），而nchar字(zi)段的(de)占(zhan)用長(chang)(chang)度(du)(du)(du)還要乘4。此外(wai)，每個(ge)binary和nchar還要額(e)外(wai)占(zhan)據(ju)兩個(ge)字(zi)節。

比如下表：

在假設Binary和Nchar數據都是寫滿16個的情(qing)況(kuang)下，單行總(zong)長(chang)度就是（8+1+2+4+8+4+8+16+16*4+1+8）+4=128字節。用128字節乘以 rowsPerTable（每個表(biao)(biao)行數）*numOfTables(表(biao)(biao)數)，就可(ke)以大體地估(gu)算出我們(men)的總(zong)數據量了。

其實，測試中更常見(jian)的(de)是(shi)直(zhi)(zhi)接用超(chao)級表作為測試主體，直(zhi)(zhi)接使用超(chao)級表的(de)count（*）數(shu)據去乘以(yi)每行長度就(jiu)可以(yi)得(de)到Raw DataSize了(le)。

最后，再(zai)用/var/lib/taos/vnode/下面各個(ge)vnode的數據文件大小(xiao)除(chu)以Raw DataSize。

大(da)功告成——我們終于得出實際壓縮率了(le)。這(zhe)里(li)，大(da)家(jia)要(yao)留意一下：在數(shu)據文件目錄(lu)下的(de)vnode目錄(lu)里(li)面還有一個wal目錄(lu)。如果(guo)這(zhe)里(li)面有數(shu)據說明數(shu)據還沒(mei)有落盤(pan)到存儲里(li)面，也就是說數(shu)據是還沒(mei)有壓縮過的(de)。為了(le)讓測(ce)試結果(guo)更加精準，所以大(da)家(jia)可(ke)以使(shi)用最簡單直接的(de)辦法——重啟服務進程，這(zhe)樣就可(ke)以直接觸發落盤(pan)機制了(le)。