遷移背景

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

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

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

首先，我們先說下 taosdump 為什么是協(xié)助“大部分”開源版用戶解決這個問題：

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

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

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

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

總結(jié)

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

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

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

遷移操作

導(dǎo)出方：

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

1. 把數(shù)據(jù)庫升級到 2.6.0.34，升級注意事項以及操作步驟都可以參考這篇文章：http://m.fjzmyy.cn/engineering/10222.html。（注意：RPM 和 Deb 包不含 taosdump ，它需要通過安裝 taosTools 包獲得。所以建議大家直接使用包含 TDengine 的 Tar 包完成升級。）TDengine 安裝包需從 2.6 版本的文檔去下載：http://m.fjzmyy.cn/all-downloads 。如果使用了 RPM 和 Deb 的話，同樣需要通過上述鏈接下載最新版的 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

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

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

示例：

原本的建庫語句：

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)入操作本身是比較簡單的，具體操作可參考：https://docs.taosdata.com/2.6/reference/taosdump/。舉例：

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

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

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

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

上述參數(shù)的設(shè)置，充分參考了下方 TimescaleDB vs. InfluxDB 對比報告中推薦的配置參數(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)測試結(jié)果及詳細(xì)的測試數(shù)據(jù)介紹等內(nèi)容，大家可參考《一鍵獲取測試腳本，輕松驗證“TSBS 時序數(shù)據(jù)庫性能基準(zhǔn)測試報告”》、《TSBS 是什么？為什么時序數(shù)據(jù)庫 TDengine 會選擇它作為性能對比測試平臺？》兩篇文章，本文便不再贅述。

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

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

不同場景下寫入性能對比

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

寫入過程資源消耗對比

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

服務(wù)端 CPU 開銷

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

磁盤 I/O 對比

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

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

客戶端 CPU 開銷

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

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

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

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

4,000 devices × 10 metrics查詢性能對比

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

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

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

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

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

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

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

資源開銷對比

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

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

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

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

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

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

100 devices × 10 metrics 查詢性能對比

對于場景一(100 devices x 10 metrics)，TSBS 的 15 個查詢對比結(jié)果如下：

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

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

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

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

寫在最后

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

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

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

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

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

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

2. 提升了部分查詢場景下的性能

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

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

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

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

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

5. Python UDF

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

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

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

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

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

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

• OPC UA
• OPC DA
• Pi

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

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

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

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

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

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

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

報名通道

講師介紹

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

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

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

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

活動議程

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

獎品一覽

社區(qū)介紹

Apache SeaTunnel (Incubating)

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

TDengine

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

我們采用下方 TimescaleDB vs. InfluxDB 對比報告中推薦的方式配置 InfluxDB，將緩沖區(qū)配置為 80G，以便 1000W 設(shè)備寫入時能夠順利進(jìn)行，同時開啟 Time Series Index（TSI）。配置系統(tǒng)在系統(tǒng)插入數(shù)據(jù)完成 30s 后開始數(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)測試結(jié)果及詳細(xì)的測試數(shù)據(jù)介紹等內(nèi)容，大家可參考《一鍵獲取測試腳本，輕松驗證“TSBS 時序數(shù)據(jù)庫性能基準(zhǔn)測試報告”》、《TSBS 是什么？為什么時序數(shù)據(jù)庫 TDengine 會選擇它作為性能對比測試平臺？》兩篇文章，本文便不再贅述。

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

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

不同場景下寫入性能對比

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

寫入過程資源消耗對比

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

服務(wù)端 CPU 開銷

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

磁盤 I/O 對比

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

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

客戶端 CPU 開銷

從上圖可以看到，客戶端上 TDengine 對 CPU 的需求是大于 InfluxDB 的。整體來說，在整個寫入過程中，InfluxDB 客戶端負(fù)載計算資源占用較低，對客戶端壓力小，這是因為其寫入的壓力基本上完全集中在服務(wù)端，但這種模式很容易導(dǎo)致服務(wù)端成為瓶頸。而 TDengine 在客戶端的開銷最大，峰值瞬間達(dá)到了 56%，然后快速回落。綜合服務(wù)器與客戶端的資源開銷來看，TDengine 寫入持續(xù)時間更短，在系統(tǒng)整體 CPU 開銷上 TDengine 仍然具有相當(dāng)大的優(yōu)勢。

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

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

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

