遷移背景

隨著時(shí)序數(shù)據(jù)庫(kù)（Time Series Database） TDengine 3.0 的發(fā)布至今，我們除了在持續(xù)地優(yōu)化產(chǎn)品質(zhì)量的本身，也一直在努力地提升用戶體驗(yàn)。但由于 3.0 底層有大量的重構(gòu)優(yōu)化，導(dǎo)致開(kāi)源版的 2.0 用戶無(wú)法通過(guò)常規(guī)途徑來(lái)升級(jí)到 3.0 ，本期文章將會(huì)協(xié)助大部分開(kāi)源版用戶解決這個(gè)問(wèn)題。
目前，我們可以提供兩種遷移方案：

1. TDengine 官方工具 taosdump；
2. 開(kāi)源數(shù)據(jù)遷移解決方案：dataX TDengine reader/writter；

前者會(huì)把數(shù)據(jù)根據(jù)配置導(dǎo)出壓縮存儲(chǔ)到本地，產(chǎn)品屬性更傾向于備份/恢復(fù)工具。后者則會(huì)在內(nèi)存中直接傳輸數(shù)據(jù)，偏向數(shù)據(jù)遷移工具。本篇文章的主體為前者的 taosdump，dataX 的使用方式可以通過(guò)這篇文章來(lái)了解：http://m.fjzmyy.cn/engineering/16401.html

首先，我們先說(shuō)下 taosdump 為什么是協(xié)助“大部分”開(kāi)源版用戶解決這個(gè)問(wèn)題：

taosdump 的導(dǎo)出行為的本質(zhì)其實(shí)是使用 SQL 進(jìn)行查詢，將數(shù)據(jù)壓縮后輸出到本地，導(dǎo)入行為則是通過(guò) STMT 接口再把導(dǎo)出的數(shù)據(jù)導(dǎo)入新的環(huán)境。在內(nèi)部，它嵌入了一個(gè) TDengine 客戶端，通過(guò) -T 參數(shù)的線程數(shù)配置，并發(fā)地把所有 SQL 請(qǐng)求發(fā)給數(shù)據(jù)庫(kù)，此后，后續(xù)的查詢工作就是數(shù)據(jù)庫(kù)自己的事情了。鑒于以上原因，所以它的導(dǎo)出導(dǎo)入的性能都十分依賴于數(shù)據(jù)庫(kù)本身的部署建模是否科學(xué)，硬件資源是否充足等因素。

舉個(gè)簡(jiǎn)單例子：假如某用戶在建表的時(shí)候，對(duì)于一列本應(yīng)使用 binary(100) 就足夠的數(shù)據(jù)使用了 nchar(2000)，那么等到導(dǎo)出 SQL 執(zhí)行的時(shí)候，性能就會(huì)被拖累很多。

因此，能夠順利完成數(shù)據(jù)導(dǎo)出的用戶，應(yīng)盡量擁有如下幾個(gè)特征：

1. 擁有足夠磁盤空間——因?yàn)橛脖P上的數(shù)據(jù)是列式壓縮，而導(dǎo)出數(shù)據(jù)為行式壓縮。如果選擇一次性導(dǎo)出全部數(shù)據(jù)，建議需要至少留出 du -sh $dataDir/vnode –exclude=’wal’ 大小的 3 倍空間（多多益善）。但如果是按照庫(kù)/表為單位分批導(dǎo)出，或者指定時(shí)間范圍導(dǎo)出的話，就比較靈活了。
   
2. 數(shù)據(jù)庫(kù)日常使用負(fù)載不高，在大量導(dǎo)出 SQL 執(zhí)行時(shí)，數(shù)據(jù)庫(kù)仍有充足資源可以保障正常生產(chǎn)使用。
   
3. 待遷移的 2.0 數(shù)據(jù)為測(cè)試環(huán)境不需擔(dān)心影響業(yè)務(wù)，或者生產(chǎn)環(huán)境的業(yè)務(wù)間歇期足夠完成數(shù)據(jù)的導(dǎo)出——這兩點(diǎn)需要結(jié)合當(dāng)前導(dǎo)出速度自己評(píng)估。

總結(jié)

導(dǎo)出/導(dǎo)入數(shù)據(jù)的快慢是由 SQL 執(zhí)行效率來(lái)決定的，而 SQL執(zhí)行效率的背后又是由部署建模，硬件資源等因素決定的。

只要磁盤空間充足，時(shí)間充足，就可以完成導(dǎo)出操作。導(dǎo)入則相對(duì)簡(jiǎn)單，沒(méi)有額外需求，按照正常的數(shù)據(jù)庫(kù)部署思路即可。

因?yàn)?taosdump 本身的產(chǎn)品特征決定了在上述特殊情況下，遷移數(shù)據(jù)會(huì)有效率問(wèn)題，因此這也是我們開(kāi)發(fā)專業(yè)的企業(yè)版數(shù)據(jù)遷移工具 taosX 的原因之一。

遷移操作

導(dǎo)出方：

對(duì)于 2.0 一側(cè)，首先要準(zhǔn)備好最新版本的 TDengine 和 taosdump 工具，具體操作如下：

1. 把數(shù)據(jù)庫(kù)升級(jí)到 2.6.0.34，升級(jí)注意事項(xiàng)以及操作步驟都可以參考這篇文章：http://m.fjzmyy.cn/engineering/10222.html。（注意：RPM 和 Deb 包不含 taosdump ，它需要通過(guò)安裝 taosTools 包獲得。所以建議大家直接使用包含 TDengine 的 Tar 包完成升級(jí)。）TDengine 安裝包需從 2.6 版本的文檔去下載：http://m.fjzmyy.cn/all-downloads 。如果使用了 RPM 和 Deb 的話，同樣需要通過(guò)上述鏈接下載最新版的 taostool 獲取 taosdump工具（當(dāng)前最新版為 2.4.5）。
2. 使用 taosdump 把數(shù)據(jù)導(dǎo)出：具體操作可參考：https://docs.taosdata.com/2.6/reference/taosdump/。舉例：

taosdump -o /test  -D test  -T 4

這條命令會(huì)把 test 庫(kù)的數(shù)據(jù)，用 4 個(gè)線程導(dǎo)出到 /test 目錄下面，文件形式如下：

接下來(lái)，我們需要把 test 路徑下的導(dǎo)出文件，遷移到 3.0 的環(huán)境中，準(zhǔn)備數(shù)據(jù)導(dǎo)入。

導(dǎo)入方：

1. 3.0 這一側(cè)，新環(huán)境我們建議使用最新版，各方面都更好（當(dāng)前最新版為 3.0.4.1），正常安裝部署即可。（同樣：RPM 和 Deb 包不含 taosdump ，它需要通過(guò)安裝 taosTools 包獲得。 所以建議大家直接使用包含 taosdump 的 tar 包完成部署，下載鏈接：https://docs.taosdata.com/releases/tdengine/）但是如果只能使用 RPM 或者 Deb ，taosTools 則需要從 3.0 的文檔單獨(dú)下載，地址：https://docs.taosdata.com/releases/tools/ （當(dāng)前最新版為 2.5.0）
   
2. 導(dǎo)入之前，我們首先要進(jìn)入導(dǎo)出文件目錄下的標(biāo)紅目錄，打開(kāi)里面的 dbs.sql，針對(duì)建庫(kù) SQL 做一些針對(duì)性的調(diào)整。尤其需要注意的是 VGROUPS 參數(shù)，這是 3.0 的新增參數(shù)，代替了此前 2.0 的一系列建表邏輯，默認(rèn)是 2 ，代表著這個(gè)庫(kù)有 2 個(gè) VGROUP 。如果原本的 2.0 環(huán)境使用了 4 個(gè) VGROUP，那么就需要手動(dòng)添加 “VGROUPS 4” 到建庫(kù)語(yǔ)句后面，即可保持和 2.0 版本一樣的 VGROUP 數(shù)量了。（其他參數(shù)同理，直接在建庫(kù) SQL 后添加即可，至于該語(yǔ)句中 2.0 時(shí)代的舊參數(shù)則會(huì)被導(dǎo)入程序自動(dòng)屏蔽掉。具體的 3.0 建庫(kù)參數(shù)細(xì)節(jié)可參考：https://docs.taosdata.com/taos-sql/database/）

示例：

原本的建庫(kù)語(yǔ)句：

CREATE DATABASE IF NOT EXISTS test REPLICA 1  QUORUM 1 DAYS 10 KEEP 3650 CACHE 16 BLOCKS 6 FSYNC 3000  PRECISION 'ms'  MINROWS 100 MAXROWS 4096 COMP 2 ;

添加參數(shù)后：

CREATE DATABASE IF NOT EXISTS test REPLICA 1  QUORUM 1 DAYS 10 KEEP 3650 CACHE 16 BLOCKS 6 FSYNC 3000  PRECISION 'ms'  MINROWS 100 MAXROWS 4096 COMP 2 VGROUPS 4;

修改完 dbs.sql 后，便可以執(zhí)行導(dǎo)入操作了，導(dǎo)入操作本身是比較簡(jiǎn)單的，具體操作可參考：https://docs.taosdata.com/2.6/reference/taosdump/。舉例：

這條命令會(huì)把 /test 目錄下的數(shù)據(jù)，用 4 個(gè)線程導(dǎo)入到當(dāng)前環(huán)境下面，地址默認(rèn)為 localhost，線程數(shù)可根據(jù)機(jī)器配置酌情設(shè)置。

導(dǎo)入完畢之后檢驗(yàn)數(shù)據(jù)內(nèi)容，確認(rèn)無(wú)誤之后，開(kāi)源版 TDengine 2.0 至 3.0 數(shù)據(jù)遷移便完成了。

如果上述兩種遷移方案都不能幫助我們完成數(shù)據(jù)遷移，歡迎聯(lián)系 TDengine 企業(yè)版團(tuán)隊(duì)做定制化的支持服務(wù)。

為確保結(jié)果具有可比性，本次測(cè)試選用 TimescaleDB 2.6.0 版本。為獲得較好的性能，TimescaleDB 需要針對(duì)不同的場(chǎng)景設(shè)置不同的 Chunk 參數(shù)，不同場(chǎng)景下參數(shù)的設(shè)置如下表所示：

上述參數(shù)的設(shè)置，充分參考了下方 TimescaleDB vs. InfluxDB 對(duì)比報(bào)告中推薦的配置參數(shù)設(shè)置，以確保寫入性能指標(biāo)的最優(yōu)化。

TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data：https://www.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/

關(guān)于系統(tǒng)的配置詳情、如何一鍵復(fù)現(xiàn)測(cè)試結(jié)果及詳細(xì)的測(cè)試數(shù)據(jù)介紹等內(nèi)容，大家可參考《一鍵獲取測(cè)試腳本，輕松驗(yàn)證“TSBS 時(shí)序數(shù)據(jù)庫(kù)性能基準(zhǔn)測(cè)試報(bào)告”》、《TSBS 是什么？為什么時(shí)序數(shù)據(jù)庫(kù) TDengine 會(huì)選擇它作為性能對(duì)比測(cè)試平臺(tái)？》兩篇文章，本文便不再贅述。

寫入性能最高達(dá)到了 TimescaleDB 的 6.7 倍

在 TSBS 全部的 cpu-only 五個(gè)場(chǎng)景中，TDengine 寫入性能均優(yōu)于 TimescaleDB。相比 TimescaleDB，TDengine 寫入速度最領(lǐng)先的場(chǎng)景是其 6.7 倍（場(chǎng)景二），最少也是 1.5 倍（場(chǎng)景五），而且對(duì)于場(chǎng)景四，如果將每個(gè)采集點(diǎn)的記錄條數(shù)由 18 條增加到 576 條，TDengine 寫入速度就達(dá)到了 TimescaleDB 的 13.2 倍。此外，TDengine 在寫入過(guò)程中消耗的 CPU 資源和磁盤 IO 開(kāi)銷也是最低的。

