前言
性能是用戶在選擇和使用時序數據庫時非常關注的一個點。
為了准確體現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安裝方式（包含客戶端）：
B. TDengine安裝步驟
2) 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://:8086$add/query?q=drop database benchmark_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，性能上會有少量浮動，絕不會從根本上改變結果，而后續其他接口以及場景的測試我們也會陸續推出。
如果您對更多細節感興趣，可以自行使用上文的測試代碼自行操作復現，我們將十分歡迎您寶貴的建議。
最后附上測試數據全記錄：
