時序資料庫DolphinDB與InfluxDB對比測試報告2

阿新 • • 發佈：2020-12-03

近日，我們曾釋出測試報告，此報告測試於2019年。當時的結果顯示，DolphinDB的查詢效能領先InfluxDB一到三個資料量級，資料匯入效能領先一個數量級，資料匯出效能相差不大。時隔一年，DolphinDB與InfluxDB都做了不少功能和效能上的優化，兩者的效能究竟有何變化？我們重新對DolphinDB Database 和InfluxDB進行對比測試，測試涵蓋資料匯入匯出、資料查詢和磁碟空間佔用三個方面。測試的資料集也涵蓋了日益流行的物聯網資料集，以及規模更大的金融大資料集。

在本次的所有測試專案中，DolphinDB 表現更出色，主要測試結論如下：

資料匯入方面，小資料集情況下 DolphinDB 的匯入效能是 InfluxDB 的 75 倍，大資料集的情況下匯入效能大約是其 100 倍，且 InfluxDB 原生不支援 CSV 匯入，需要手動轉換為 Line Protocol 格式。
資料匯出方面，DolphinDB 的效能是 InfluxDB 的 11 倍左右，且 InfluxDB 在匯出大批量資料為 CSV 格式時容易產生記憶體溢位問題。
磁碟空間佔用方面，DolphinDB 佔用的空間總是小於等於 InfluxDB 佔用的空間。
查詢功能方面，InfluxDB 不支援對比查詢，不支援表連線，不支援對除 time 以外的 tag, field 進行排序，且函式的引數只能是某一個 field ，而不能是 field 的表示式，功能上有極大的限制，有多個測試樣例無法在
InfluxDB 中實現；而 DolphinDB 對資料的處理則更加的靈活、方便。
查詢效能方面，DolphinDB 在 2 個測試樣例中效能超過 InfluxDB 1000多倍；在 6 個測試樣例中效能超過 InfluxDB 50多倍；在 2 個測試樣例中效能為 InfluxDB 10多倍 ; 其餘所有測試樣例效能也全部優於 InfluxDB。

一、系統概述

DolphinDB

DolphinDB 是以 C++ 編寫的一款分析型的高效能分散式時序資料庫，使用高吞吐低延遲的列式記憶體引擎，集成了功能強大的程式語言和高容量高速度的流資料分析系統，可在資料庫中進行復雜的程式設計和運算，顯著減少資料遷移所耗費的時間。

DolphinDB 通過記憶體引擎、資料本地化、細粒度資料分割槽和平行計算實現高速的分散式計算，內建流水線、 Map Reduce 和迭代計算等多種計算框架，使用內嵌的分散式檔案系統自動管理分割槽資料及其副本，為分散式計算提供負載均衡和容錯能力。

DolphinDB 支援類標準 SQL 的語法，提供類似於 Python 的指令碼語言對資料進行操作，也提供其它常用程式語言的 API，在金融領域中的歷史資料分析建模與實時流資料處理，以及物聯網領域中的海量感測器資料處理與實時分析等場景中表現出色。

InfluxDB

InfluxDB 是目前最為流行的高效能開源時間序列資料庫，由 Go 語言寫成。它的核心是一款定製的儲存引擎 TSM Tree，對時間序列資料做了優化，優先考慮插入和查詢資料的效能。

InfluxDB 使用類 SQL 的查詢語言 InfluxQL，並提供開箱即用的時間序列數學和統計函式；同時對外提供基於 HTTP 的介面來支援資料的插入與查詢

InfluxDB 允許使用者定義資料儲存策略 (Retention Policies) 來實現對儲存超過指定時間的資料進行刪除或者降取樣，被廣泛應用於儲存系統的監控資料，IoT 行業的實時資料等場景。

二、測試環境

由於 InfluxDB 叢集版本閉源，在測試中 DolphinDB 與 InfluxDB 均使用單機模式。

主機：DELL OptiPlex 7060
CPU ：Intel Core i7-8700（6 核 12 執行緒 3.20 GHz）
記憶體：32 GB （8GB × 4, 2666 MHz）
硬碟：2T HDD （222 MB/s 讀取；210 MB/s 寫入）
OS：Ubuntu 16.04 LTS