不同場(chǎng)景下寫入性能對(duì)比

從上圖可以看到，在全部五個(gè)場(chǎng)景中，TDengine 的寫入性能全面超越 TimescaleDB。在場(chǎng)景二中 TDengine 寫入性能最大達(dá)到了 TimescaleDB 的 6.74 倍，在差距最小的場(chǎng)景五中，也達(dá)到了 TimescaleDB 的 1.52 倍。

寫入過(guò)程資源消耗對(duì)比

但僅憑數(shù)據(jù)寫入速度，并不能全面地反映出 TDengine 和 TimescaleDB 在不同場(chǎng)景下數(shù)據(jù)寫入的整體表現(xiàn)。為此我們以 1,000,000 devices × 10 metrics （場(chǎng)景四）為例，檢查數(shù)據(jù)寫入過(guò)程中的服務(wù)器和客戶端的整體負(fù)載狀況，并以此來(lái)對(duì)比 TDengine 和 TimescaleDB 在寫入過(guò)程中服務(wù)器/客戶端節(jié)點(diǎn)的資源占用情況，這里的資源占用主要包括服務(wù)器端的 CPU 開(kāi)銷/磁盤 IO 開(kāi)銷和客戶端 CPU 開(kāi)銷。

服務(wù)端 CPU 開(kāi)銷

上圖展示了在場(chǎng)景四寫入過(guò)程之中服務(wù)器端 CPU 負(fù)載狀況?？梢钥吹剑琓Dengine 和 TimescaleDB 在返回給客戶端寫入完成消息以后，都還繼續(xù)使用服務(wù)器的資源進(jìn)行相應(yīng)的處理工作，這點(diǎn)上，TimescaleDB 尤為明顯，TimescaleDB 在 7x 秒的時(shí)候即反饋客戶端寫入完成，但是其服務(wù)器端仍然在調(diào)用 CPU 資源進(jìn)行數(shù)據(jù)壓縮和整理工作，當(dāng)然整個(gè)工作帶來(lái)的 CPU 負(fù)載相對(duì)而言并不高，只有其峰值 CPU 開(kāi)銷的一半左右，但是其持續(xù)時(shí)間相當(dāng)長(zhǎng)，接近凈寫入時(shí)間的 4 倍，遠(yuǎn)長(zhǎng)于 TDengine。TDengine 對(duì)服務(wù)器的 CPU 需求較小，峰值也僅使用了 17% 左右的服務(wù)器 CPU 資源。由此可見(jiàn)，TDengine 獨(dú)特的數(shù)據(jù)模型不僅體現(xiàn)在時(shí)序數(shù)據(jù)的寫入性能上，也體現(xiàn)在整體的資源開(kāi)銷上。

磁盤 I/O 對(duì)比

上圖展示了 1,000,000 devices × 10 metrics （場(chǎng)景四）兩大系統(tǒng)在數(shù)據(jù)寫入過(guò)程中服務(wù)器端磁盤寫入狀態(tài)。結(jié)合服務(wù)器端 CPU 開(kāi)銷表現(xiàn)，可以看到，兩大數(shù)據(jù)庫(kù)的 IO 動(dòng)作與 CPU 均呈現(xiàn)出同步活躍狀態(tài)。

在寫入相同規(guī)模數(shù)據(jù)集的情況下，TDengine 在寫入過(guò)程中對(duì)于磁盤寫入能力的占用遠(yuǎn)小于 TimescaleDB，整體寫入過(guò)程只占用了部分磁盤寫入能力（125MiB/Sec. 3000IOPS）。從圖上能看到，對(duì)于兩大數(shù)據(jù)庫(kù)來(lái)說(shuō)，數(shù)據(jù)寫入過(guò)程中磁盤的 IO 瓶頸是確實(shí)存在的，但 TimescaleDB 寫入過(guò)程對(duì)于寫入的消耗遠(yuǎn)超過(guò)了 TDengine 對(duì)磁盤寫入能力的需求。

客戶端 CPU 開(kāi)銷

從上圖可以看到，客戶端上 TDengine 對(duì) CPU 的需求大于 TimescaleDB ，TDengine 在客戶端峰值瞬間達(dá)到了 56%，然后快速回落，其在客戶端的開(kāi)銷相比于 TimescaleDB 多了 1 倍。但綜合服務(wù)器與客戶端的資源開(kāi)銷來(lái)看，TDengine 寫入持續(xù)時(shí)間更短，在系統(tǒng)整體 CPU 開(kāi)銷上 TDengine 仍然具有相當(dāng)大的優(yōu)勢(shì)。

查詢性能最高達(dá)到了 TimescaleDB 的 28.6 倍

在場(chǎng)景一（只包含 4 天數(shù)據(jù)）與場(chǎng)景二的 15 個(gè)不同類型的查詢中，TDengine 的查詢平均響應(yīng)時(shí)間全面優(yōu)于 TimescaleDB，而且在復(fù)雜查詢上優(yōu)勢(shì)更為明顯，同時(shí)具有最小的計(jì)算資源開(kāi)銷。相比 TimeScaleDB，場(chǎng)景一中 TDengine 的查詢性能是其 1.1 ～ 28.6 倍，場(chǎng)景二中 TDengine 的查詢性能是其 1.2 ～ 24.6 倍。

在查詢性能評(píng)估部分，我們使用場(chǎng)景一和場(chǎng)景二作為基準(zhǔn)數(shù)據(jù)集。在查詢性能評(píng)估之前，對(duì)于 TimescaleDB，我們采用上文出現(xiàn)的 TimescaleDB vs. InfluxDB 對(duì)比報(bào)告中推薦配置，設(shè)置為 8 個(gè) Chunk ，以確保其充分發(fā)揮查詢性能。在整個(gè)查詢對(duì)比中，TDengine 數(shù)據(jù)庫(kù)的虛擬節(jié)點(diǎn)數(shù)量（vnodes）保持為默認(rèn)的 6 個(gè)，其他的數(shù)據(jù)庫(kù)參數(shù)配置為默認(rèn)值。

4,000 devices × 10 metrics查詢性能對(duì)比

由于部分類型（分類標(biāo)準(zhǔn)參見(jiàn) TimescaleDB vs. InfluxDB 對(duì)比報(bào)告）單次查詢響應(yīng)時(shí)間非常短，為了更加準(zhǔn)確地測(cè)量每個(gè)查詢場(chǎng)景的較為穩(wěn)定的響應(yīng)時(shí)間，我們將單個(gè)查詢運(yùn)行次數(shù)提升到 5,000 次，然后使用 TSBS 自動(dòng)統(tǒng)計(jì)并輸出結(jié)果，最后結(jié)果是 5,000 次查詢的算數(shù)平均值，使用并發(fā)客戶端 Workers 數(shù)量為 8。下表是場(chǎng)景二 （4,000 設(shè)備）下兩大數(shù)據(jù)庫(kù)的查詢性能對(duì)比結(jié)果。

下面我們對(duì)每個(gè)查詢結(jié)果做一定的分析說(shuō)明：

由于 Simple Rollups 的整體查詢響應(yīng)時(shí)間非常短，因此制約查詢響應(yīng)時(shí)間的主體因素并不是查詢所涉及的數(shù)據(jù)規(guī)模，即這一類型查詢的瓶頸并非數(shù)據(jù)規(guī)模。但從結(jié)果上看，TDengine 仍然在所有類型的查詢響應(yīng)時(shí)間上優(yōu)于 TimescaleDB，具體的數(shù)值對(duì)比請(qǐng)參見(jiàn)上表。

通過(guò)上圖可以看到，在 Aggregates 類型的查詢中，TDengine 的查詢性能相比 TimescaleDB 有比較大的優(yōu)勢(shì)，其cpu-max-all-8 查詢性能是 TimescaleDB 的 6 倍。

在 Double-rollups 類型查詢中， TDengine 同樣展現(xiàn)出巨大的性能優(yōu)勢(shì)，以查詢響應(yīng)時(shí)間來(lái)度量，其在 double-groupby-5 和 double-groupby-all 類型下的查詢性能均達(dá)到了 TimescaleDB 的 24 倍。

上面兩圖展示的是 threshold 類型的查詢對(duì)比，可以看到，TDengine 的查詢響應(yīng)時(shí)間均顯著低于 TimescaleDB。在 high-cpu-all 類型的查詢上，TDengine 的性能是 TimescaleDB 的 1.23 倍。

對(duì)于 Complex-queries 類型的查詢，TDengine 兩個(gè)查詢同樣均大幅領(lǐng)先 TimescaleDB。在 lastpoint 查詢中TDengine 的查詢性能是 TimescaleDB 的 5 倍，在 groupby-orderby-limit 場(chǎng)景中 TDengine 的查詢性能是 TimescaleDB 的 8 倍。在時(shí)間窗口聚合的查詢過(guò)程中，針對(duì)規(guī)模較大的數(shù)據(jù)集 TimescaleDB 查詢性能不佳（double rollups 類型查詢），對(duì)于 groupby-orderby-limit 類型的查詢，TimescaleDB 的性能表現(xiàn)同樣不是太好。

資源開(kāi)銷對(duì)比

由于部分查詢持續(xù)時(shí)間特別短，因此我們并不能完整地看到查詢過(guò)程中服務(wù)器的 IO/CPU/網(wǎng)絡(luò)情況。為此我們針對(duì)場(chǎng)景二以 Double rollups 類別中的 double-groupby-5 查詢?yōu)槔?，?zhí)行 1,000 次查詢，記錄整個(gè)過(guò)程中 TDengine、TimescaleDB 兩個(gè)軟件系統(tǒng)在查詢執(zhí)行的整個(gè)過(guò)程中服務(wù)器 CPU、內(nèi)存、網(wǎng)絡(luò)的開(kāi)銷并進(jìn)行對(duì)比。

如上圖所示，兩個(gè)系統(tǒng)在整個(gè)查詢過(guò)程中 CPU 的使用均較為平穩(wěn)。TDengine 在查詢過(guò)程中整體 CPU 占用約 80%，使用的 CPU 資源最高，TimescaleDB 在查詢過(guò)程中瞬時(shí) CPU 占用約 38%。由于 TDengine 完成全部查詢的時(shí)間僅 TimescaleDB 1/20，因此雖然其 CPU 穩(wěn)定值是 TimescaleDB 的 2 倍多，但整體的 CPU 計(jì)算時(shí)間消耗只有其 1/10 。

• 服務(wù)器內(nèi)存狀況

如上圖所示，在整個(gè)查詢過(guò)程中，TDengine 內(nèi)存維持在一個(gè)相對(duì)平穩(wěn)的狀態(tài)。而 TimescaleDB 在整個(gè)查詢過(guò)程中內(nèi)存呈現(xiàn)增加的狀態(tài)，查詢完成后即恢復(fù)到初始狀態(tài)。

• 服務(wù)器網(wǎng)絡(luò)帶寬

上圖展示了查詢過(guò)程中兩個(gè)系統(tǒng)的服務(wù)器端上行和下行的網(wǎng)絡(luò)帶寬情況，可以看到，負(fù)載狀況基本上和 CPU 狀況相似。TDengine 網(wǎng)絡(luò)帶寬開(kāi)銷較高，因?yàn)樵谧疃痰臅r(shí)間內(nèi)就完成了全部查詢，需要將查詢結(jié)果返回給客戶端。TimescaleDB 開(kāi)銷較低，但持續(xù)時(shí)間長(zhǎng)。

100 devices × 10 metrics 查詢性能對(duì)比

