TDengine和InfluxDB的性能對比報告

前言

性能是用戶在選擇和使用時序資料庫時非常關注的一個點，

為了準確體現TDengine的性能資料，我們策劃了《TDengine和InfluxDB的性能對比》系列測驗報告，

“一言不合上資料”，今天我們就先來分享一下兩款資料庫寫入性能的對比，

為了更加具有說服力，本次的測驗是基于InfluxDB此前與Graphite的性能對比中使用過的場景和資料集的，（https://www.influxdata.com/blog/influxdb-outperforms-graphite-in-time-series-data-metrics-benchmark/）

經過多方準備與反復測驗后，我們得出的結論是：

1.在InfluxDB發布的自己最優的條件下，TDengine的寫入速度是它的2倍，

2.當設備數放大到1000的時候，TDengine的寫入速度是InfluxDB的5.2倍，

此外，除了給出測驗結果，我們還有一個小目標——那就是按照文中的步驟和配置，所有閱讀本文的開發人員或者架構師都可以復現出同樣的程序與結果，我們認為，只有通過這樣得來的測驗報告才是最有價值的測驗報告，

正文

InfluxDB是一個用Go語言撰寫的開源時序資料庫，其核心是一個自定義構建的存盤引擎，它針對時間序列資料進行了優化，是目前最為流行的時間序列資料庫，在DB-Engines的時序資料庫榜單中穩居第一，

TDengine是一款集成了訊息佇列，資料庫，流式計算等功能的物聯網大資料平臺，該產品不依賴任何開源或第三方軟體，擁有完全自主知識產權，具有高性能、高可靠、可伸縮、零管理、簡單易學等技術特點，和InfluxDB相比，TDengine是當前時序資料庫領域中一匹勢頭正勁的黑馬，

接下來，我們正式進入測驗環節，

一. 基礎資訊如下：

本次測驗使用的資料集是為DevOps監控指標案例建模的資料集，在這個場景中，一組服務器需要定期報告系統和應用程式的指標，具體實作是：每10秒在一臺服務器上的9個子系統（CPU、記憶體、磁盤、磁盤I/O、內核、網路、Redis、PostgreSQL和Nginx）上采樣100個值，為了更好的完成關鍵指標的對比，在與Graphite的該次對比中，InfluxDB選擇了一個周期為24小時，設備為100臺的設定，因此，本次的TDengine和InfluxDB對比測驗也是重新使用了這個相對適中的部署，

重要引數如下圖，在上文鏈接中均可見：

二. 環境準備

為了方便大家復現，我們所有的測驗都是在運行Ubuntu 20.10的兩臺azure虛擬機上進行的，配置如下：

標準 E16as_v4 ?AMD EPYC 7452（32-Core Processor 2345.608 MHz，16vCPU， 128GB RAM， 5000 IOPS SSD 1024GB） 用于資料庫服務端，
標準 F8s_v2 instance type ?Intel(R) Xeon(R) Platinum 8272CL （2.60GHz ，8vCPU，16 GB RAM）用于資料庫客戶端，

值得注意的是雖然上面服務端CPU顯示為32核，但是云服務只分給16個processor，

三. 具體測驗方法與步驟：

我們只要按照如下方式操作便可復現本次測驗結果：

1.整體規劃：

服務端機器需要安裝Influxdb和TDengine服務端；客戶端機器需要安裝TDengine客戶端（版本同為2.0.18）和go語言環境，以及從github上下載性能測驗腳本并運行，

2.安裝準備：

1) TDengine安裝方式（包含客戶端）：

A. TDengine安裝包下載

B. TDengine安裝步驟

2) Influxdb安裝方式：

Influxdb安裝包下載以及安裝步驟

3) go1.安裝方式：

wget https://studygolang.com/dl/golang/go1.16.linux-amd64.tar.gz

tar -C /usr/local -xzf go1.16.linux-amd64.tar.gz

添加環境變數/etc/profile export PATH=$PATH:/usr/local/go/bin

source /etc/profile

部署完TDengine、InfluxDB與Go語言環境，確保兩臺服務器的資料庫連接正常使用正常（建庫刪庫寫入查詢功能均需測驗，建庫之后立即洗掉，如有問題立刻排查，為確保權限問題不打擾環境測驗，可以全程使用root用戶）

此外，在測驗中應該注意以下幾點：

1）fsync的設定要保持同步，InfluxDB默認是無延時的fsync，需要修改TDengine的這兩個引數：walLevel=2 ，fsync=0才能達到相同的配置環境，后續的一切測驗均是在這個設定條件下完成，

2）TDengine的客戶端要把maxSQLLength開到最大1048576，

3.從github取下代碼：

su - root
mkdir /comparisons
cd /comparisons
git clone https://github.com/taosdata/timeseriesdatabase-comparisons

4.編譯準備：

1）cd /comparisons/timeseriesdatabase-comparisons，然后洗掉里面的go.mod和go.sum檔案
2）執行 go mod init github.com/taosdata/timeseriesdatabase-comparisons
3）執行如下命令安裝依賴包：
go get github.com/golang/protobuf/proto
go get github.com/google/flatbuffers/go
go get github.com/pelletier/go-toml
go get github.com/pkg/profile
go get github.com/valyala/fasthttp

