從《寫(xiě)入性能：TDengine 最高達(dá)到 InfluxDB 的 10.3 倍，TimeScaleDB 的 6.74 倍》、《查詢性能：TDengine 最高達(dá)到了 InfluxDB 的 37 倍、 TimescaleDB 的 28.6 倍》兩篇文章中，我們發(fā)現(xiàn)，TDengine 不僅在寫(xiě)入和查詢性能上超越了 InfluxDB 和 TimescaleDB，在數(shù)據(jù)處理過(guò)程的資源消耗也比兩大時(shí)序數(shù)據(jù)庫(kù)要更低。本篇文章將會(huì)從 TDengine（ Time Series Database ） 的產(chǎn)品設(shè)計(jì)角度出發(fā)，為感興趣的小伙伴分析一下 TDengine 性能強(qiáng)消耗低的原因。

為什么 TDengine 的“寫(xiě)入強(qiáng)，開(kāi)銷低”？

“客戶端上 TDengine 對(duì) CPU 的需求大于 TimescaleDB 和 InfluxDB， 而 InfluxDB 的寫(xiě)入壓力基本上完全集中在服務(wù)端，這種模式很容易導(dǎo)致服務(wù)端成為瓶頸。TDengine 在客戶端的開(kāi)銷最大，峰值瞬間達(dá)到了 56%，然后快速回落。綜合服務(wù)器與客戶端的資源開(kāi)銷來(lái)看，TDengine 寫(xiě)入持續(xù)時(shí)間更短，在系統(tǒng)整體 CPU 開(kāi)銷上 TDengine 仍然具有相當(dāng)大的優(yōu)勢(shì)?！?/p>

在 TSBS 測(cè)試報(bào)告全部的 cpu-only 五個(gè)場(chǎng)景中，TDengine 寫(xiě)入性能均優(yōu)于 TimescaleDB 和 InfluxDB。相對(duì)于 TimescaleDB，TDengine 寫(xiě)入速度最領(lǐng)先的場(chǎng)景是其 6.7 倍（場(chǎng)景二），最少也是 1.5 倍（場(chǎng)景五），而且對(duì)于場(chǎng)景四，如果將每個(gè)采集點(diǎn)的記錄條數(shù)由 18 條增加到 576 條，TDengine 寫(xiě)入速度是 TimescaleDB 的 13.2 倍。相對(duì)于 InfluxDB，TDengine 寫(xiě)入速度最領(lǐng)先的場(chǎng)景是其 10.6 倍（場(chǎng)景五），最少也是 3.0 倍（場(chǎng)景一)。此外，在保證高效寫(xiě)入的情況下，TDengine 在寫(xiě)入過(guò)程中消耗的 CPU 資源和磁盤(pán) IO 開(kāi)銷也是最少的。

通過(guò)上圖可以看到，從客戶端負(fù)載來(lái)說(shuō)，三個(gè)系統(tǒng)中 InfluxDB 計(jì)算資源占用最低，對(duì)客戶端壓力最小，但這并不能說(shuō)明 InfluxDB 是三個(gè)數(shù)據(jù)庫(kù)當(dāng)中 CPU 開(kāi)銷最低的，因?yàn)槠鋵?xiě)入壓力基本完全集中在了服務(wù)端，而這種模式也為 InfluxDB 埋下了一個(gè)隱患，如果寫(xiě)入的數(shù)據(jù)規(guī)模過(guò)大，寫(xiě)入線程會(huì)長(zhǎng)時(shí)間地大量消耗服務(wù)器的計(jì)算和磁盤(pán)IO資源。

與 InfluxDB 相反，TDengine 在客戶端的開(kāi)銷最大，峰值直接沖到了 56%，其在客戶端的開(kāi)銷比 TimescaleDB 都多了 1 倍，但在用時(shí)上，卻比 InfluxDB 和 TimescaleDB 都小。也因此，從系統(tǒng)整體的 CPU 開(kāi)銷來(lái)看，TDengine 的優(yōu)勢(shì)仍舊非常顯著。

基于產(chǎn)品特點(diǎn)，我們可以從兩個(gè)方面分析這種“高寫(xiě)入，低開(kāi)銷”的特點(diǎn)。首先，為充分利用數(shù)據(jù)的時(shí)序性等特點(diǎn)，TDengine 采取了“一個(gè)數(shù)據(jù)采集點(diǎn)一張表”的策略，要求對(duì)每個(gè)數(shù)據(jù)采集點(diǎn)單獨(dú)建表（比如有一千萬(wàn)個(gè)智能電表，就需創(chuàng)建一千萬(wàn)張表），用來(lái)存儲(chǔ)這個(gè)數(shù)據(jù)采集點(diǎn)所采集的時(shí)序數(shù)據(jù)。這種設(shè)計(jì)對(duì)于提升寫(xiě)入性能來(lái)說(shuō)主要表現(xiàn)在兩個(gè)方面：