對(duì)于場(chǎng)景一(100 devices x 10 metrics)，TSBS 的 15 個(gè)查詢對(duì)比結(jié)果如下：

如上表所示，從更小規(guī)模的數(shù)據(jù)集（100 設(shè)備）上的查詢對(duì)比可以看到，整體上 TDengine 同樣展現(xiàn)出極好的性能，在全部的查詢語(yǔ)句中全面優(yōu)于 TimescaleDB，部分查詢性能超過(guò) TimescaleDB 28 倍。

TimescaleDB 占用的磁盤空間最高達(dá)到 TDengine 的 26.9 倍

下圖是TDengine 和 TimescaleDB 數(shù)據(jù)完全落盤以后，比較了兩個(gè)系統(tǒng)在不同場(chǎng)景下的磁盤空間占用：

在磁盤空間的占用上，從上圖可以看到，TimescaleDB 在全部五個(gè)場(chǎng)景下的數(shù)據(jù)規(guī)模均顯著大于 TDengine，并且這種差距隨著數(shù)據(jù)規(guī)模增加快速變大。TimescaleDB 在場(chǎng)景四和場(chǎng)景五中占用磁盤空間是 TDengine 的 25.6 倍和 26.9 倍。

寫在最后

從上述 TSBS 測(cè)試報(bào)告中我們可以得出結(jié)論，不管是在寫入性能、查詢性能還是存儲(chǔ)性能，TDengine 時(shí)序數(shù)據(jù)庫(kù) 比 TimescaleDB 時(shí)序數(shù)據(jù)庫(kù) 都略勝一籌，且不論是服務(wù)器的 CPU 還是 IO 抑或是客戶端的開(kāi)銷統(tǒng)計(jì)，TDengine 均遠(yuǎn)優(yōu)于 TimescaleDB。尤其本次性能測(cè)試還是基于 Timescale 打造的基準(zhǔn)性能測(cè)試平臺(tái) TSBS 進(jìn)行的，測(cè)試結(jié)果的公平公正性可見(jiàn)一斑。

具體到實(shí)踐上，在八五信息的新能源電力物聯(lián)網(wǎng)平臺(tái)項(xiàng)目，曾經(jīng)使用的實(shí)時(shí)數(shù)據(jù)庫(kù)便是 TimescaleDB，后面因?yàn)榉N種原因，他們選擇應(yīng)用 TDengine 升級(jí)數(shù)據(jù)架構(gòu)，關(guān)于本次案例的具體信息可以查看《代替 TimescaleDB，TDengine 接管數(shù)據(jù)量日增 40 億條的光伏日電系統(tǒng)》。

為了方便大家驗(yàn)證測(cè)試結(jié)果，本測(cè)試報(bào)告支持運(yùn)行測(cè)試腳本一鍵復(fù)現(xiàn)，歡迎各位檢驗(yàn)。同時(shí)，我們也歡迎大家添加 小T vx：tdengine1，加入 TDengine 用戶交流群，和更多志同道合的開(kāi)發(fā)者一起探討數(shù)據(jù)處理難題。

3.0.4.0 版本涉及到的更新內(nèi)容包括產(chǎn)品穩(wěn)定性的提升、查詢性能提升、參數(shù)使用優(yōu)化、以及多副本情況下的健壯性提升、Python UDF、集群負(fù)載再平衡、基于時(shí)間段進(jìn)行數(shù)據(jù)重整等九大方面。具體更新信息如下：

1. 大幅提升產(chǎn)品穩(wěn)定性

在大并發(fā)、高負(fù)載的寫入和查詢下的系統(tǒng)穩(wěn)定性有顯著提升：優(yōu)化了對(duì)內(nèi)存的使用，優(yōu)化了有大量并發(fā)查詢下對(duì)連接池的控制，修復(fù)了一些影響系統(tǒng)穩(wěn)定性的缺陷。

2. 提升了部分查詢場(chǎng)景下的性能

• 提升了當(dāng)與 interval() 一起使用時(shí) mode() 函數(shù)的性能
• 提升了 percentile() 函數(shù)的性能
• 提升了 last()/last_row() 函數(shù)的性能

3. 可以動(dòng)態(tài)配置更多數(shù)據(jù)庫(kù)參數(shù)

新增兩個(gè)可以動(dòng)態(tài)配置的數(shù)據(jù)庫(kù)參數(shù)：stt_trigger 和 minRows，其具體功能請(qǐng)參考官方文檔。

4. 優(yōu)化了 WAL 數(shù)據(jù)保留的行為

WAL 中數(shù)據(jù)的保存僅受參數(shù) WAL_RETENTION_PERIOD 和 WAL_RETENTION_SIZE 的控制，不再受數(shù)據(jù)訂閱的影響。具體細(xì)節(jié)請(qǐng)參考官方文檔。

5. Python UDF

應(yīng)用開(kāi)發(fā)者可以用 Python 開(kāi)發(fā)自定義函數(shù)并將其嵌入數(shù)據(jù)庫(kù)，從而提升數(shù)據(jù)處理和分析能力。

6. 集群負(fù)載再平衡 （企業(yè)版功能）

當(dāng)集群中某個(gè) dnode 宕機(jī)重啟后會(huì)出現(xiàn)負(fù)載不均衡現(xiàn)象，重新啟動(dòng)的 dnode 上沒(méi)有 leader vnode，所以不承擔(dān)任何寫入和查詢負(fù)載。通過(guò) rebalance 命令，可以使集群中各個(gè) dnode 之間的負(fù)載再次均衡。

7. 基于時(shí)間段進(jìn)行數(shù)據(jù)重整 （企業(yè)版功能）

為了減少數(shù)據(jù)重整所花費(fèi)的時(shí)間，最小化對(duì)系統(tǒng)的影響，可以指定時(shí)間段進(jìn)行數(shù)據(jù)重整，只針對(duì)確定有亂序數(shù)據(jù)的時(shí)間段或者查詢所關(guān)注的時(shí)間段進(jìn)行數(shù)據(jù)重整。

8. 能夠?qū)⒍喾N工業(yè)互聯(lián)網(wǎng)中的傳統(tǒng)數(shù)據(jù)源接入TDengine （企業(yè)版功能）

• OPC UA
• OPC DA
• Pi

9. 集中控制臺(tái) taosExplorer 管理數(shù)據(jù)源和數(shù)據(jù)接入任務(wù) （企業(yè)版功能）

同步增強(qiáng)了集中控制臺(tái) taosExplorer 以能夠管理所支持的各種數(shù)據(jù)源和與它們所關(guān)聯(lián)的數(shù)據(jù)接入任務(wù)。

詳細(xì)信息可以參考發(fā)布說(shuō)明(https://github.com/taosdata/TDengine/releases/tag/ver-3.0.4.0)。歡迎大家下載使用 TDengine，有任何問(wèn)題，都可以添加小T vx：tdengine1 申請(qǐng)加入 TDengine 用戶交流群，及時(shí)向我們的解決方案專家尋求支持與幫助。

近日，TDengine 與 Apache SeaTunnel 展開(kāi)集成合作，雙方將于 4 月 18 日 19:00 聯(lián)合進(jìn)行直播，分享兩大軟件集成應(yīng)用的最佳實(shí)踐。

（Apache Seatunnel 是一個(gè)易用、高性能、支持實(shí)時(shí)流式和離線批處理的海量數(shù)據(jù)處理產(chǎn)品，架構(gòu)于Apache Spark 和 Apache Flink之上。）

此前，TDengine 已經(jīng)與 Kafka、Telegraf、Grafana、Google Data Studio、EMQ X、Prometheus、StatsD 和 collectd 等眾多第三方工具展開(kāi)集成，之后又連接了工業(yè)英特爾? 邊緣洞見(jiàn)軟件包、數(shù)據(jù)同步工具 DataX，插件也正式上架 Grafana 官網(wǎng)、連接器上線 Google Data Studio 應(yīng)用商店。此次 TDengine 與 Apache SeaTunnel 展開(kāi)集成合作，進(jìn)一步擴(kuò)大了自身生態(tài)版圖，為用戶帶來(lái)應(yīng)用上的更多選擇。

兩者聯(lián)合將帶來(lái)怎樣的驚喜，歡迎大家關(guān)注4 月 18日即將到來(lái)的線上直播！趕快點(diǎn)擊下方直播卡片預(yù)約觀看吧~

報(bào)名通道

講師介紹

李宏宇 北京沃東天駿信息技術(shù)有限公司 架構(gòu)師

歷經(jīng)阿里、京東等多家成熟互聯(lián)網(wǎng)公司及羅輯思維等初創(chuàng)公司。十年后端及數(shù)據(jù)開(kāi)發(fā)經(jīng)驗(yàn)，目前主要聚焦在實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)領(lǐng)域工作

霍立波 北京濤思數(shù)據(jù)科技有限公司 連接器開(kāi)發(fā)工程師

熟悉 Java、GO、rust、node 等多種開(kāi)發(fā)語(yǔ)言，對(duì)使用的各個(gè)框架與工具底層實(shí)現(xiàn)有深入理解。目前主要圍繞 TDengine 做生態(tài)開(kāi)發(fā)。

活動(dòng)議程

按照慣例，直播中我們?yōu)榇蠹覝?zhǔn)備了抽獎(jiǎng)環(huán)節(jié)，中獎(jiǎng)?wù)呖色@得社區(qū)提供的精美周邊禮品，來(lái)到直播間就有機(jī)會(huì)中獎(jiǎng)~此外，填寫活動(dòng)反饋表也能獲得抽獎(jiǎng)機(jī)會(huì)哦：http://whaleops.mikecrm.com/1pxlyDU！

獎(jiǎng)品一覽

社區(qū)介紹

Apache SeaTunnel (Incubating)

Apache SeaTunnel (Incubating) 是一個(gè)云原生的高性能海量數(shù)據(jù)集成平臺(tái)。美國(guó)時(shí)間 2021 年 12 月 9 日， SeaTunnel以全票通過(guò)的優(yōu)秀表現(xiàn)正式成為 Apache 孵化器項(xiàng)目，這也是 Apache 基金會(huì)中第一個(gè)誕生自中國(guó)的數(shù)據(jù)集成平臺(tái)項(xiàng)目。目前，SeaTunnel 在GitHub 上Star 數(shù)達(dá) 4.1k+，社區(qū)達(dá)到5000+人規(guī)模。2017 年對(duì)外開(kāi)源后，SeaTunnel 已經(jīng)發(fā)布了 30多個(gè)版本，并經(jīng)過(guò)大量企業(yè)生產(chǎn)使用，在 Bilibili、新浪、水滴籌、搜狗、趣頭條、唯品會(huì)等公司的生產(chǎn)實(shí)踐中，廣泛應(yīng)用于海量數(shù)據(jù)集成、數(shù)據(jù) ETL、數(shù)據(jù)聚合以及多源數(shù)據(jù)處理等場(chǎng)景中，貢獻(xiàn)者 160+。

TDengine

TDengine 是一款開(kāi)源、云原生的時(shí)序數(shù)據(jù)庫(kù)（ Time Series Database,TSDB ），專為物聯(lián)網(wǎng)、工業(yè)互聯(lián)網(wǎng)、金融、IT 運(yùn)維監(jiān)控等場(chǎng)景設(shè)計(jì)并優(yōu)化，具有極強(qiáng)的彈性伸縮能力。同時(shí)它還帶有內(nèi)建的緩存、流式計(jì)算、數(shù)據(jù)訂閱等系統(tǒng)功能，能大幅減少系統(tǒng)設(shè)計(jì)的復(fù)雜度，降低研發(fā)和運(yùn)營(yíng)成本，是一個(gè)極簡(jiǎn)的時(shí)序數(shù)據(jù)處理平臺(tái)。TDengine 的內(nèi)核（存儲(chǔ)、計(jì)算引擎和集群）已 100% 開(kāi)源，GitHub Star數(shù)達(dá)到 21.1k，且多次在 GitHub 全球趨勢(shì)排行榜上排名第一（開(kāi)源地址：https://github.com/taosdata/TDengine）。目前，TDengine 的運(yùn)行實(shí)例數(shù)已超過(guò) 230.6k，用戶遍布全球。