測試使用的 DolphinDB 版本為 Linux v0.89 (2019.01.31)，最大記憶體設定為 28GB。

測試使用的 InfluxDB 版本為 1.7.5，根據 InfluxDB 官方配置檔案中的說明，結合測試機器的實際硬體對配置做了優化，主要將 wal-fsync-delay 調節為適合機械硬碟的 100ms，將 cache-max-memory-size 設定為 28GB，以及將 series-id-set-cache-size 設定為 400。

具體修改的配置詳見附錄中 influxdb.conf 檔案。

三、資料集

本報告測試了小資料量級（4.2GB）和大資料量級（270GB）下DolphinDB和InfluxDB的表現情況，以下是兩個資料的表結構和分割槽方法：

4.2GB裝置感測器記錄小資料集（csv格式，3千萬條）

我們使用物聯網裝置的感測器資訊作為小資料集來測試，資料集包含3000個裝置在2016年11月15日到2016年11月19日10000個時間間隔上的感測器時間，裝置ID，電池，記憶體，CPU等時序統計資訊。資料集共30,000,000條資料，包含包含一張裝置資訊表device_info和一張裝置感測器資訊記錄表readings。

資料來源：

下載地址：

以下是readings表在DolphinDB和InfluxDB中的結構：

2018年8月，我們曾釋出測試報告。當時的結果顯示，DolphinDB的查詢效能領先InfluxDB一到三個資料量級，資料匯入效能領先一個數量級，資料匯出效能相差不大。時隔半年，DolphinDB與InfluxDB都做了不少功能和效能上的優化，兩者的效能究竟有何變化？我們重新對DolphinDB和InfluxDB進行對比測試，測試涵蓋資料匯入匯出、資料查詢和磁碟空間佔用三個方面。測試的資料集也涵蓋了日益流行的物聯網資料集，以及規模更大的金融大資料集。

在本次的所有測試專案中，DolphinDB 表現更出色，主要測試結論如下：

資料匯入方面，小資料集情況下 DolphinDB 的匯入效能是 InfluxDB 的 75 倍，大資料集的情況下匯入效能大約是其 100 倍，且 InfluxDB 原生不支援 CSV 匯入，需要手動轉換為 Line Protocol 格式。
資料匯出方面，DolphinDB 的效能是 InfluxDB 的 11 倍左右，且 InfluxDB 在匯出大批量資料為 CSV 格式時容易產生記憶體溢位問題。
磁碟空間佔用方面，DolphinDB 佔用的空間總是小於等於 InfluxDB 佔用的空間。
查詢功能方面，InfluxDB 不支援對比查詢，不支援表連線，不支援對除 time 以外的 tag, field 進行排序，且函式的引數只能是某一個 field ，而不能是 field 的表示式，功能上有極大的限制，有多個測試樣例無法在 InfluxDB 中實現；而 DolphinDB 對資料的處理則更加的靈活、方便。
查詢效能方面，DolphinDB 在 2 個測試樣例中效能超過 InfluxDB 1000多倍；在 6 個測試樣例中效能超過 InfluxDB 50多倍；在 2 個測試樣例中效能為 InfluxDB 10多倍 ; 其餘所有測試樣例效能也全部優於 InfluxDB。

一、系統概述

DolphinDB

InfluxDB

InfluxDB 使用類 SQL 的查詢語言 InfluxQL，並提供開箱即用的時間序列數學和統計函式；同時對外提供基於 HTTP 的介面來支援資料的插入與查詢

二、測試環境

由於 InfluxDB 叢集版本閉源，在測試中 DolphinDB 與 InfluxDB 均使用單機模式。

測試使用的 DolphinDB 版本為 Linux v0.89 (2019.01.31)，最大記憶體設定為 28GB。

具體修改的配置詳見附錄中 influxdb.conf 檔案。

三、資料集

本報告測試了小資料量級（4.2GB）和大資料量級（270GB）下DolphinDB和InfluxDB的表現情況，以下是兩個資料的表結構和分割槽方法：

4.2GB裝置感測器記錄小資料集（csv格式，3千萬條）

資料來源：

下載地址：

以下是readings表在DolphinDB和InfluxDB中的結構：

