无码人妻精品一区二区三18禁,影音先锋男人AV橹橹色,污污污污污污www网站免费,日韩成人av无码一区二区三区,欧美性受xxxx狂喷水

一鍵獲取測試腳本，輕松驗證 TDengine 3.0 IoT 場景下 TSBS 測試報告

爾悅

2023-07-05 / ,

不久前，基于 TSBS，我們發布了 TDengine 3.0 測試報告系列第一期——《DevOps 場景下 TDengine 3.0 對比測試報告》，報告驗證了 TDengine 基于時序數據場景所設計的獨特架構，在 DevOps 場景下帶來的性能優勢以及成本控制水平。本期我們繼續探尋在 IoT 場景下，TDengine 對比 TimescaleDB、InfluxDB 在寫入和查詢上的性能表現——《IoT 場景下 TDengine 3.0 性能對比分析報告來啦！》，給有時序數據庫（Time Series Database）選型需求的開發者做參考。

本期報告顯示，在全部的五個場景中，TDengine 寫入性能均優于 TimescaleDB 和 InfluxDB。寫入性能最大達到 TimescaleDB 的 3.3 倍，InfluxDB 的 16.2 倍；此外，TDengine 在寫入過程中消耗了最少計算（CPU）資源和磁盤 IO 開銷。在查詢方面，對于大多數查詢類型，TDengine 的性能均優于 InfluxDB 和 TimescaleDB，在復雜的混合查詢中 TDengine 展現出巨大的優勢——其中 avg-load 和 breakdown-frequency 的查詢性能是 InfluxDB 的 426 倍 和 53 倍；daily-activity 和 avg-load 的查詢性能是 TimescaleDB 的 34 倍和 23 倍。

為了便于大家對報告結果進行驗證，本篇文章將會對測試數據及環境搭建等環節進行一一闡述，方便有需要的開發者取用復制。此外，本測試報告中的數據在準備好物理環境后，可以由腳本一鍵執行生成，測試步驟在本文中也有涉及。

測試背景

測試場景介紹

在本期測試報告中，我們使用了 TSBS 的 IoT 場景作為基礎數據集，在TSBS 框架下模擬虛擬貨運公司車隊中一組卡車的時序數據，針對每個卡車的診斷數據（diagnostics）記錄包含 3 個測量值和 1 個（納秒分辨率）時間戳、8 個標簽值；卡車的指標信息（readings）記錄包含 7 個測量值和 1 個（納秒分辨率）時間戳，8 個標簽值。數據模式（schema）見下圖，每 10 秒對生成的數據進行一條記錄。由于 IoT 場景引入了環境因素，所以每個卡車存在無序和缺失的時間序列數據。

一鍵獲取測試腳本，輕松驗證 TDengine 3.0 IoT 場景下 TSBS 測試報告 - TDengine Database 時序數據庫
樣例數據

在整個基準性能評估中，涉及以下五個場景，每個場景的具體數據規模和特點見下表，由于存在數據缺失，所以單個卡車數據記錄取記錄均值：

一鍵獲取測試腳本，輕松驗證 TDengine 3.0 IoT 場景下 TSBS 測試報告 - TDengine Database 時序數據庫

從上表可以看到，五個場景的區別主要在于數據集所包含的單個卡車記錄數量以及卡車總數的差異，數據時間間隔均維持在 10 秒。整體上看，五個場景的數據規模都不大，數據規模最大的是場景五，數據規模最小的是場景四。在場景四和場景五中，由于卡車數量相對較多，所以數據集僅覆蓋了 3 分鐘的時間跨度。

數據建模

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

TDengine 一個重要的創新是其獨特的數據模型——為每個設備創建獨立的數據表（子表），并通過超級表（Super Table）在邏輯上和語義上對同一采集類型的設備進行統一管理。針對 IoT 場景的數據內容，我們為每個卡車創建了兩張表（后文中設備和卡車同義），用來存儲診斷信息和指標信息的時序數據。在上述數據記錄中，truck name 可以作為每個卡車的標識 ID，因為有兩張超級表，因此在 TDengine 中使用 truck name 拼接 d（r）作為子表的名稱。我們使用如下的語句創建名為 diagnostics 和 readings 的超級表，分別包含 3 、7 個測量值和 8 個標簽。