4,000 devices × 10 metrics查詢性能對比

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

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

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

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

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

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

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

資源開銷對比

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

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

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

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

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

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

3,100 devices × 10 metrics 查詢性能對比

對于場景一(100 devices x 10 metrics)，TSBS 的 15 個查詢對比結(jié)果如下：

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

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

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

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

寫在最后

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

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

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

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

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

taosKeeper 安裝方式：單獨編譯 taosKeeper 并安裝，詳情請參考 taosKeeper 倉庫（https://github.com/taosdata/taoskeeper）。

配置和運行方式

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

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

命令行參數(shù)啟動

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

$ taosKeeper

環(huán)境變量啟動

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

$ export TAOS_KEEPER_TDENGINE_HOST=192.168.64.3
$ taoskeeper

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

配置文件啟動

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

$ taoskeeper -c <keeper config file>

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

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

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

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

$ taos
# 如上示例，使用 log 庫作為監(jiān)控日志存儲位置
> 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)控數(shù)據(jù)庫 + Grafana 對 TDengine 進(jìn)行監(jiān)控的解決方案，下文將淺談一下 TDinsight 的前期部署和準(zhǔn)備。在部署時，我們首先需要下載自動化腳本 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指定。如果是運行在同一主機，通常是 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 來獲取。JSON 解析工具 jq 可能需要單獨安裝。

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

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

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

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

SENSORO x TDengine

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

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

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

架構(gòu)圖

北京智能建筑 x TDengine

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

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

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

架構(gòu)圖

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

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

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

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

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

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

數(shù)字政通 x TDengine

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

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

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

架構(gòu)圖

結(jié)語

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

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

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

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

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