1. 由于不同數(shù)據(jù)采集點(diǎn)產(chǎn)生數(shù)據(jù)的過(guò)程完全獨(dú)立，每個(gè)數(shù)據(jù)采集點(diǎn)的數(shù)據(jù)源是唯一的，一張表也就只有一個(gè)寫(xiě)入者，這樣就可采用無(wú)鎖方式來(lái)寫(xiě)，寫(xiě)入速度就能大幅提升。
2. 對(duì)于一個(gè)數(shù)據(jù)采集點(diǎn)而言，其產(chǎn)生的數(shù)據(jù)是按照時(shí)間排序的，因此寫(xiě)的操作可用追加的方式實(shí)現(xiàn)，進(jìn)一步大幅提高數(shù)據(jù)寫(xiě)入速度。

其次，因?yàn)?TDengine 的 SQL 解析是在客戶端完成的，這樣一來(lái)，其在整個(gè)寫(xiě)入過(guò)程中，主要的負(fù)載都集中在客戶端，服務(wù)器端承擔(dān)的壓力就會(huì)變得非常小。我們之所以將寫(xiě)入的負(fù)載轉(zhuǎn)移到客戶端，其原因是客戶應(yīng)用端的伸縮和擴(kuò)展操作非常地便捷容易，可操作性更強(qiáng)——在保障服務(wù)器有剩余能力的情況下，如果寫(xiě)入性能不夠，只要增加寫(xiě)入進(jìn)程或?qū)懭肟蛻舳思纯山鉀Q此問(wèn)題，不再需要增加服務(wù)器的設(shè)備了。

試想一下，如果不需要變更服務(wù)器數(shù)量，那也就不會(huì)涉及到集群的伸縮操作、資源負(fù)載均衡等復(fù)雜邏輯，整體的寫(xiě)入成本自然就會(huì)顯著降低。

除了客戶端 CPU 開(kāi)銷外，三個(gè)系統(tǒng)對(duì)比，TDengine 對(duì)服務(wù)器的 CPU 需求也是最小的，峰值僅使用了 17% 左右的服務(wù)器 CPU 資源。在磁盤(pán)寫(xiě)入能力的消耗上，InfluxDB 長(zhǎng)時(shí)間消耗完全部的磁盤(pán)寫(xiě)入能力，TimescaleDB 寫(xiě)入過(guò)程對(duì)于寫(xiě)入的消耗相對(duì) InfluxDB 來(lái)說(shuō)要更具優(yōu)勢(shì)，但是仍然遠(yuǎn)超 TDengine 對(duì)磁盤(pán)寫(xiě)入能力的需求。

如何用最小的計(jì)算開(kāi)銷實(shí)現(xiàn)最高的查詢性能？

“從整體 CPU 開(kāi)銷上來(lái)看，TDengine 不僅完成全部查詢的時(shí)間低于 TimescaleDB 和 InfluxDB，在整體上CPU計(jì)算資源的消耗也遠(yuǎn)小于 TimescaleDB 和 InfluxDB。在整個(gè)查詢過(guò)程中，TDengine 內(nèi)存也始終維持在一個(gè)相對(duì)平穩(wěn)的狀態(tài)?！?/p>

基于 TSBS 測(cè)試報(bào)告我們可以總結(jié)出，查詢方面，在場(chǎng)景一（只包含 4 天的數(shù)據(jù)）與場(chǎng)景二的 15 個(gè)不同類型的查詢中，TDengine 的查詢平均響應(yīng)時(shí)間全面優(yōu)于 InfluxDB 和 TimescaleDB，而且在復(fù)雜查詢上優(yōu)勢(shì)更為明顯，同時(shí)具有最小的計(jì)算資源開(kāi)銷。相比 InfluxDB，場(chǎng)景一中 TDengine 查詢性能是其 1.9 ～ 37.0 倍，場(chǎng)景二中 TDengine 查詢性能是其 1.8 ～ 34.2 倍；相比 TimescaleDB，場(chǎng)景一中 TDengine 查詢性能是其 1.1 ～ 28.6 倍，場(chǎng)景二中 TDengine 查詢性能是其 1.2 ～ 24.6 倍。