我們在 DolphinDB database 中的分割槽方案是將 time 作為分割槽的第一個維度，按天分為 4 個區，分割槽邊界為 [2016.11.15 00:00:00, 2016.11.16 00:00:00, 2016.11.17 00:00:00, 2016.11.18 00:00:00, 2016.11.19 00:00:00]；再將 device_id 作為分割槽的第二個維度，每天一共分 10 個區，最後每個分割槽所包含的原始資料大小約為 100 MB。

InfluxDB 中使用 Shard Group 來儲存不同時間段的資料，不同 Shard Group 對應的時間段不會重合。一個 Shard Group 中包含了大量的 Shard， Shard 才是 InfluxDB 中真正儲存資料以及提供讀寫服務的結構。InfluxDB 採用了 Hash 分割槽的方法將落到同一個 Shard Group 中的資料再次進行了一次分割槽，即根據 hash(Series) 將時序資料對映到不同的 Shard，因此我們使用以下語句手動指定每個 Shard Group 的 Duration，在時間維度上按天分割槽。

create retention policy one_day on test duration inf replication 1 shard duration 1d default

270GB股票交易大資料集（csv格式，23個csv，65億條）

我們將紐約證券交易所（NYSE）提供的 2007.08.01 - 2007.08.31 一個月的股市 Level 1 報價資料作為大資料集進行測試，資料集包含 8000 多支股票在一個月內的交易時間,股票程式碼,買入價,賣出價,買入量,賣出量等報價資訊。

資料集中，共有 65 億（65,6169,3704）條報價記錄，一個 CSV 中儲存一個交易日的記錄，該月共 23 個交易日，未壓縮的 CSV 檔案共計 270 GB。

資料來源：

以下是TAQ表在DolphinDB和InfluxDB中的結構：

在 DolphinDB database 中我們按date(日期),symbol(股票程式碼)進行分割槽，每天再根據 symbol 分為 100 個分割槽，每個分割槽大概 120 MB 左右。

在InfluxDB中使用與小資料集相同的策略。

四、資料匯入匯出測試

1. 匯入資料

DolphinDB使用以下指令碼匯入：