然后 ，我們使用如下語句創(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')

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

軟件版本和配置

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

TDengine

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

gitinfo: c90e2aa791ceb62542f6ecffe7bd715165f181e8

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

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

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

numOfVnodeFetchThreads           4

queryRspPolicy                   1

compressMsgSize             128000

SIMD-builtins                    1

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

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

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

TimescaleDB

為確保結(jié)果具有可比性，我們選用 TimescaleDB 版本 version 2.6.0。為獲得較好的性能，TimescaleDB 需要針對不同的場景設(shè)置不同的 Chunk 參數(shù)，不同場景下參數(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。這里沒有使用 InfluxDB 最新的 2.x 版本是因為 TSBS 沒有對其進(jìn)行適配，所以選用了 InfluxDB 能夠運行 TSBS 框架的最新版本。同樣，我們采用《TimescaleDB vs. InfluxDB》中推薦的方式配置 InfluxDB，將緩沖區(qū)配置為 80G，以便 1000W 設(shè)備寫入時能夠順利進(jìn)行，同時開啟 Time Series Index（TSI）。配置系統(tǒng)在系統(tǒng)插入數(shù)據(jù)完成 30s 后開始數(shù)據(jù)壓縮。

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

測試步驟

硬件準(zhǔn)備

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

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

為運行測試腳本，服務(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 (無需手動安裝，測試腳本將自動安裝）
4. 編譯依賴：gcc , cmake, build-essential, git, libssl-dev (無需手動安裝，測試腳本將自動安裝）

開始前請做兩個配置：

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

獲取測試腳本

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

1. 在客戶端機器，進(jìn)入測試目錄拉取代碼，默認(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í)行對比測試

執(zhí)行以下命令：

nohup bash tsdbComparison.sh > test.log &

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

寫在最后

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

1. 極簡的時序數(shù)據(jù)管理平臺

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

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

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

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

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

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

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

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

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

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

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

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

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

在去年，TDengine 成功打造 TDengine Cloud 平臺并率先上線海外云市場，目前已經(jīng)發(fā)展有數(shù)百家注冊企業(yè)。而國內(nèi)的公有云支持工作也一直在如火如荼地推進(jìn)，在 TDengine 研發(fā)小伙伴的不懈努力下，終于在今年 3 月，TDengine Cloud 在國內(nèi)正式跟大家見面。

TDengine Cloud 是基于開源、高性能的時序數(shù)據(jù)庫（Time Series Database,TSDB）TDengine 打造的具備彈性伸縮、Serverless 特性的時序數(shù)據(jù)處理服務(wù)。除高性能的時序數(shù)據(jù)庫之外，它還具有緩存、訂閱和流計算等系統(tǒng)功能，同時提供了便利而又安全的數(shù)據(jù)分享、基于角色的權(quán)限控制、多云數(shù)據(jù)復(fù)制、邊云協(xié)同、IP 白名單等企業(yè)級功能。在時序數(shù)據(jù)的管理上，利用 TDengine Cloud，物聯(lián)網(wǎng)、工業(yè)互聯(lián)網(wǎng)、金融、IT 運維監(jiān)控等領(lǐng)域企業(yè)可實現(xiàn)人力成本和運營成本的大幅降低。

下面詳細(xì)介紹一下 TDengine Cloud 主要具備的三點優(yōu)勢：

極簡的時序數(shù)據(jù)管理平臺

除高性能、具有水平擴展能力的時序數(shù)據(jù)庫外，TDengine Cloud 還提供緩存、數(shù)據(jù)訂閱、流式計算等功能，無需再部署 Redis、Kafka、Spark/Flink 等第三方軟件，大幅簡化系統(tǒng)架構(gòu)、降低運營成本。

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

TDengine Cloud 既支持將一個庫完全開放，設(shè)置讀或?qū)懙臋?quán)限；也支持通過數(shù)據(jù)訂閱的方式，將庫、超級表、一組或一張表、或聚合處理后的數(shù)據(jù)分享出去。這種時序數(shù)據(jù)共享機制能夠幫助企業(yè)各部門以及合作伙伴之間快速洞察業(yè)務(wù)運營的變化。

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

TDengine Cloud 提供數(shù)據(jù)定時備份、恢復(fù)，數(shù)據(jù)從運行實例到私有云、其他公有云或Region 的實時復(fù)制；為保證數(shù)據(jù)安全，還會提供基于角色的訪問權(quán)限控制、IP 白名單、用戶行為審計等功能，用 7*24 的專業(yè)技術(shù)服務(wù)保障 99.9% 的 Service Level Agreement。通過安全、專業(yè)、可靠的企業(yè)級服務(wù)，用戶可以用最少的精力和成本完成數(shù)據(jù)管理，更加聚焦自身核心業(yè)務(wù)的發(fā)展。

TDengine 創(chuàng)始人& CEO 陶建輝也一直在關(guān)注 TDengine Cloud 在國內(nèi)云服務(wù)市場的推進(jìn)工作，對于此次成功上線阿里云，他表示：

“這是 TDengine Cloud 在國內(nèi)云服務(wù)市場邁出的一大步，現(xiàn)在物聯(lián)網(wǎng)和大數(shù)據(jù)開發(fā)人員可以在阿里云、Microsoft Azure、AWS、Google Cloud 四大公有云上，訪問和部署穩(wěn)健、安全、擴展性強的 TDengine 時序數(shù)據(jù)解決方案。未來 TDengine Cloud 還將發(fā)展更多的‘云’，打造更全面的云服務(wù)網(wǎng)絡(luò)?！?/p>

借助 TDengine Cloud，用戶能夠根據(jù)業(yè)務(wù)需求保障數(shù)據(jù)庫集群自動擴縮容，不用為部署、優(yōu)化、擴容、備份、異地容災(zāi)等繁瑣事務(wù)發(fā)愁，可以從繁重的運維工作中解放出來，在解決業(yè)務(wù)需求的同時實現(xiàn)更好的成本管理。

隨著 TDengine Cloud 的推出，濤思數(shù)據(jù)產(chǎn)品生態(tài)變得更加豐富，借助這些產(chǎn)品，我們有信心幫助企業(yè)以最低的成本搭建最高效的數(shù)據(jù)處理架構(gòu)，實現(xiàn)企業(yè)業(yè)務(wù)的數(shù)字化智能化轉(zhuǎn)型快速發(fā)展。

點擊了解關(guān)于 TDengine Cloud 的更多信息。