最后看到新的go.sum和go.mod檔案后，可以繼續操作，

5.編譯階段：

mkdir  /comparisons/timeseriesdatabase-comparisons/build/tsdbcompare/bin
我們寫入需要3個程式，分別是bulk_data_gen、bulk_load_influx以及bulk_load_tdengine，下載得到代碼后，分別進入相應目錄執行編譯等如下命令：
cd /comparisons/timeseriesdatabase-comparisons/cmd/bulk_data_gen ;go build ;cp bulk_data_gen ../../build/tsdbcompare/bin
cd ../bulk_load_influx;go build ;cp bulk_load_influx ../../build/tsdbcompare/bin
cd ../bulk_load_tdengine;go build ; cp bulk_load_tdengine ../../build/tsdbcompare/bin

(注意：編譯bulk_load_tdengine之前要記得安裝TDengine客戶端)

6.修改腳本：

修改/comparisons/timeseriesdatabase-comparisons/build/tsdbcompare/write_to_server.sh, 把add='tdvs',修改為您選用的資料庫服務端hostname，

然后修改如下四行命令，將原有目錄替換為自己資料庫的檔案目錄所在（通常TDengine為/var/lib/taos，Influxdb為/var/lib/influxdb）：

rm -rf /mnt/lib/taos/* -> rm -rf /var/lib/taos/
rm -rf /mnt/lib/influxdb/* ->rm -rf /var/lib/influxdb/*
TDDISK=`ssh root@$add "du -sh /mnt/lib/taos/vnode | cut -d ' ' -f 1 " `-> TDDISK=`ssh root@$add "du -sh /var/lib/taos/vnode | cut -d ' ' -f 1 " `
IFDISK=`ssh root@$add "du -sh /mnt/lib/influxdb/data | cut -d ' ' -f 1" `-> IFDISK=`ssh root@$add "du -sh /var/lib/influxdb/data | cut -d ' ' -f 1" `

注銷掉：curl "http://$add:8086/query?q=drop%20database%20benchmark_db" -X POST這一行前面的#，

7.運行腳本復現測驗結果：

cd /comparisons/timeseriesdatabase-comparisons/build/tsdbcompare/


./loop_scale_to_server.sh

（注意：此腳本封裝了資料的生成與寫入程序，有興趣的讀者可以自行閱讀，如果遇到干擾因素導致寫入失敗，可以手動傳入引數再次執行得到測驗結果，如write_to_server.sh -b 5000 -w 100 -g 0 -s 100，具體引數含義可以通過“/comparison/timeseriesdatabase-comparisons/build/tsdbcompare/write_to_server.sh -h得知）

四. 實際測量資料

經過一番測驗后，我們制作了這樣一張表格，通過它我們可以清楚地看到：不論是單執行緒還是多執行緒，不論是小批次還是大批次，TDengine都一直穩穩保持著2倍左右的速度優勢，

其中5000batch，16wokers的場景下（InfluxDB與Graphite的對比報告中的測驗項），influxDB耗時35.04秒，而TDengine耗時僅17.92秒，

此外，InfluxDB僅僅做了100臺設備和900個監測點的測驗，但是于我們看來，實際應用場景中的設備數量和監測點數目一定是遠遠超過這個數字的，于是我們調整了腳本引數，從100個設備逐步增加到200，400，600，800，1000，通過將雙方資料量的同比例放大，從而得出了更多接入設備情況下的寫入對比結果，

（資料表格附在正文后，且由于所耗時間實在過長，所以1000臺設備單執行緒寫入1行的結果沒有寫入表格，不影響實際結果）結果是，在成倍地增加設備數后，TDengine依然保持著穩穩地領先，并且將優勢繼續擴大，

結論

當前的測驗結果已經比較有力地說明了前言中的兩點結論：

1.在InfluxDB發布的自己最優的條件下，TDengine的寫入速度是它的兩倍，

2.當設備數放大到1000的時候，TDengine的寫入速度是InfluxDB的5.2倍，

由于5.2倍又恰好是本次測驗雙方的性能差距最高點，因此我們毫不猶豫地決定使用該測驗條件（5000batch size，16workers）作出兩張以設備臺數為橫軸的折線圖，因為這將極具代表性，（圖一代表雙方寫入相同資料量的所耗秒數，圖二代表雙方每秒寫入的行數，）

這兩張圖充分說明了一點：設備數越多，資料量越大，TDengine的優勢就越明顯，正如成語有云——韓信將兵，多多益善，

而考慮到本次性能測驗對比的介面型別并不一致，TDengine采用的是cgo介面而InfluxDB為rest，性能上會有少量浮動，絕不會從根本上改變結果，而后續其他介面以及場景的測驗我們也會陸續推出，

如果您對更多細節感興趣，可以自行使用上文的測驗代碼自行操作復現，我們將十分歡迎您寶貴的建議，

最后附上測驗資料全記錄：