CREATE STABLE `readings` (`ts` TIMESTAMP, `latitude` DOUBLE, `longitude` DOUBLE, `elevation` DOUBLE, `velocity` DOUBLE, `heading` DOUBLE, `grade` DOUBLE, `fuel_consumption` DOUBLE) TAGS (`name` VARCHAR(30), `fleet` VARCHAR(30), `driver` VARCHAR(30), `model` VARCHAR(30), `device_version` VARCHAR(30), `load_capacity` DOUBLE, `fuel_capacity` DOUBLE, `nominal_fuel_consumption` DOUBLE)
 
CREATE STABLE `diagnostics` (`ts` TIMESTAMP, `fuel_state` DOUBLE, `current_load` DOUBLE, `status` BIGINT) TAGS (`name` VARCHAR(30), `fleet` VARCHAR(30), `driver` VARCHAR(30), `model` VARCHAR(30), `device_version` VARCHAR(30), `load_capacity` DOUBLE, `fuel_capacity` DOUBLE, `nominal_fuel_consumption` DOUBLE)

然后 ，我們使用如下語句創建名為 r_truck_1和 d_truck_1 的子表：

CREATE TABLE `r_truck_1` USING `readings` (`name`, `fleet`, `driver`, `model`, `device_version`, `load_capacity`, `fuel_capacity`, `nominal_fuel_consumption`) TAGS ("truck_1", "South", "Albert", "F-150", "v1.5", 2.000000e+03, 2.000000e+02, 1.500000e+01)
 
CREATE TABLE `d_truck_1` USING `diagnostics` (`name`, `fleet`, `driver`, `model`, `device_version`, `load_capacity`, `fuel_capacity`, `nominal_fuel_consumption`) TAGS ("truck_1", "South", "Albert", "F-150", "v1.5", 2.000000e+03, 2.000000e+02, 1.500000e+01)

由此可知，對于 100 個設備（CPU）的場景一，我們將會建立 100 個子表；對于 4000 個設備的場景二，系統中將會建立 4000 個子表用以存儲各自對應的數據。在 TSBS 框架生成的數據中，我們發現存在標簽信息 truck 為 null 的數據內容，為此建立了 d_truck_null(r_truck_null) 的表，用以存儲所有未能標識 truck 的數據。

軟件版本和配置

本報告比較 TDengine、InfluxDB 與 TimeScaleDB 三種類型的數據庫，下面對使用的版本和配置做出說明。

TDengine

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

gitinfo: 1bea5a53c27e18d19688f4d38596413272484900

在服務器上編譯安裝運行：

cmake .. -DDISABLE_ASSERT=true -DSIMD_SUPPORT=true -DCMAKE_BUILD_TYPE=Release  -DBUILD_TOOLS=false

在 TDengine 的配置文件中設置了六個涉及查詢的配置參數：

numOfVnodeFetchThreads   4

queryRspPolicy           1

compressMsgSize          128000

SIMD-builtins            1

tagFilterCache           1

numOfTaskQueueThreads    24

第一個參數 numOfVnodeFetchThreads 作用是設置 Vnode（virtual node） 的 Fetch 線程數量為 4 個；第二個參數 queryRspPolicy 用于打開 query response 快速返回機制；第三個參數 compressMsgSize 讓 TDengine 在傳輸層上大于 128000 bytes 的消息自動進行壓縮；第四個參數的作用是在 CPU 支持的情況下啟用內置的 FMA/AVX/AVX2 硬件加速；第五個參數用于開啟 tag 列的過濾緩存；第六個參數用于設置任務隊列的線程數量為 24。

由于 IoT 場景下表數目是卡車規模數的二倍，所以 TDengine 建庫默認創建 12 個 vnodes，即創建的表會按照表名隨機分配到 12 個虛擬節點中，將 LRU 緩存設置為 last_row 緩存模式。對于場景一和場景二，stt_trigger 設置為 1，此時 TDengine 會準備一個 Sorted Time-series Table (STT) 文件，用于容納單表寫入量小于 minimum rows 時的數據，當 STT 文件中無法容納新數據時，系統會將 STT 中的數據進行整理，再寫入到數據文件中。在本次報告中，場景三配置 stt_trigger 為 8，場景四和場景五 stt_trigger 設置為 16 ，即允許最多生成 16 個 STT 文件。針對低頻表多的場景，需要適度增加 STT 的值，以此來獲得更好的寫入性能。