我們采用下方 TimescaleDB vs. InfluxDB 對(duì)比報(bào)告中推薦的方式配置 InfluxDB，將緩沖區(qū)配置為 80G，以便 1000W 設(shè)備寫入時(shí)能夠順利進(jìn)行，同時(shí)開(kāi)啟 Time Series Index（TSI）。配置系統(tǒng)在系統(tǒng)插入數(shù)據(jù)完成 30s 后開(kāi)始數(shù)據(jù)壓縮。

TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data：

https://www.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/

關(guān)于系統(tǒng)的配置詳情、如何一鍵復(fù)現(xiàn)測(cè)試結(jié)果及詳細(xì)的測(cè)試數(shù)據(jù)介紹等內(nèi)容，大家可參考《一鍵獲取測(cè)試腳本，輕松驗(yàn)證“TSBS 時(shí)序數(shù)據(jù)庫(kù)性能基準(zhǔn)測(cè)試報(bào)告”》、《TSBS 是什么？為什么時(shí)序數(shù)據(jù)庫(kù) TDengine 會(huì)選擇它作為性能對(duì)比測(cè)試平臺(tái)？》兩篇文章，本文便不再贅述。

寫入性能最高達(dá)到 InfluxDB 的 10.6 倍

總體而言，在 TSBS 報(bào)告全部的 cpu-only 五個(gè)場(chǎng)景中，時(shí)序數(shù)據(jù)庫(kù)（Time Series Database,TSDB）TDengine 寫入性能均優(yōu)于 InfluxDB。相比 InfluxDB，TDengine 寫入速度最領(lǐng)先的場(chǎng)景是其 10.6 倍（場(chǎng)景五），最少也是 3.0 倍（場(chǎng)景一)。此外，TDengine 在寫入過(guò)程中消耗了最少 CPU 資源和磁盤 IO 開(kāi)銷。下面看一下具體分析：

不同場(chǎng)景下寫入性能對(duì)比

從上圖可以看到，在全部五個(gè)場(chǎng)景中，TDengine 的寫入性能全面超越 InfluxDB。TDengine 在場(chǎng)景五中寫入性能是 InfluxDB 的 10.63 倍，在差距最小的場(chǎng)景一中也有 3.01 倍。

寫入過(guò)程資源消耗對(duì)比

數(shù)據(jù)寫入速度并不能夠全面的反映 TDengine 和 InfluxDB 在不同場(chǎng)景下數(shù)據(jù)寫入的整體表現(xiàn)。為此我們以 1,000,000 devices × 10 metrics （場(chǎng)景四）為例，檢查數(shù)據(jù)寫入過(guò)程中的服務(wù)器和客戶端（包括客戶端與服務(wù)器）的整體負(fù)載狀況，并以此來(lái)對(duì)比 TDengine 和 InfluxDB 在寫入過(guò)程中服務(wù)器/客戶端節(jié)點(diǎn)的資源占用情況，這里的資源占用主要包括服務(wù)器端的 CPU 開(kāi)銷/磁盤 IO 開(kāi)銷和客戶端 CPU 開(kāi)銷。

服務(wù)端 CPU 開(kāi)銷

下圖展示了兩大數(shù)據(jù)庫(kù)在場(chǎng)景四寫入過(guò)程中服務(wù)器端 CPU 負(fù)載狀況?？梢钥吹?，TDengine 和 InfluxDB 在返回給客戶端寫入完成消息以后，都還繼續(xù)使用服務(wù)器的資源進(jìn)行相應(yīng)的處理工作，InfluxDB 使用了相當(dāng)多的 CPU 資源，瞬時(shí)峰值甚至使用了全部的 CPU 資源，其寫入負(fù)載較高，并且其持續(xù)時(shí)間遠(yuǎn)長(zhǎng)于 TDengine。兩個(gè)系統(tǒng)對(duì)比，TDengine 對(duì)服務(wù)器的 CPU 需求最小，峰值也僅使用了 17% 左右的服務(wù)器 CPU 資源。由此可見(jiàn)，TDengine 獨(dú)特的數(shù)據(jù)模型對(duì)于時(shí)序數(shù)據(jù)寫入不僅在性能上，在整體的資源開(kāi)銷上也具有非常大的優(yōu)勢(shì)。

磁盤 I/O 對(duì)比

下圖展示了 1,000,000 devices × 10 metrics （場(chǎng)景四）數(shù)據(jù)寫入過(guò)程中兩大數(shù)據(jù)庫(kù)在服務(wù)器端磁盤的寫入狀態(tài)?？梢钥吹剑Y(jié)合著服務(wù)器端 CPU 開(kāi)銷表現(xiàn)，其 IO 動(dòng)作與 CPU 呈現(xiàn)同步的活躍狀態(tài)。

在寫入相同規(guī)模的數(shù)據(jù)集情況下，TDengine 在寫入過(guò)程中對(duì)于磁盤寫入能力的占用遠(yuǎn)小于 InfluxDB，寫入過(guò)程只占用了部分磁盤寫入能力（125MiB/Sec. 3000IOPS）。從上圖能看到，對(duì)于兩大數(shù)據(jù)庫(kù)，數(shù)據(jù)寫入過(guò)程中磁盤的 IO 瓶頸都是確實(shí)存在的。但 InfluxDB 長(zhǎng)時(shí)間消耗完全部的磁盤寫入能力，遠(yuǎn)遠(yuǎn)超過(guò)了 TDengine 對(duì)磁盤寫入能力的需求。

客戶端 CPU 開(kāi)銷

從上圖可以看到，客戶端上 TDengine 對(duì) CPU 的需求是大于 InfluxDB 的。整體來(lái)說(shuō)，在整個(gè)寫入過(guò)程中，InfluxDB 客戶端負(fù)載計(jì)算資源占用較低，對(duì)客戶端壓力小，這是因?yàn)槠鋵懭氲膲毫旧贤耆性诜?wù)端，但這種模式很容易導(dǎo)致服務(wù)端成為瓶頸。而 TDengine 在客戶端的開(kāi)銷最大，峰值瞬間達(dá)到了 56%，然后快速回落。綜合服務(wù)器與客戶端的資源開(kāi)銷來(lái)看，TDengine 寫入持續(xù)時(shí)間更短，在系統(tǒng)整體 CPU 開(kāi)銷上 TDengine 仍然具有相當(dāng)大的優(yōu)勢(shì)。

查詢性能最高達(dá)到 InfluxDB 的 37 倍

在查詢性能的評(píng)估上，我們使用場(chǎng)景一和場(chǎng)景二作為基準(zhǔn)數(shù)據(jù)集。為了讓 InfluxDB 發(fā)揮出更好的查詢性能，我們開(kāi)啟 InfluxDB 的 TSI (time series index)。在整個(gè)查詢對(duì)比中，TDengine 數(shù)據(jù)庫(kù)的虛擬節(jié)點(diǎn)數(shù)量（vnodes）保持為默認(rèn)的 6 個(gè)，其他的數(shù)據(jù)庫(kù)參數(shù)配置為默認(rèn)值。

總體來(lái)說(shuō)，查詢方面，在場(chǎng)景一（只包含 4 天的數(shù)據(jù)）與場(chǎng)景二的 15 個(gè)不同類型的查詢中，TDengine 的查詢平均響應(yīng)時(shí)間是全面優(yōu)于 InfluxDB 的，而且在復(fù)雜查詢上優(yōu)勢(shì)更為明顯，同時(shí)具有最小的計(jì)算資源開(kāi)銷。相比 InfluxDB，場(chǎng)景一中 TDengine 查詢性能是其 1.9 ～ 37.0 倍，場(chǎng)景二中 TDengine 查詢性能是其 1.8 ～ 34.2 倍。

4,000 devices × 10 metrics查詢性能對(duì)比

由于部分類型（分類標(biāo)準(zhǔn)參見(jiàn) TimescaleDB vs. InfluxDB 對(duì)比報(bào)告）單次查詢響應(yīng)時(shí)間非常短，為了更加準(zhǔn)確地測(cè)量每個(gè)查詢場(chǎng)景的較為穩(wěn)定的響應(yīng)時(shí)間，我們將單個(gè)查詢運(yùn)行次數(shù)提升到 5,000 次，然后使用 TSBS 自動(dòng)統(tǒng)計(jì)并輸出結(jié)果，最后結(jié)果是 5,000 次查詢的算數(shù)平均值，使用并發(fā)客戶端 Workers 數(shù)量為 8。首先我們提供場(chǎng)景二（4,000 設(shè)備）的查詢性能對(duì)比結(jié)果：

下面我們對(duì)每個(gè)查詢結(jié)果做一定的分析說(shuō)明：

由于 Simple Rollups 的整體查詢響應(yīng)時(shí)間非常短，制約查詢響應(yīng)時(shí)間主體因素并不是查詢涉及的數(shù)據(jù)規(guī)模，即這種類型查詢的瓶頸并不是數(shù)據(jù)規(guī)模。但是 TDengine 仍然在所有類型的查詢響應(yīng)時(shí)間上優(yōu)于 InfluxDB，具體的數(shù)值比較請(qǐng)參見(jiàn)上表中的詳細(xì)數(shù)據(jù)表格。

在 Aggregates 類型的查詢中，我們看到 TDengine 查詢性能相比于 InfluxDB 有較大優(yōu)勢(shì)，TDengine cpu-max-all-8 類型的查詢性能是 InfluxDB 的 7 倍。

在 Double-rollups 類型查詢中， TDengine 同樣展現(xiàn)出巨大的性能優(yōu)勢(shì)，以查詢響應(yīng)時(shí)間來(lái)度量，在 double-groupby-5 查詢上 TDengine 是 InfluxDB 的 26 倍，double-groupby-all 上是其 34 倍。

上面兩圖是 threshold 類型的查詢對(duì)比，TDengine 的查詢響應(yīng)時(shí)間均顯著低于 InfluxDB。在 high-cpu-all 類型的查詢上，TDengine 的性能是 InfluxDB 的 15 倍。

對(duì)于 Complex-queries 類型的查詢，TDengine 兩個(gè)查詢均大幅領(lǐng)先 InfluxDB。在 lastpoint 查詢中，查詢性能是 InfluxDB 的 21倍；在 groupby-orderby-limit 場(chǎng)景中查詢性能是 InfluxDB 的 15 倍。

資源開(kāi)銷對(duì)比

由于部分查詢持續(xù)時(shí)間特別短，因此我們并不能完整地看到查詢過(guò)程中服務(wù)器的 IO/CPU/網(wǎng)絡(luò)情況。為此我們針對(duì)場(chǎng)景二以 Double rollups 類別中的 double-groupby-5 查詢?yōu)槔?，?zhí)行 1,000 次查詢，記錄 TDengine 和 InfluxDB 在查詢執(zhí)行的整個(gè)過(guò)程中服務(wù)器 CPU、內(nèi)存、網(wǎng)絡(luò)的開(kāi)銷并進(jìn)行對(duì)比。