在資源開(kāi)銷上，TDengine 在查詢過(guò)程中整體 CPU 占用約 80%，是三個(gè)系統(tǒng)中最高的，TimescaleDB 在查詢過(guò)程中瞬時(shí) CPU 占用次之，InfluxDB 的穩(wěn)定 CPU 占用最?。ǖ怯休^多的瞬時(shí)沖高）。從整體 CPU 開(kāi)銷上來(lái)看，雖然 InfluxDB 瞬時(shí) CPU 開(kāi)銷大部分是最低的，但是其完成查詢持續(xù)時(shí)間最長(zhǎng)，所以整體 CPU 資源消耗最多。由于 TDengine 完成全部查詢的時(shí)間僅為 TimescaleDB 或 InfluxDB 的 1/20，雖然 CPU 穩(wěn)定值是 TimescaleDB 與 InfluxDB 的 2 倍多，但整體的 CPU 計(jì)算時(shí)間消耗只有其 1/10 。

用最小的計(jì)算開(kāi)銷實(shí)現(xiàn)最高的查詢性能，TDengine 是如何做到的呢？首先，TDengine 對(duì)每個(gè)數(shù)據(jù)采集點(diǎn)單獨(dú)建表，但在實(shí)際應(yīng)用中經(jīng)常需要對(duì)不同的采集點(diǎn)數(shù)據(jù)進(jìn)行聚合。為高效的進(jìn)行聚合操作，TDengine 引入超級(jí)表（STable）的概念。超級(jí)表用來(lái)代表一特定類型的數(shù)據(jù)采集點(diǎn)，它是包含多張表的表集合，集合里每張表的模式（schema）完全一致，但每張表都帶有自己的靜態(tài)標(biāo)簽，標(biāo)簽可以有多個(gè)，可以隨時(shí)增加、刪除和修改。應(yīng)用可通過(guò)指定標(biāo)簽的過(guò)濾條件，對(duì)一個(gè) STable 下的全部或部分表進(jìn)行聚合或統(tǒng)計(jì)操作，這樣就大大簡(jiǎn)化了應(yīng)用的開(kāi)發(fā)。其具體流程如下圖所示：

由于 TDengine 在 vnode 內(nèi)將標(biāo)簽數(shù)據(jù)與時(shí)序數(shù)據(jù)分離存儲(chǔ)，通過(guò)在內(nèi)存里過(guò)濾標(biāo)簽數(shù)據(jù)，就可以先找到需要參與聚合操作的表的集合，這樣需要掃描的數(shù)據(jù)集就會(huì)變得大幅減少，聚合計(jì)算速度自然就會(huì)獲得顯著提升。同時(shí)，由于數(shù)據(jù)分布在多個(gè) vnode/dnode，聚合計(jì)算操作在多個(gè) vnode 里并發(fā)進(jìn)行，這又進(jìn)一步提升了聚合的速度。

其次，在單表查詢上，當(dāng)我們要對(duì)全部數(shù)據(jù)集進(jìn)行查詢時(shí)，就需要將查詢請(qǐng)求廣播到所有的節(jié)點(diǎn)。試想一下，當(dāng)我們?cè)跇I(yè)務(wù)場(chǎng)景中需要對(duì)某個(gè)設(shè)備進(jìn)行查詢，這時(shí)如果可以不使用標(biāo)簽過(guò)濾，直接查詢對(duì)應(yīng)的設(shè)備，查詢效率是不是變得更高了，TDengine 便是如此。在本次測(cè)試報(bào)告中就有幾個(gè)這樣的場(chǎng)景，TDengine 都表現(xiàn)出了很好的查詢性能。

此外，為有效提升查詢處理的性能，針對(duì)物聯(lián)網(wǎng)數(shù)據(jù)不可更改的特點(diǎn)，TDengine 會(huì)在數(shù)據(jù)塊頭部記錄該數(shù)據(jù)塊中存儲(chǔ)數(shù)據(jù)的統(tǒng)計(jì)信息：包括最大值、最小值、和，我們稱之為預(yù)計(jì)算單元。如果查詢處理涉及整個(gè)數(shù)據(jù)塊的全部數(shù)據(jù)，就可以直接使用預(yù)計(jì)算結(jié)果，完全不需要讀取數(shù)據(jù)塊的內(nèi)容。由于預(yù)計(jì)算數(shù)據(jù)量遠(yuǎn)小于磁盤(pán)上存儲(chǔ)的數(shù)據(jù)塊數(shù)據(jù)的大小，對(duì)于磁盤(pán) I/O 為瓶頸的查詢處理，使用預(yù)計(jì)算結(jié)果可以極大地減小讀取 I/O 壓力，加速查詢處理的流程。預(yù)計(jì)算機(jī)制與 PostgreSQL 的索引 BRIN（block range index）有異曲同工之妙。

用極致壓縮比實(shí)現(xiàn)存儲(chǔ)成本的最大程度降低