TimescaleDB

為確保結果具有可比性，我們選用 TimescaleDB version 2.10.1。為獲得較好的性能，TimescaleDB 需要針對不同的場景設置不同的 Chunk 參數，不同場景下參數的設置如下表所示。

一鍵獲取測試腳本，輕松驗證 TDengine 3.0 IoT 場景下 TSBS 測試報告 - TDengine Database 時序數據庫

關于上述參數的設置，我們充分參考了[TimescaleDB vs. InfluxDB]對比報告中推薦的配置參數設置，以確保能夠最大化寫入性能指標。

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

InfluxDB

針對 InfluxDB，本報告選用的是 version 1.8.10。這里沒有使用 InfluxDB 最新的 2.x 版本是因為 TSBS 沒有對其進行適配，所選用的 1.8.10 版本是 InfluxDB 能夠運行 TSBS 框架的最新版本。在配置上，仍然采用[TimescaleDB vs. InfluxDB]對比報告中推薦的方式對其進行配置，將緩沖區配置為 80GB，以便 1000W 設備寫入時能夠順利進行，同時開啟 Time Series Index（TSI）。

配置系統在系統插入數據完成 30s 后開始進行數據壓縮：

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

測試步驟

硬件準備

為與[TimescaleDB vs. InfluxDB]對比報告的環境高度接近，我們使用亞馬遜 AWS 的 EC2 提供的 r4.8xlarge 類型實例作為基礎運行平臺，包括 1 臺服務器、1 臺客戶端共兩個節點構成的環境。客戶端與服務器硬件配置完全相同，客戶端與服務器使用 10 Gbps 網絡連接。配置簡表如下：

一鍵獲取測試腳本，輕松驗證 TDengine 3.0 IoT 場景下 TSBS 測試報告 - TDengine Database 時序數據庫

服務器環境準備

為運行測試腳本，服務器 OS 需要是 ubuntu20.04 以上的系統。AWS EC2 的服務器系統信息如下：

  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. 基礎環境，版本信息為：Go1.16.9 , python3.8 , pip20.0.2 (無需手動安裝，測試腳本將自動安裝）
  4. 編譯依賴：gcc , cmake, build-essential, git, libssl-dev (無需手動安裝，測試腳本將自動安裝）

此外，還要做下面兩個配置：

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

獲取測試腳本

為便于重復測試，隱藏繁瑣的下載、安裝、配置、啟動、匯總結果等細節，整個 TSBS 的測試過程被封裝成一個測試腳本。重復本測試報告，需要先下載該測試腳本，腳本暫支持 ubuntu20.04 的系統。以下操作要求具有 root 權限。

在客戶端機器，進入測試目錄拉取代碼，默認進入 /usr/local/src/ 目錄：

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

需要修改配置文件 test.ini 中服務端和客戶端的 IP 地址（這里配置 AWS 的私網地址即可）和 hostname，如果服務器未配置免密，還需要配置服務器端的 root 密碼。由于本次測試在 IoT 場景下，故修改 caseType 為 iot。

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
caseType="iot"             #testcase

一鍵執行對比測試

執行以下命令：

nohup bash tsdbComparison.sh > test.log &

測試腳本將自動安裝 TDengine、InfluxDB、TimescaleDB 等軟件，并自動運行各種對比測試項。在目前的硬件配置下，整個測試跑完需要大約三天的時間。測試結束后，將自動生成 CSV 格式的對比測試報告，并存放在客戶端的 /data2 目錄，對應 load 和 query 前綴的文件夾下。

結語

閱讀完畢，你一定更加深入地了解了 TDengine 的數據建模、三大數據庫測試版本和配置，以及如何運用測試腳本進行一鍵復現。如果有小伙伴想要驗證三大數據庫在 IoT 場景下的測試結果，歡迎按照上述步驟進行操作，檢驗測試結果，有任何問題都歡迎大家和我們及時溝通。現在你也可以添加小T vx:tdengine1，申請加入 TDengine 用戶交流群，和更多志同道合的開發者一起聊技術、聊實戰。