timer {
    for (fp in fps) {
        loadTextEx(db, `taq, `date`symbol, fp, ,schema)
        print now() + ": 已匯入 " + fp
    }
}

4.2 GB 裝置感測器記錄小資料集共3 千萬條資料匯入用時 20 秒, 平均速率 150 萬條/秒。

270 GB 股票交易大資料集共 65 億條資料（TAQ20070801 - TAQ20070831 23 個檔案），匯入用時 38 分鐘 。

InfluxDB 本身不支援直接匯入 CSV，只能通過 HTTP API 或者influx -import的方式匯入，出於匯入效能考慮，我們選擇將 CSV 中的每一行先轉換為 Line Protocol 格式，如：

readings,device_id=demo000000,battery_status=discharging,bssid=A0:B1:C5:D2:E0:F3,ssid=stealth-net battery_level=96,battery_temperature=91.7,cpu_avg_1min=5.26,cpu_avg_5min=6.172,cpu_avg_15min=6.51066666666667,mem_free=650609585,mem_used=349390415,rssi=-42 1479211200

並新增如下檔案頭：

# DDL
CREATE DATABASE test
CREATE RETENTION POLICY one_day ON test DURATION INF REPLICATION 1 SHARD DURATION 1d DEFAULT

# DML
# CONTEXT-DATABASE:test
# CONTEXT-RETENTION-POLICY:one_day

儲存到磁碟中，再通過以下命令匯入：

influx -import -path=/data/devices/readings.txt -precision=s -database=test

經過轉換後，4.2 GB 裝置感測器記錄小資料集共3 千萬條資料匯入用時25 分鐘 10 秒, 平均速率2 萬條/秒 。

將 TAQ 資料插入到 InfluxDB 的過程中，如果多次插入時間相同 (1185923302)，tag 相同的記錄 (這裡是 symbol, mode, ex)，比如下面兩條，即使 value 不同 (bid, ofr, bidsiz, ofrsiz)，後面的那一條記錄也會覆蓋前面的記錄，最終資料庫中只保留了最後一條記錄。

taq,symbol=A,mode=12,ex=T bid=37,ofr=54.84,bidsiz=1,ofrsiz=1 1185923302
taq,symbol=A,mode=12,ex=T bid=37,ofr=38.12,bidsiz=1,ofrsiz=1 1185923302

要解決這個問題文件（）裡給出了兩種方法，一種是新增一個 tag 來對相同時間的資料設定不同的 tag value 手動區分，另一種是強行微調時間戳使其不同。

設定不同的 tag value 手動區分這種方法只適用於資料完全按照時間順序插入的情況。在使用其他的程式語言插入資料的過程中判斷該條記錄的時間戳是否與上一條記錄完全相同，並在插入資料庫時手動指定不同的 tag value 作區分，效率低下且操作繁瑣；若資料並非完全按照時間順序插入，則無法判斷當前的時間點是否已經有資料記錄的存在，是否會覆蓋先前的資料。

我們在本次測試中使用強行微調時間戳的方法，由於原有 TAQ 交易記錄的時間精度為秒，因此我們可以在將 CSV 的資料轉換至 Line Protocol 格式的過程中，在原來精確到秒的時間戳的基礎上，隨機加上一個毫秒值，產生一個新的精度為毫秒的偽時間戳，以防止資料衝突。

經過轉換後，270 GB 股票交易大資料集所包含的65 億條資料匯入用時65 小時，平均匯入速率2.7 萬條/秒。

匯入效能對比如下表所示：

結果顯示，DolphinDB 的匯入速率遠大於 InfluxDB 的匯入速率。在匯入過程中還可以觀察到，隨著時間的推移，InfluxDB 的匯入速率不斷下降，而 DolphinDB 保持穩定。而且 InfluxDB 在匯入資料時需要先編寫程式碼將 CSV 格式檔案轉換為 InfluxDB 的 Line Protocol 格式，複雜繁瑣，還會產生多餘的中間檔案佔用大量空間。

2. 匯出資料

在 DolphinDB 中使用saveText((select * from readings), '/data/devices/readings_dump.csv')進行資料匯出，用時僅需 28 秒。

在 InfluxDB 中若使用influx -database 'test' -format csv -execute "select * from readings > /data/devices/export_15.csv進行資料匯出記憶體佔用會超過 30 GB，最終引發fatal error: runtime: out of memory，最後採用分時間段匯出 CSV 的方法。程式碼如下所示：

for i in 1{5..8}; do
    time influx -database 'test' -format csv -execute "select * from readings where '2016-11-$i 00:00:00' <= time and time < '2016-11-$((i+1)) 00:00:00'" > /data/devices/export_$i.csv
done

總耗時5 min 31 s。

除效能差距懸殊之外，InfluxDB 的 CSV 資料匯出操作複雜，容易發生記憶體溢位問題，而且匯出的 CSV 檔案首行無欄位名稱，使用者體驗遠不如 DolphinDB。

匯出效能對比如下表所示：

五、磁碟空間佔用對比

匯入資料後，DolphinDB和InfluxDB佔用空間如下表所示：

小資料集中 DolphinDB 的空間利用率與 InfluxDB 相近，兩款資料庫都對資料進行了壓縮儲存，壓縮率大致處於同一個數量級，在 20% - 30% 之間；大資料集中 InfluxDB 對資料的壓縮效果不好，佔用空間為 DolphinDB 的兩倍。

六、資料庫查詢效能測試

我們一共對比了以下八種類別的查詢：

點查詢指定某一欄位取值進行查詢
範圍查詢針對單個或多個欄位根據時間區間查詢資料
精度查詢針對不同的標籤維度列進行資料聚合，實現高維或者低維的欄位範圍查詢功能
聚合查詢是指時序資料庫有提供針對欄位進行計數、平均值、求和、最大值、最小值、滑動平均值、標準差、歸一等聚合類 API 支援
對比查詢按照兩個維度將表中某欄位的內容重新整理為一張表格（第一個維度作為列，第二個維度作為行）
抽樣查詢指的是資料庫提供資料取樣的 API，可以為每一次查詢手動指定取樣方式進行資料的稀疏處理，防止查詢時間範圍太大資料量過載的問題
關聯查詢對不同的欄位，在進行相同精度、相同的時間範圍進行過濾查詢的基礎上，篩選出有關聯關係的欄位並進行分組
經典查詢是實際業務中常用的查詢

查詢測試的時間包含磁碟 I/O 的時間，為保證測試公平，每次啟動程式測試前均通過 Linux 系統命令sync; echo 1,2,3 | tee /proc/sys/vm/drop_caches分別清除系統的頁面快取、目錄項快取和硬碟快取，啟動程式後依次執行所有查詢語句執行一次。

4.2GB裝置感測器記錄小資料集查詢測試結果如下表所示：

查詢指令碼見附錄。

結果顯示，DolphinDB的查詢效能遠超於InfluxDB。在功能上，InfluxDB不如DolphinDB強大，比如：

InfluxDB不支援對比查詢和表連線，無法完成許多常規SQL資料庫支援的查詢。
InfluxDB 不支援對除 time 以外的 tag, field 進行排序，即不能select * from taq order by <some-field>，詳見。
InfluxDB中函式的引數只能是某一個 field ，而不能是 field 的表示式（field1 + field2等）因此只能用 subquery 先計算出表示式的值再套用函式，非常繁瑣，而且需要在子查詢和父查詢的 where 子句中重複指定時間範圍，否則會從最舊的資料記錄的時間開始一直掃描到當前時間。 InfluxDB 和 DolphinDB 第14個查詢語句的對比如下：

//14. 經典查詢：計算某時間段內高負載高電量裝置的記憶體大小
//DolphinDB
select max(date(time)) as date,	max(mem_free + mem_used) as mem_all
from readings
where
    time <= 2016.11.18 21:00:00,
    battery_level >= 90,
    cpu_avg_1min > 90
group by hour(time), device_id

//InfluxDB
select max(mem_total)
from (
	select mem_free + mem_used as mem_total
    from readings 
    where
        time <= '2016-11-18 21:00:00' and 
     	battery_level >= 90 and 
     	cpu_avg_1min > 90
)
where time <= '2016-11-18 21:00:00'
group by time(1h), device_id

270GB股票交易大資料查詢測試結果如下表所示：

查詢指令碼見附錄。

結果顯示，某些查詢，兩者的效能差別不大，但某些查詢，DolphinDB比InfluxDB快將近100到200倍。

在測試中，我們發現：

InfluxDB在第2個查詢中，對於where條件中選擇的多個非連續的時間分割槽返回的結果為空，而不是各個時間分割槽的結果的總和。InfluxDB中第2個查詢的程式碼如下所示：

//2. 範圍查詢：查詢某時間段內的某些股票的所有記錄
select symbol, time, bid, ofr 
from taq 
where
	(symbol = 'IBM' or symbol = 'MSFT' or symbol = 'GOOG' or symbol = 'YHOO') and
	('2007-08-03 01:30:00' <= time and time < '2007-08-03 01:30:59')
//該語句返回的結果不為空

select symbol, time, bid, ofr 
from taq 
where
	(symbol = 'IBM' or symbol = 'MSFT' or symbol = 'GOOG' or symbol = 'YHOO') and
	(('2007-08-03 01:30:00' <= time and time < '2007-08-03 01:30:59') or ('2007-08-04 01:30:00' <= time and time < '2007-08-04 01:30:59'))
//擴充套件了時間範圍後，該語句返回的結果反而為空

在InfluxDB中無法完成第8個查詢。DolphinDB的第8個查詢的程式碼如下所示：

//8. 經典查詢：計算某天每個股票每分鐘最大賣出與最小買入價之差
select symbol, max(ofr) - min(bid) as gap 
from taq 
where
	'2007-08-03' <= time and time < '2007-08-04' and 
	bid > 0 and 
	ofr > bid 
group by symbol, time(1m)

InfluxDB會丟擲異常，ERR: mixing multiple selector functions with tags or fields is not supported，即不能在select語句中同時使用max和min函式，而DolphinDB可以正常執行。

InfluxDB 對時間進行 group by 之後返回的結果包含了所有的時間段，即使當前時間段內無有效資料也返回（如下所示），對於稀疏資料增加了處理複雜度且降低效能，而DolphinDB只返回包含有效資料的時間段。

2007-07-31T23:02:00Z 22.17   54.84
2007-07-31T23:03:00Z
2007-07-31T23:04:00Z
2007-07-31T23:05:00Z
2007-07-31T23:06:00Z
2007-07-31T23:07:00Z
2007-07-31T23:08:00Z 37      38.12
2007-07-31T23:09:00Z
2007-07-31T23:10:00Z 37.03   38.12

七、其他方面的比較

DolphinDB 除了在基準測試中體現出優越的效能之外，還具有如下優勢：

語言上，InfluxDB 通過 InfluxQL 來操作資料庫，這是一種類 SQL 語言；而 DolphinDB 內建了完整的指令碼語言，不僅支援 SQL 語言，而且支援命令式、向量化、函式化、超程式設計、RPC 等多種程式設計正規化，可以輕鬆實現更多的功能。
資料匯入方面，InfluxDB 對於特定檔案格式資料例如 CSV 檔案的批量匯入沒有很好的官方支援，使用者只能通過開源第三方工具或自己實現檔案的讀取，規整為 InfluxDB 指定的輸入格式，再通過 API 進行批量匯入。單次只能匯入 5000 行，不僅操作複雜，效率也極其低下；而DolphinDB提供了ploadText、loadText、loadTextEx函式，可以直接在指令碼中匯入CSV檔案，對使用者更加友好，並且效率更高。
功能上，InfluxDB不支援表連線，部分常規查詢無法完成；而DolphinDB不僅支援常用的表連線功能，還對asof join和window join等非同時連線做了很多效能優化。
InfluxDB對時間序列的分組（group by）的最大分組是星期（week）；而DolphinDB支援對所有內建時間型別進行分組，最大單位為月（month）。InfluxDB在查詢中函式的引數只能是某一個欄位，不能是欄位的表示式，而DolphinDB無此限制。
DolphinDB提供了600多個內建函式，可滿足金融領域的歷史資料建模與實時流資料處理以及物聯網領域中的實時監控與實時分析處理等不同場景的需求，並且大部分聚合函式、處理時序資料需要的領先、滯後、累計視窗、滑動視窗函式都做了效能優化。
DolphinDB 的叢集版本支援事務，而且在一個分割槽的多個副本寫入時，保證強一致性。

附錄

資料預覽（取前20行）

DolphinDB

InfluxDB

時序資料庫DolphinDB與InfluxDB對比測試報告2

一、系統概述

二、測試環境

三、資料集

一、系統概述

二、測試環境

三、資料集

四、資料匯入匯出測試

1. 匯入資料

2. 匯出資料

五、磁碟空間佔用對比

六、資料庫查詢效能測試

七、其他方面的比較

附錄

時序資料庫DolphinDB與InfluxDB對比測試報告2

時序資料庫DolphinDB與Druid的對比測試

時序資料庫特點與對比

TDengine 和 InfluxDB 查詢效能對比測試報告

時序資料庫DolphinDB外掛開發教程

4倍速！ML.NET Model Builder GPU 與 CPU 對比測試

乾貨丨時序資料庫DolphinDB 記憶體分割槽表的載入和操作

墨天輪國產資料庫沙龍 | 胡津銘：時序資料庫DolphinDB，從量化金融到萬物互聯

Django bulk_create()、update()與資料庫事務的效率對比分析

阿里時序資料庫 telegraf+influxdb+grafana for sqlserver input plugin

allure 測試報告（一）簡介與安裝

使用Python操作InfluxDB時序資料庫

對比測試：Apache Pulsar 與 Kafka 在金融場景下的效能分析

內網穿透工具對比FRP+NPS+Zerotier與NAT伺服器測試

時序資料庫-InfluxDB安裝及使用-Ubuntu

實時資料庫與時序資料庫

Spring Boot中使用時序資料庫InfluxDB

OpenMetric與時序資料庫模型之主流TSDB分析

時序資料庫InfluxDB的基本語法

InfluxDB和MySQL的讀寫對比測試

時序資料庫DolphinDB與InfluxDB對比測試報告2

一、系統概述

二、測試環境

三、資料集

一、系統概述

二、測試環境

三、資料集

四、資料匯入匯出測試

1. 匯入資料

2. 匯出資料

五、磁碟空間佔用對比

六、資料庫查詢效能測試

七、其他方面的比較

附錄

相關推薦