“磁盤(pán)空間占用方面，TimescaleDB 在所有五個(gè)場(chǎng)景下的數(shù)據(jù)規(guī)模均顯著大于 InfluxDB 和 TDengine，并且這種差距隨著數(shù)據(jù)規(guī)模增加快速變大。TimescaleDB 在場(chǎng)景四和場(chǎng)景五中占用磁盤(pán)空間是 TDengine 的 25.6 倍和 26.9 倍。在前面三個(gè)場(chǎng)景中，InfluxDB 落盤(pán)后數(shù)據(jù)文件規(guī)模與 TDengine 非常接近，但是在大數(shù)據(jù)規(guī)模的場(chǎng)景四和場(chǎng)景五中，InfluxDB 落盤(pán)后文件占用的磁盤(pán)空間是 TDengine 的 4.2 倍和 4.5 倍?！?/p>

當(dāng)數(shù)據(jù)寫(xiě)入磁盤(pán)時(shí)，TDengine 會(huì)根據(jù)系統(tǒng)配置參數(shù) comp 決定是否壓縮數(shù)據(jù)。TDengine 共提供了三種壓縮選項(xiàng)：無(wú)壓縮、一階段壓縮和兩階段壓縮，分別對(duì)應(yīng) comp 值為 0、1 和 2 的情況。一階段壓縮根據(jù)數(shù)據(jù)的類型進(jìn)行了相應(yīng)的壓縮，壓縮算法包括 delta-delta 編碼、simple 8B 方法、zig-zag 編碼、LZ4 等算法。二階段壓縮在一階段壓縮的基礎(chǔ)上又用通用壓縮算法進(jìn)行了壓縮，壓縮率更高。

同時(shí)，TDengine 采用的是標(biāo)簽分離存儲(chǔ)機(jī)制，即標(biāo)簽與數(shù)據(jù)是分開(kāi)進(jìn)行存儲(chǔ)的，這樣就帶來(lái)了兩個(gè)方面的好處：

1. 在存儲(chǔ)操作上占用更小的磁盤(pán)空間，表級(jí)別的標(biāo)簽基本上沒(méi)有冗余。
2. 標(biāo)簽集中存儲(chǔ)更有利于標(biāo)簽過(guò)濾操作中 IO 訪問(wèn)的局部性，標(biāo)簽過(guò)濾完成得更快，查詢性能也會(huì)變得更好。

此外，對(duì)于 TDengine 來(lái)說(shuō)，每個(gè)數(shù)據(jù)塊內(nèi)部采用的就是列式存儲(chǔ)模式，而且打造了“一個(gè)數(shù)據(jù)采集點(diǎn)一張表”的創(chuàng)新設(shè)計(jì)，一個(gè)數(shù)據(jù)采集點(diǎn)采集量的變化肯定比多個(gè)采集點(diǎn)的采集量變化更慢，壓縮率自然也會(huì)變得更高。綜合上述的幾點(diǎn)設(shè)計(jì)，TDengine 在進(jìn)行數(shù)據(jù)處理時(shí)提供了很好的壓縮比，幫用戶節(jié)約了存儲(chǔ)空間和存儲(chǔ)資源，極大程度上減少了存儲(chǔ)成本浪費(fèi)。

寫(xiě)在最后

在產(chǎn)品開(kāi)發(fā)之初，TDengine 就明確了設(shè)計(jì)方向，即針對(duì)時(shí)序數(shù)據(jù)的特點(diǎn)對(duì)寫(xiě)入、存儲(chǔ)、查詢等流程進(jìn)行設(shè)計(jì)和優(yōu)化，在經(jīng)過(guò)幾個(gè)版本的不斷迭代加強(qiáng)后，其存儲(chǔ)量大、存儲(chǔ)運(yùn)維成本低、讀寫(xiě)性能卓越、壓縮率高等特點(diǎn)越發(fā)顯著。這些優(yōu)勢(shì)也體現(xiàn)在企業(yè)的具體實(shí)踐上，以西門(mén)子的數(shù)字化解決方案改造項(xiàng)目為例，TDengine 幫助其 SIMICAS? OEM 2.0 版本移除了 Flink、Kafka 以及 Redis，大大簡(jiǎn)化了系統(tǒng)架構(gòu)，節(jié)約了運(yùn)維成本；而在零跑科技的 C11 新車型項(xiàng)目中，TDengine 高壓縮算法助力其壓縮性能提升了10-20 倍，降低存儲(chǔ)壓力的同時(shí)也解決了數(shù)據(jù)存儲(chǔ)成本高的問(wèn)題。

如果你也面臨著性能和成本難以兩全的數(shù)據(jù)處理難題，亟需升級(jí)數(shù)據(jù)架構(gòu)，歡迎添加小T vx：tdengine1，加入 TDengine 用戶交流群，和更多志同道合的開(kāi)發(fā)者一起攻克難關(guān)。