從上圖可以看到，TDengine 和 InfluxDB 在整個(gè)查詢過(guò)程中 CPU 的使用均較為平穩(wěn)。TDengine 在查詢過(guò)程中整體 CPU 占用約 80%，使用的 CPU 資源較高，InfluxDB 穩(wěn)定的 CPU 占用較小，約 27 %（但是有較多的瞬時(shí)沖高）。從整體 CPU 開(kāi)銷上來(lái)看，雖然 InfluxDB 瞬時(shí) CPU 開(kāi)銷大部分是較低的，但是其完成查詢持續(xù)時(shí)間最長(zhǎng)，所以整體 CPU 資源消耗最多。由于 TDengine 完成全部查詢的時(shí)間僅是 InfluxDB 的 1/20，雖然 CPU 穩(wěn)定值是 InfluxDB 的 2 倍多，但整體的 CPU 計(jì)算時(shí)間消耗只有其 1/10 。

服務(wù)器內(nèi)存狀況

如上圖所示，在整個(gè)查詢過(guò)程中，TDengine 與 InfluxDB 的內(nèi)存均維持在一個(gè)相對(duì)平穩(wěn)的狀態(tài)。

服務(wù)器網(wǎng)絡(luò)帶寬

上圖展示了查詢過(guò)程中服務(wù)器端上行和下行的網(wǎng)絡(luò)帶寬情況，負(fù)載狀況基本上和 CPU 狀況相似。TDengine 網(wǎng)絡(luò)帶寬開(kāi)銷最高，因?yàn)樵谧疃痰臅r(shí)間內(nèi)就完成了全部查詢，需要將查詢結(jié)果返回給客戶端。InfluxDB 網(wǎng)絡(luò)帶寬開(kāi)銷最低，持續(xù)時(shí)間也較長(zhǎng)。

3,100 devices × 10 metrics 查詢性能對(duì)比

對(duì)于場(chǎng)景一(100 devices x 10 metrics)，TSBS 的 15 個(gè)查詢對(duì)比結(jié)果如下：

如上表所示，在更小規(guī)模的數(shù)據(jù)集（100設(shè)備）上的查詢對(duì)比可以看到，整體上 TDengine 同樣展現(xiàn)出極好的性能，在全部的查詢語(yǔ)句中全面優(yōu)于 InfluxDB，部分查詢性能超過(guò) InfluxDB 37 倍。

InfluxDB 占用的磁盤空間最高達(dá)到 TDengine 的 4.5 倍

在前面三個(gè)場(chǎng)景中，InfluxDB 落盤后數(shù)據(jù)文件規(guī)模與 TDengine 非常接近，但是在大數(shù)據(jù)規(guī)模的場(chǎng)景四和場(chǎng)景五中，InfluxDB 落盤后文件占用的磁盤空間顯著超過(guò)了 TDengine。下圖比較了 TDengine 和 InfluxDB 在不同場(chǎng)景下的磁盤空間占用情況：

從上圖可以看到，在前面三個(gè)場(chǎng)景中，InfluxDB 落盤后數(shù)據(jù)文件規(guī)模與 TDengine 非常接近（在場(chǎng)景二中，TDengine 的數(shù)據(jù)落盤規(guī)模比 InfluxDB 大了 1%）。但是在場(chǎng)景四和場(chǎng)景五中，InfluxDB 落盤后文件占用的磁盤空間分別是 TDengine 的 4.2 倍和 4.5 倍。

寫在最后

基于本次測(cè)試報(bào)告，我們可以得出結(jié)論，在全部的數(shù)據(jù)場(chǎng)景中，TDengine 寫入性能、查詢性能均全面超過(guò) InfluxDB。在整個(gè)寫入過(guò)程中，TDengine 在提供更高寫入和查詢能力的前提下，不論是服務(wù)器的 CPU 還是 IO，TDengine 均優(yōu)于 InfluxDB。即使加上客戶端的開(kāi)銷統(tǒng)計(jì)，TDengine 在寫入開(kāi)銷上也在 InfluxDB 之下。

從實(shí)踐角度出發(fā)，這個(gè)報(bào)告結(jié)果也很好地說(shuō)明了為什么有很多企業(yè)客戶在 InfluxDB 和 TDengine 的選型調(diào)研中選擇了 TDengine，雙匯便是其中之一，在《雙匯大數(shù)據(jù)方案選型：從棘手的InfluxDB+Redis到毫秒級(jí)查詢的TDengine》這篇文章中，便闡述了其選型調(diào)研過(guò)程的具體思考。

為了方便大家驗(yàn)證測(cè)試結(jié)果，本測(cè)試報(bào)告支持運(yùn)行測(cè)試腳本一鍵復(fù)現(xiàn)，歡迎大家在評(píng)論區(qū)互動(dòng)交流。同時(shí)，你也可以添加 小T vx：tdengine1，加入 TDengine 用戶交流群，和更多志同道合的開(kāi)發(fā)者一起探討數(shù)據(jù)處理難題。

小 T 導(dǎo)讀：taosKeeper 是 TDengine 3.0 的運(yùn)行狀態(tài)指標(biāo)監(jiān)控工具，通過(guò)簡(jiǎn)單的幾項(xiàng)配置即可獲取 TDengine 的運(yùn)行狀態(tài)信息。其使用 TDengine RESTful 接口，所以不需要安裝 TDengine 客戶端即可使用。本文將詳細(xì)解讀 taosKeeper 的詳細(xì)語(yǔ)法規(guī)則，方便有需要的用戶開(kāi)展應(yīng)用。

時(shí)序數(shù)據(jù)庫(kù) TDengine（ Time Series Database,TSDB） 通過(guò) taosKeeper 將服務(wù)器的 CPU、內(nèi)存、硬盤空間、帶寬、請(qǐng)求數(shù)、磁盤讀寫速度等信息定時(shí)寫入指定實(shí)時(shí)數(shù)據(jù)庫(kù)，也支持對(duì)重要的系統(tǒng)操作（比如登錄、創(chuàng)建、刪除數(shù)據(jù)庫(kù)等）以及各種錯(cuò)誤報(bào)警信息進(jìn)行記錄。系統(tǒng)管理員可以從命令行直接查看該數(shù)據(jù)庫(kù)，也可以在 Web 端通過(guò)圖形化界面查看這些監(jiān)測(cè)信息。這些監(jiān)測(cè)信息的采集缺省是打開(kāi)的，也可以通過(guò)修改配置文件里的選項(xiàng) monitor 來(lái)關(guān)閉。

taosKeeper 安裝方式：?jiǎn)为?dú)編譯 taosKeeper 并安裝，詳情請(qǐng)參考 taosKeeper 倉(cāng)庫(kù)（https://github.com/taosdata/taoskeeper）。

配置和運(yùn)行方式

taosKeeper 需要在操作系統(tǒng)終端中執(zhí)行，該工具支持三種配置方式：命令行參數(shù)、環(huán)境變量和配置文件。優(yōu)先級(jí)為：命令行參數(shù)、環(huán)境變量、配置文件參數(shù)。

需要注意的是，在運(yùn)行 taosKeeper 之前要確保 TDengine 集群與 taosAdapter 已經(jīng)正確運(yùn)行，并且 TDengine 已經(jīng)開(kāi)啟監(jiān)控服務(wù)。監(jiān)控配置可參考相關(guān)文檔，具體的配置項(xiàng)包括 monitor、monitorFqdn、monitorPort、monitorInterval 和 telemetryReporting。

命令行參數(shù)啟動(dòng)

可以直接執(zhí)行 taosKeeper，也可以在執(zhí)行命令時(shí)提供命令行參數(shù)。

$ taosKeeper

環(huán)境變量啟動(dòng)

通過(guò)設(shè)置環(huán)境變量達(dá)到控制啟動(dòng)參數(shù)的目的，通常在容器中運(yùn)行時(shí)使用。

$ export TAOS_KEEPER_TDENGINE_HOST=192.168.64.3
$ taoskeeper

具體參數(shù)列表請(qǐng)參照 taoskeeper -h 輸入結(jié)果。

配置文件啟動(dòng)

執(zhí)行以下命令即可快速體驗(yàn) taosKeeper。當(dāng)不指定 taosKeeper 配置文件時(shí)，優(yōu)先使用 /etc/taos/keeper.toml 配置，否則將使用默認(rèn)配置。

$ taoskeeper -c <keeper config file>

具體配置文件示例請(qǐng)參考：https://docs.taosdata.com/reference/taosKeeper/

獲取監(jiān)控指標(biāo)

taosKeeper 作為 TDengine 監(jiān)控指標(biāo)的導(dǎo)出工具，可以將 TDengine 產(chǎn)生的監(jiān)控?cái)?shù)據(jù)記錄在指定數(shù)據(jù)庫(kù)中，并提供導(dǎo)出接口。

查看監(jiān)控結(jié)果集

$ taos
# 如上示例，使用 log 庫(kù)作為監(jiān)控日志存儲(chǔ)位置
> use log;
> select * from cluster_info limit 1;

結(jié)果示例：

           ts            |            first_ep            | first_ep_dnode_id |   version    |    master_uptime     | monitor_interval |  dbs_total  |  tbs_total  | stbs_total  | dnodes_total | dnodes_alive | mnodes_total | mnodes_alive | vgroups_total | vgroups_alive | vnodes_total | vnodes_alive | connections_total |  protocol   |           cluster_id           |
===============================================================================================================================================================================================================================================================================================================================================================================
 2022-08-16 17:37:01.629 | hlb:6030                       |                 1 | 3.0.0.0      |              0.27250 |               15 |           2 |          27 |          38 |            1 |            1 |            1 |            1 |             4 |             4 |            4 |            4 |                14 |           1 | 5981392874047724755            |
Query OK, 1 rows in database (0.036162s)

導(dǎo)出監(jiān)控指標(biāo)

$ curl http://127.0.0.1:6043/metrics

部分結(jié)果集：

# HELP taos_cluster_info_connections_total 
# TYPE taos_cluster_info_connections_total counter
taos_cluster_info_connections_total{cluster_id="5981392874047724755"} 16
# HELP taos_cluster_info_dbs_total 
# TYPE taos_cluster_info_dbs_total counter
taos_cluster_info_dbs_total{cluster_id="5981392874047724755"} 2
# HELP taos_cluster_info_dnodes_alive 
# TYPE taos_cluster_info_dnodes_alive counter
taos_cluster_info_dnodes_alive{cluster_id="5981392874047724755"} 1
# HELP taos_cluster_info_dnodes_total 
# TYPE taos_cluster_info_dnodes_total counter
taos_cluster_info_dnodes_total{cluster_id="5981392874047724755"} 1
# HELP taos_cluster_info_first_ep 
# TYPE taos_cluster_info_first_ep gauge
taos_cluster_info_first_ep{cluster_id="5981392874047724755",value="hlb:6030"} 1

TDinsight

除了 taosKeeper，TDengine 還提供了 TDinsight——使用監(jiān)控?cái)?shù)據(jù)庫(kù) + Grafana 對(duì) TDengine 進(jìn)行監(jiān)控的解決方案，下文將淺談一下 TDinsight 的前期部署和準(zhǔn)備。在部署時(shí)，我們首先需要下載自動(dòng)化腳本 TDinsight.sh：

wget https://github.com/taosdata/grafanaplugin/raw/master/dashboards/TDinsight.sh
chmod +x TDinsight.sh

準(zhǔn)備：

1. TDengine Server 信息：
   • TDengine RESTful 服務(wù)：使用參數(shù) -a指定。如果是運(yùn)行在同一主機(jī)，通常是 http://localhost:6041。
   • TDengine 用戶名和密碼，使用 -u-p 指定。
2. Grafana 告警通知
   • 使用已經(jīng)存在的 Grafana Notification Channel uid，參數(shù) -E。該參數(shù)可以使用 curl -u admin:admin localhost:3000/api/alert-notifications |jq 來(lái)獲取。JSON 解析工具 jq 可能需要單獨(dú)安裝。

sudo ./TDinsight.sh -a http://localhost:6041 -u root -p taosdata -E <notifier uid>

運(yùn)行程序并重啟 Grafana 服務(wù)，打開(kāi)面板：http://localhost:3000/d/tdinsight可以查看 TDengine 服務(wù)運(yùn)行狀態(tài)。

監(jiān)控?cái)?shù)據(jù)庫(kù)為用戶提供了更多的監(jiān)控項(xiàng)，與 taosKeeper 共同筑牢 TDengine 數(shù)據(jù)監(jiān)控的城墻。在下一篇文章中，我們將會(huì)詳解解說(shuō)如何使用 TDinsight 方案對(duì) TDengine 進(jìn)行監(jiān)控，敬請(qǐng)期待。

為幫助大家尋找解決上述問(wèn)題的最優(yōu)解，我們匯總了四家比較具有代表性的智慧城市升級(jí)項(xiàng)目的架構(gòu)改造案例，一起來(lái)看看他們都是如何做的。

SENSORO x TDengine

“我們進(jìn)行的數(shù)據(jù)庫(kù)調(diào)研測(cè)試結(jié)果顯示，TDengine (Time Series Database,TSDB) 的空間占用只有 Druid 的 60%（沒(méi)有計(jì)算 Druid 使用的 Deep Storage）。針對(duì)單一設(shè)備的查詢與聚和的響應(yīng)時(shí)間比 Druid 有倍數(shù)的提升，尤其時(shí)間跨度較久時(shí)差距更明顯（在十倍以上），同時(shí) Druid 的響應(yīng)時(shí)間方差也較大。在實(shí)際業(yè)務(wù)環(huán)境中，我們創(chuàng)建了多列的超級(jí)表，雖然會(huì)存在大量的空列，但得益于 TDengine 的優(yōu)化，能達(dá)到恐怖的 0.01 的壓縮率，簡(jiǎn)單計(jì)算下來(lái)大約需要 3.67GB 每?jī)|條?！?/p>

業(yè)務(wù)背景

SENSORO 面向城市基礎(chǔ)設(shè)施與核心要素提供全域數(shù)字化服務(wù)方案，建立城市級(jí)傳感器網(wǎng)絡(luò)所涉及的傳感器種類十分多樣，由此產(chǎn)生的數(shù)據(jù)量也十分龐大。在系統(tǒng)開(kāi)發(fā)初期，SENSORO 先是選擇了 Apache Druid 作為存儲(chǔ)傳感數(shù)據(jù)的實(shí)時(shí)數(shù)據(jù)庫(kù)，然而在使用過(guò)程中卻遇到了各種各樣的問(wèn)題，這使得其將目光轉(zhuǎn)移到了 TDengine 上，但因?yàn)槠脚_(tái)涉及的特殊數(shù)據(jù)模型，合作便一直擱置了下來(lái)。隨后 TDengine 經(jīng)過(guò)了多個(gè)版本迭代，支持了 join 查詢，而 SENSORO 的數(shù)據(jù)模型也發(fā)生了變化，遷移到 TDengine 時(shí)不再需要做出很多的系統(tǒng)模塊改動(dòng)，由此雙方的合作也開(kāi)始快速展開(kāi)。

架構(gòu)圖

北京智能建筑 x TDengine

“TDengine 幫助我們?cè)谶吘墏?cè)解決了一個(gè)很大的問(wèn)題，即邊緣存儲(chǔ)的問(wèn)題。因?yàn)楹芏鄷r(shí)候邊緣是布署在資源比較少的機(jī)器上面，甚至是 ARM 的工業(yè)盒子上面，在資源使用上非常的苛刻，而現(xiàn)在得益于 TDengine 超強(qiáng)的壓縮算法，我們使用非常小的存儲(chǔ)空間就存儲(chǔ)了幾千萬(wàn)數(shù)據(jù)，壓縮率遠(yuǎn)超 1/20，在單機(jī)上面布署一個(gè) TDengine 服務(wù)器就可以輕輕松松地存儲(chǔ)上億的數(shù)據(jù)。此外它還擁有超強(qiáng)的計(jì)算能力，占用的資源也非常小，在我們的業(yè)務(wù)中千萬(wàn)級(jí)數(shù)據(jù)檢索時(shí)間達(dá)到了毫秒級(jí)，從用戶角度來(lái)說(shuō)產(chǎn)品體驗(yàn)非常好?！?/p>

業(yè)務(wù)背景

北京智能建筑是北京市在智能建筑和智慧城市領(lǐng)域的創(chuàng)新平臺(tái)，同時(shí)也是冬奧科技平臺(tái)公司、智慧冬奧國(guó)家重點(diǎn)項(xiàng)目設(shè)計(jì)單位和核心實(shí)施單位。在邊緣側(cè)采集數(shù)據(jù)存儲(chǔ)方案中，其面臨著在有限的計(jì)算資源下，如何實(shí)現(xiàn)最高效的數(shù)據(jù)存儲(chǔ)、分析和計(jì)算的問(wèn)題。經(jīng)過(guò)調(diào)研與測(cè)試，其最終選擇根據(jù)業(yè)務(wù)需求靈活搭配使用 TDengine 與 SQLite——由 TDengine 處理時(shí)序數(shù)據(jù)，SQLite 處理關(guān)系數(shù)據(jù)，以此更好地實(shí)現(xiàn)邊緣側(cè)的數(shù)據(jù)自治。

架構(gòu)圖

交通數(shù)據(jù)資源管理系統(tǒng) x TDengine

“所有車輛最新位置信息的查詢是交通運(yùn)行監(jiān)控中的重中之重，最初‘使用何種查詢語(yǔ)句實(shí)現(xiàn)高效查詢’是非常困擾我們的一件事，后面在 TDengine 社區(qū)團(tuán)隊(duì)的幫助下，我們利用了隱藏字段名 tbname 和 group by 方法，高效地查詢了車輛的最新定位信息。在頻繁查詢的情況下，接近六萬(wàn)輛車的位置信息，只用了不到 1 秒的查詢時(shí)間，簡(jiǎn)單而又高效，完全符合我們的業(yè)務(wù)需求；在數(shù)據(jù)統(tǒng)計(jì)分析上，一個(gè) 64 天數(shù)據(jù)量的表，進(jìn)行每日數(shù)據(jù)條數(shù)的降維統(tǒng)計(jì)，所需時(shí)間也不到 1 秒。”

業(yè)務(wù)背景

為了強(qiáng)化全市交通運(yùn)輸管理、統(tǒng)籌綜合交通發(fā)展、提升交通運(yùn)行和管理效率，某市級(jí)管理單位建立了大交通數(shù)據(jù)資源管理系統(tǒng)及相關(guān)應(yīng)用 “一圖一庫(kù)”。其中“一庫(kù)”部分主要內(nèi)容包括：數(shù)據(jù)接入、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)共享；“一圖”部分主要內(nèi)容包括：GIS 信息及其關(guān)聯(lián)數(shù)據(jù)信息在二維、三維地圖上的形象表達(dá)。在數(shù)據(jù)中臺(tái)的建設(shè)中，存在大量的時(shí)序數(shù)據(jù)應(yīng)用場(chǎng)景，其中最為關(guān)鍵的就是車輛運(yùn)行產(chǎn)生的時(shí)序數(shù)據(jù)的存儲(chǔ)與使用。為了實(shí)現(xiàn)高效的業(yè)務(wù)處理， 研發(fā)人員決定從 InfluxDB、ClickHouse 和 TDengine 三款時(shí)序數(shù)據(jù)庫(kù)（Time Series Database）中進(jìn)行選型調(diào)研，最終憑借強(qiáng)大的產(chǎn)品力，TDengine 脫穎而出。

架構(gòu)搭建上的考慮

由于該系統(tǒng)業(yè)務(wù)開(kāi)發(fā)框架使用的是 Srping 框架，在使用 TAOS-JDBCDriver 進(jìn)行開(kāi)發(fā)時(shí)，可以選擇兩種方式進(jìn)行數(shù)據(jù)入庫(kù)——JDBC-JNI 方式或者是 JDBC-RESTful 方式。在 TDengine 官網(wǎng)，明確記載了“JDBC-RESTful 性能是 JDBC-JNI 的 50%～90%”，因此，其選擇了 JDBC-JNI 方式進(jìn)行多線程入庫(kù)——以數(shù)據(jù)庫(kù)連接池（Hikari、druid）+原生 SQL 執(zhí)行寫入為主要寫入模式

數(shù)字政通 x TDengine

“壓縮方面，通過(guò)查看 3 個(gè)節(jié)點(diǎn)的 Vnode 目錄總大小，可以得知目前數(shù)據(jù)占用總量為 8.7GB。而從上述表結(jié)構(gòu)我們也能看出實(shí)際入庫(kù)數(shù)據(jù)總量大概為 203GB，經(jīng)過(guò)壓縮后為 8.7GB，壓縮率達(dá)到了 4% 左右，大幅節(jié)約了存儲(chǔ)成本。在查詢上，對(duì) 9 億數(shù)據(jù)量的超級(jí)表使用降采樣查詢，展示設(shè)備指標(biāo)日月年線，耗時(shí)僅僅 0.22 秒?！?/p>

業(yè)務(wù)背景

隨著智慧城市的加速建設(shè)，物聯(lián)設(shè)備的管理問(wèn)題凸顯，為此，數(shù)字政通研發(fā)“城市管理物聯(lián)網(wǎng)平臺(tái)”對(duì)物聯(lián)網(wǎng)設(shè)備實(shí)行監(jiān)督，提供各類設(shè)備的實(shí)時(shí)監(jiān)測(cè)數(shù)據(jù)及報(bào)警數(shù)據(jù)，進(jìn)一步滿足各類設(shè)備的數(shù)據(jù)分析、關(guān)聯(lián)分析、歷史分析、對(duì)比分析等需求。簡(jiǎn)單來(lái)講就是通過(guò)鳥(niǎo)瞰整體數(shù)據(jù)來(lái)發(fā)現(xiàn)設(shè)備問(wèn)題，便于及時(shí)派單處理，助力智慧城市管理。面對(duì)海量物聯(lián)網(wǎng)數(shù)據(jù)的處理，TDengine 的高效存儲(chǔ)給了數(shù)字政通相當(dāng)大的助力。

架構(gòu)圖

結(jié)語(yǔ)

通過(guò)上面的幾大案例我們可以看到，在解決海量時(shí)序數(shù)據(jù)處理效率低、處理成本高等問(wèn)題上，關(guān)鍵點(diǎn)就是要選對(duì)合適的時(shí)序數(shù)據(jù)庫(kù)（Time Series Database,TSDB），當(dāng)前市面上時(shí)序數(shù)據(jù)庫(kù)產(chǎn)品眾多，在性能提升和降低資源消耗上究竟誰(shuí)能更勝一籌？如果你也在思考這一問(wèn)題，那或許《寫入性能：TDengine 最高達(dá)到 InfluxDB 的 10.3 倍，TimeScaleDB 的 6.74 倍》、《查詢性能：TDengine 最高達(dá)到了 InfluxDB 的 37 倍、 TimescaleDB 的 28.6 倍》這兩篇文章能給到你答案。

如果你的項(xiàng)目中也存在難以調(diào)節(jié)的數(shù)據(jù)痛點(diǎn)問(wèn)題，歡迎添加小T vx：tdengine1，我們會(huì)邀請(qǐng)你加入 TDengine 時(shí)序數(shù)據(jù)交流群，和專業(yè)的解決方案架構(gòu)師點(diǎn)對(duì)點(diǎn)溝通，齊心協(xié)力攻克數(shù)據(jù)技術(shù)難題。

數(shù)據(jù)建模

在 TSBS 框架中， TimescaleDB 和 InfluxDB 會(huì)自動(dòng)創(chuàng)建相應(yīng)的數(shù)據(jù)模型并生成對(duì)應(yīng)格式的數(shù)據(jù)。本文不再贅述其具體的數(shù)據(jù)建模方式，只介紹 TDengine 的數(shù)據(jù)建模策略。

TDengine 一個(gè)重要的創(chuàng)新是其獨(dú)特的數(shù)據(jù)模型——為每個(gè)設(shè)備創(chuàng)建獨(dú)立的數(shù)據(jù)表（子表），并通過(guò)超級(jí)表（Super Table）在邏輯上和語(yǔ)義上對(duì)同一采集類型的設(shè)備進(jìn)行統(tǒng)一管理。針對(duì) DevOps 場(chǎng)景的數(shù)據(jù)內(nèi)容，我們?yōu)槊總€(gè)設(shè)備 （這里是 CPU）創(chuàng)建了一個(gè)表，用以存儲(chǔ)該表的時(shí)序數(shù)據(jù)。我們?cè)?TDengine 中使用 hostname 作為子表的名稱（因?yàn)閔ostname 可以作為每個(gè)設(shè)備的標(biāo)識(shí) ID），并使用如下的語(yǔ)句創(chuàng)建名為 CPU 的超級(jí)表，包含 10 個(gè)測(cè)量值和 10 個(gè)標(biāo)簽。

create stable cpu (ts timestamp,usage_user bigint,usage_system bigint,usage_idle bigint,usage_nice bigint,usage_iowait bigint,usage_irq bigint,usage_softirq bigint,usage_steal bigint,usage_guest bigint,usage_guest_nice bigint)
tags (hostname varchar(30), region varchar(30),datacenter varchar(30),rack varchar(30),os varchar(30),arch varchar(30),team varchar(30),service varchar(30),service_version varchar(30),service_environment varchar(30))

然后 ，我們使用如下語(yǔ)句創(chuàng)建名為 host_0 的子表：

create table host_0 using cpu (hostname,region,datacenter,rack,os,arch,team,service,service_version,service_environment)
tags ('host_0','eu-central-1','eu-central-1a','6','Ubuntu15.10','x86','SF','19','1','test')

上述語(yǔ)句創(chuàng)建了一個(gè)子表。由此可知，對(duì)于 100 個(gè)設(shè)備（CPU）的場(chǎng)景 一，我們將會(huì)建立 100 個(gè)子表。對(duì)于 4000 個(gè)設(shè)備的場(chǎng)景二，系統(tǒng)中將會(huì)建立 4000 個(gè)子表用以存儲(chǔ)各自對(duì)應(yīng)的數(shù)據(jù) 。

軟件版本和配置

本報(bào)告僅僅比較 TDengine ( Time Series Database )、InfluxDB 與 TimeScaleDB, 下面對(duì)使用的版本和配置做出說(shuō)明。

TDengine

我們直接采用 TDengine Ver3.0，從 GitHub 克隆 TDengine 代碼編譯版本作為性能對(duì)比的版本。

gitinfo: c90e2aa791ceb62542f6ecffe7bd715165f181e8

在服務(wù)器上編譯安裝運(yùn)行。

cmake .. -DDISABLE_ASSERT=true -DSIMD_SUPPORT=true -DCMAKE_BUILD_TYPE=Release  -DBUILD_TOOLS=false
make -j  && make install

在 TDengine 的配置文件中設(shè)置了四個(gè)涉及查詢的配置參數(shù)。

numOfVnodeFetchThreads           4

queryRspPolicy                   1

compressMsgSize             128000

SIMD-builtins                    1

參數(shù)設(shè)置解讀：

• numOfVnodeFetchThreads 設(shè)置了 Vnode 的 Fetch 線程數(shù)量為 4 個(gè)，
• queryRspPolicy 用來(lái)打開(kāi) query response 快速返回機(jī)制
• compressMsgSize 的作用是自動(dòng)壓縮 TDengine 在傳輸層上大于 128,000 bytes 的消息
• 如果 CPU 支持，SIMD-builtins 可以啟用內(nèi)置的 FMA/AVX/AVX2 硬件加速

如上所述，TDengine 建庫(kù)默認(rèn)創(chuàng)建 6 個(gè) vnodes，即創(chuàng)建的表會(huì)按照表名隨機(jī)分配到 6 個(gè)虛擬節(jié)點(diǎn)（virtual node, VNode) 中。打開(kāi) LRU 緩存，設(shè)置為 last_row 緩存模式。對(duì)于場(chǎng)景一和場(chǎng)景二，stt_trigger 設(shè)置為 1，此時(shí) TDengine 會(huì)準(zhǔn)備一個(gè) Sorted Time-series Table (STT) 文件，當(dāng)單表寫入量小于 minimum rows 時(shí)，數(shù)據(jù)會(huì)直接保存在 STT 文件中，當(dāng) STT 文件中無(wú)法容納新數(shù)據(jù)時(shí)，系統(tǒng)就會(huì)將 STT 中的數(shù)據(jù)整理后再寫入到數(shù)據(jù)文件中。對(duì)于其他的場(chǎng)景（場(chǎng)景三、四、五），stt_trigger 設(shè)置為 8，即允許最多生成 8 個(gè) STT 文件。針對(duì)表較多的場(chǎng)景，需要適度增加 STT 的值，以此來(lái)獲得更好的寫入性能。

TimescaleDB

為確保結(jié)果具有可比性，我們選用 TimescaleDB 版本 version 2.6.0。為獲得較好的性能，TimescaleDB 需要針對(duì)不同的場(chǎng)景設(shè)置不同的 Chunk 參數(shù)，不同場(chǎng)景下參數(shù)的設(shè)置如下表所示。

上述參數(shù)的設(shè)置，充分參考了《TimescaleDB vs. InfluxDB》（如下鏈接） 中推薦的配置參數(shù)設(shè)置，以確保能夠最大化寫入性能指標(biāo)。

TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data. https://www.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/

InfluxDB

我們選擇了 InfluxDB version 1.8.10。這里沒(méi)有使用 InfluxDB 最新的 2.x 版本是因?yàn)?TSBS 沒(méi)有對(duì)其進(jìn)行適配，所以選用了 InfluxDB 能夠運(yùn)行 TSBS 框架的最新版本。同樣，我們采用《TimescaleDB vs. InfluxDB》中推薦的方式配置 InfluxDB，將緩沖區(qū)配置為 80G，以便 1000W 設(shè)備寫入時(shí)能夠順利進(jìn)行，同時(shí)開(kāi)啟 Time Series Index（TSI）。配置系統(tǒng)在系統(tǒng)插入數(shù)據(jù)完成 30s 后開(kāi)始數(shù)據(jù)壓縮。

cache-max-memory-size = "80g"
max-values-per-tag = 0
index-version = "tsi1"
compact-full-write-cold-duration = "30s"

測(cè)試步驟

硬件準(zhǔn)備

為達(dá)到與 TimescaleDB vs. InfluxDB 對(duì)比報(bào)告中的環(huán)境高度接近，我們使用亞馬遜 AWS 的 EC2 提供的 r4.8xlarge 類型實(shí)例作為基礎(chǔ)運(yùn)行平臺(tái)，包括 1 臺(tái)服務(wù)器、1 臺(tái)客戶端共兩個(gè)節(jié)點(diǎn)構(gòu)成的環(huán)境。客戶端與服務(wù)器硬件配置完全相同，客戶端與服務(wù)器使用 10 Gbps 網(wǎng)絡(luò)連接。配置簡(jiǎn)表如下：

服務(wù)器環(huán)境準(zhǔn)備

為運(yùn)行測(cè)試腳本，服務(wù)器 OS 需要是 ubuntu20 以上的系統(tǒng)。AWS EC2 的服務(wù)器系統(tǒng)信息如下：

1. OS： Linux tv5931 5.15.0-1028-aws #32~20.04.1-Ubuntu SMP Mon Jan 9 18:02:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
2. Gcc：gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04)
3. 基礎(chǔ)環(huán)境，版本信息為：Go1.16.9 , python3.8 , pip20.0.2 (無(wú)需手動(dòng)安裝，測(cè)試腳本將自動(dòng)安裝）
4. 編譯依賴：gcc , cmake, build-essential, git, libssl-dev (無(wú)需手動(dòng)安裝，測(cè)試腳本將自動(dòng)安裝）

開(kāi)始前請(qǐng)做兩個(gè)配置：

1. client 和 server 配置 ssh 訪問(wèn)免密，以便腳本可不暴露密碼，可參考文檔：免密配置（https://blog.csdn.net/qq_38154295/article/details/121582534）。
2. 保證 client 和 server 之間所有端口開(kāi)放。

獲取測(cè)試腳本

為便于重復(fù)測(cè)試，隱藏繁瑣的下載、安裝、配置、啟動(dòng)、匯總結(jié)果等細(xì)節(jié)，整個(gè) TSBS 的測(cè)試過(guò)程被封裝成一個(gè)測(cè)試腳本。重復(fù)本測(cè)試報(bào)告，需要先下載該測(cè)試腳本，腳本暫支持 ubuntu20 以上的系統(tǒng)。以下操作要求具有 root 權(quán)限。

1. 在客戶端機(jī)器，進(jìn)入測(cè)試目錄拉取代碼，默認(rèn)進(jìn)入 /usr/local/src/ 目錄：

cd /usr/local/src/ && apt install git && git clone https://github.com/taosdata/tsbs.git && cd tsbs/scripts/tsdbComp 

2. 修改配置文件 test.ini 中服務(wù)端和客戶端的 IP 地址（這里配置 AWS 的私網(wǎng)地址即可）和 hostname，如果服務(wù)器未配置免密，還需要配置服務(wù)器端的 root 密碼：

clientIP="192.168.0.203"   #client ip
clientHost="trd03"         #client hostname
serverIP="192.168.0.204"   #server ip
serverHost="trd04"         #server hostname
serverPass="taosdata123"   #server root password

一鍵執(zhí)行對(duì)比測(cè)試

執(zhí)行以下命令：

nohup bash tsdbComparison.sh > test.log &

測(cè)試腳本將自動(dòng)安裝 TDengine、InfluxDB、TimeScaleDB 等軟件，并自動(dòng)運(yùn)行各種對(duì)比測(cè)試項(xiàng)。在目前的硬件配置下，整個(gè)測(cè)試跑完需要大約一天半的時(shí)間。測(cè)試結(jié)束后，將自動(dòng)生成 CSV 格式的對(duì)比測(cè)試報(bào)告，并存放在客戶端的 /data2 目錄。

寫在最后

閱讀完畢，你一定更加深入地了解了 TDengine 的數(shù)據(jù)建模、三大數(shù)據(jù)庫(kù)測(cè)試版本和配置，以及如何運(yùn)用測(cè)試腳本進(jìn)行一鍵復(fù)現(xiàn)。如果有小伙伴想要驗(yàn)證 TDengine 的報(bào)告結(jié)果，歡迎按照上述步驟進(jìn)行操作，檢驗(yàn)測(cè)試結(jié)果，有任何問(wèn)題都?xì)g迎大家和我們及時(shí)溝通?，F(xiàn)在添加小T vx:tdengine1，可以邀請(qǐng)你加入 TDengine 用戶交流群，和更多志同道合的開(kāi)發(fā)者一起聊技術(shù)、聊實(shí)戰(zhàn)。

面對(duì)這樣規(guī)模的大數(shù)據(jù)挑戰(zhàn)，TDengine 選擇充分地利用時(shí)序數(shù)據(jù)本身的特點(diǎn)（可參考：https://mp.weixin.qq.com/s?__biz=MzIzNzg5MTcxNA==&mid=2247483956&idx=1&sn=86c55c40e935acd18835fec764fd7767&chksm=e8c0fbd9dfb772cf4e102a62498b034c6407cd9ea2c47d209b3e737800676cea7a108bf1d9d1&scene=21#wechat_redirect），來(lái)針對(duì)性地設(shè)計(jì)存儲(chǔ)引擎。最終的目標(biāo)其實(shí)就是：高效持續(xù)地吞吐、消化這些數(shù)據(jù)流，讓數(shù)據(jù)能夠無(wú)延遲地產(chǎn)生價(jià)值。

可以說(shuō)，我們追求的便是“流”一般的產(chǎn)品能力。而關(guān)于文章標(biāo)題的答案，本文將從 TDengine 的存儲(chǔ)引擎的變化史說(shuō)起：

由于認(rèn)為時(shí)間序列擁有天然遞增屬性，所以在最早期的 1.6 版本中，TDengine 是不支持對(duì)亂序數(shù)據(jù)的處理的，當(dāng)時(shí)亂序數(shù)據(jù)寫入表中后，系統(tǒng)會(huì)做報(bào)錯(cuò)處理。但經(jīng)過(guò)用戶實(shí)際場(chǎng)景的磨練后，我們不得不把注意力聚焦在這個(gè)“害群之馬”的身上。在生產(chǎn)環(huán)境中，由于設(shè)備損壞，網(wǎng)絡(luò)延遲等原因，數(shù)據(jù)亂序到達(dá)是難免的。更關(guān)鍵的是，不管數(shù)據(jù)亂序與否，用戶都有權(quán)利自行決定是否處理它，這是一個(gè)產(chǎn)品應(yīng)該具有的靈活度。

它讓理想中的數(shù)據(jù)流“亂”了，但我們卻又不能放棄它。

于是，我們立刻在 2.0 版本中增加了數(shù)據(jù)在內(nèi)存中的排序和硬盤中的數(shù)據(jù)子塊來(lái)支持亂序數(shù)據(jù)的處理，以此維持了數(shù)據(jù)的完整性和有序性。

但是這對(duì)于 2.0 版本的流式計(jì)算和訂閱來(lái)說(shuō)，仍然有類似的麻煩。

當(dāng)時(shí)的訂閱/流計(jì)算（連續(xù)查詢）是基于查詢引擎的產(chǎn)物，它依靠連續(xù)不斷地執(zhí)行 SQL 查詢結(jié)果作出實(shí)時(shí)反饋。以訂閱為例，每條符合要求被消費(fèi)掉的數(shù)據(jù)的時(shí)間戳，都會(huì)被記錄下來(lái)，從而作為下次 SQL 查詢中時(shí)間范圍的起始點(diǎn)。這時(shí)，即便是新數(shù)據(jù)的時(shí)間戳只比這個(gè)記錄早一秒，也不會(huì)被 SQL 輪詢到。因此可以說(shuō)， 2.0 的流計(jì)算（連續(xù)查詢）/訂閱同 1.6 一樣，它只處理了有序部分的數(shù)據(jù)。本質(zhì)上來(lái)說(shuō)，由于 SQL 取到的只能是已經(jīng)入庫(kù)的數(shù)據(jù)，所以這個(gè)階段的查詢行為是滯后的。

因此，我們決定在 3.0 再次進(jìn)行優(yōu)化重構(gòu)：

雖然數(shù)據(jù)的時(shí)間戳有亂序，但是他們到達(dá)數(shù)據(jù)庫(kù)的時(shí)間永遠(yuǎn)分有先后，這組序列相當(dāng)于“數(shù)據(jù)入庫(kù)時(shí)間”。不過(guò)這個(gè)“數(shù)據(jù)入庫(kù)時(shí)間” 不是時(shí)間戳，而是一個(gè)從 0 開(kāi)始的整型數(shù)字，我們稱之為“版本號(hào)”，代表的是數(shù)據(jù)庫(kù)概念是“第 x 次的數(shù)據(jù)變更”。熟悉 WAL 概念的伙伴們都知道，TDengine 利用 WAL 技術(shù)來(lái)提供基本的數(shù)據(jù)可靠性：每一條 WAL 信息代表的是一次數(shù)據(jù)庫(kù)的變更（增刪改），所以每一條 WAL 信息都會(huì)有唯一的版本號(hào)。通過(guò)“版本號(hào)”，我們可以明確地告訴流計(jì)算/訂閱該數(shù)據(jù)是否為新增數(shù)據(jù)，再通過(guò)對(duì) WAL 的這組“版本號(hào)”創(chuàng)建索引，我們就可以快速定位要消費(fèi)的數(shù)據(jù)了。

以訂閱為例：3.0 的訂閱引擎為時(shí)間驅(qū)動(dòng)，它會(huì)解析每一條新寫入的 WAL 的消息內(nèi)容，然后判斷是否匹配 topic 的 sql 條件，如果匹配則直接把 WAL 的消息轉(zhuǎn)化成數(shù)據(jù)返回給用戶 。

除了用于訂閱，這組版本號(hào)還有很多十分重要的作用：

1. 它本身核心的職責(zé)是 raft 日志的編號(hào)，用于多副本的數(shù)據(jù)同步；
2. 把版本號(hào)下發(fā)給每行數(shù)據(jù)，以追加寫入的形式完成數(shù)據(jù)的更新與刪除。

比如：某條 wal 消息的內(nèi)容是寫入一行數(shù)據(jù)：

insert into d1 values ("2022-03-10 08:00:00.000",100)；

那么這行數(shù)據(jù)就也擁有了這條 wal 消息的版本號(hào)（假設(shè)為 1） ，并且永久性地存儲(chǔ)在數(shù)據(jù)文件中。

解下來(lái)的一條 wal 消息的內(nèi)容是以相同時(shí)間戳更新這行數(shù)據(jù)：

insert into d1 values ("2022-03-10 08:00:00.000",200)；

消息的版本號(hào)便是 “2”，這條數(shù)據(jù)會(huì)以寫入的形式追加存儲(chǔ)。查詢的時(shí)候，在時(shí)間戳相同的情況下，通過(guò)比對(duì)版本號(hào)大小來(lái)選擇最新的數(shù)據(jù)，因此我們得到的數(shù)據(jù)便是：”2022-03-10 08:00:00.000″,200。

刪除同理，被刪除的數(shù)據(jù)是取版本號(hào)較大的空數(shù)據(jù)，這樣便可在不破壞原有數(shù)據(jù)文件結(jié)構(gòu)的情況下實(shí)現(xiàn)高效的刪除。以上部分具體實(shí)現(xiàn)細(xì)節(jié)可參考：https://mp.weixin.qq.com/s/imECB9dIFxZKeoaF3uoOgg

3.另外，當(dāng) follower 副本的數(shù)據(jù)落后，但 leader 上的 WAL 日志已經(jīng)消失的情況下，版本號(hào)還可以做數(shù)據(jù)文件的快照。只把增量的數(shù)據(jù)傳 輸過(guò)去，大大節(jié)約 data recovery 的時(shí)間。

通過(guò)這些大刀闊斧的重構(gòu)，TDengine 完美地把上面幾大模塊縫合了起來(lái)：

1. 解決了流計(jì)算、訂閱對(duì)于亂序數(shù)據(jù)處理的不支持；
2. 讓刪除操作為邏輯刪除，解決了刪除操作的性能問(wèn)題；
3. 基于版本號(hào)引入了快照機(jī)制，大幅優(yōu)化了特定場(chǎng)景下的數(shù)據(jù)恢復(fù)的速度。

回到標(biāo)題上，為何 TDengine 用戶應(yīng)盡快切至 3.0 版本？答案已經(jīng)都寫在上面了。通過(guò)下沉到海量用戶實(shí)際場(chǎng)景中反復(fù)迭代優(yōu)化，從 1.6 到 2.0 再到 3.0， TDengine 從底層結(jié)構(gòu)上解決了最初設(shè)計(jì)的瑕疵，各個(gè)模塊之間結(jié)構(gòu)變得更加清晰，銜接也更加自然，這樣扎實(shí)的底層設(shè)計(jì)對(duì)產(chǎn)品未來(lái)的穩(wěn)定和性能提升所帶來(lái)的幫助都是巨大的。

1. 極簡(jiǎn)的時(shí)序數(shù)據(jù)管理平臺(tái)

除高性能、具有水平擴(kuò)展能力的時(shí)序數(shù)據(jù)庫(kù)外，TDengine Cloud 還提供：

• 緩??存：無(wú)需部署 Redis，應(yīng)用就能快速的獲得最新數(shù)據(jù)。
• 數(shù)據(jù)訂閱：無(wú)需部署 Kafka，當(dāng)系統(tǒng)接收到新的數(shù)據(jù)時(shí)，應(yīng)用將立即收到通知。
• 流式計(jì)算：無(wú)需部署 Spark或Flink，應(yīng)用通過(guò)SQL就能創(chuàng)建連續(xù)查詢或時(shí)間驅(qū)動(dòng)的流計(jì)算。

TDengine Cloud 大幅簡(jiǎn)化了系統(tǒng)架構(gòu)、降低系統(tǒng)復(fù)雜度、降低運(yùn)營(yíng)成本。

2. 便捷且安全的數(shù)據(jù)共享

既支持將一個(gè)庫(kù)完全開(kāi)放，設(shè)置讀或?qū)懙臋?quán)限；也支持通過(guò)數(shù)據(jù)訂閱的方式，將庫(kù)、超級(jí)表、一組或一張表、或聚合處理后的數(shù)據(jù)分享出去。

• 便捷：如同在線文檔一樣簡(jiǎn)單，只需輸入對(duì)方郵件地址，設(shè)置訪問(wèn)權(quán)限和訪問(wèn)時(shí)長(zhǎng)即可實(shí)現(xiàn)分享。對(duì)方收到郵件，接受邀請(qǐng)后，可即刻訪問(wèn)。
• 安全：訪問(wèn)權(quán)限可以控制到一個(gè)運(yùn)行實(shí)例、一個(gè)庫(kù)或訂閱的 topic；對(duì)于每個(gè)授權(quán)的用戶，對(duì)分享的資源，系統(tǒng)會(huì)生成一個(gè)訪問(wèn)用的 token；而且可以設(shè)置訪問(wèn)到期時(shí)間。

便捷而又安全的數(shù)據(jù)共享，讓部門或合作伙伴之間能快速洞察業(yè)務(wù)的運(yùn)營(yíng)。

3. 安全可靠的企業(yè)級(jí)服務(wù)

除強(qiáng)大的時(shí)序數(shù)據(jù)管理、共享功能之外，TDengine Cloud 還提供企業(yè)穩(wěn)定運(yùn)營(yíng)必須具備的：

• 可靠：提供數(shù)據(jù)定時(shí)備份、恢復(fù)，數(shù)據(jù)從運(yùn)行實(shí)例到私有云、其他公有云或 Region 的實(shí)時(shí)復(fù)制。
• 安全：提供基于角色的訪問(wèn)權(quán)限控制、IP 白名單、用戶行為審計(jì)等功能。
• 專業(yè)：提供 7*24 的專業(yè)技術(shù)服務(wù)，承諾 99.9% 的 Service Level Agreement。

TDengine Cloud 讓用戶無(wú)需再為數(shù)據(jù)管理發(fā)愁，完全聚焦自身核心業(yè)務(wù)。

相比之下，TDengine社區(qū)版雖然也具有高性能、極簡(jiǎn)和云原生等特點(diǎn)，但是需要自己部署和維護(hù)，也沒(méi)有提供數(shù)據(jù)共享和企業(yè)級(jí)云服務(wù)等功能。

如果您想了解更多關(guān)于TDengine Cloud的信息，請(qǐng)查看文檔。