乾貨丨時序數據庫DolphinDB API性能基準測試報告

1. 概述

DolphinDB database是一款高性能分佈式時序數據庫（time-series database)，屬於列式關係型數據庫，由C++編寫，具備內置的並行和分佈式計算框架，可用於處理實時數據和海量歷史數據。

DolphinDB除了提供本身的腳本語言外，還提供了C++、Java、C#、Python、R等編程語言API，便於開發者在各類不一樣的開發環境中使用DolphinDB。

本文將測試API接口（C++、Java、C#、Python、R）與DolphinDB交互的性能，具體包括如下場景：

• 單用戶上傳數據到內存表
• 多用戶併發上傳數據到分佈式（DFS）數據庫
• 多用戶併發從DolphinDB下載數據到客戶端
• 多用戶併發發送計算任務（計算某天某個股票的分鐘級k線）到DolphinDB，並返回結果

2. 測試環境

2.1 硬件配置

本次測試使用了三臺配置相同的服務器（SERVER1，SERVER2，SERVER3），每臺服務器的配置以下：

主機：PowerEdge R730xd

CPU：E5-2650 24cores 48線程

內存：512G

硬盤：HDD 1.8T * 12

網絡：萬兆以太網

OS：CentOS Linux release 7.6.1810

2.2 軟件配置

C++ ： GCC 4.8.5

JRE ： 1.8.0

C# ：.net 2.2.105

Python : 3.7.0

R：3.5.2

DolphinDB : 0.94.2

2.3 測試框架

DolphinDB集羣部署在SERVER1上，API程序運行在SERVER2和SERVER3上，經過網絡鏈接到SERVER1上的DolphinDB數據節點進行測試。

DolphinDB集羣配置以下：

集羣包含1個控制節點和6個數據節點；

內存：32G/節點 * 6節點 = 192G

線程：8線程/節點 * 6節點 = 48 線程

硬盤：每一個節點配置一個獨立的HDD硬盤，1.8T/節點 * 6 = 9.6T

3. 單用戶上傳數據性能測試

本節測試單用戶經過API上傳數據到DolphinDB服務器。在SERVER1的DolphinDB集羣上建立一張內存表，SERVER2上運行API程序，將數據寫入到SERVER1內存表中。

寫入的數據表字段包括STRING、INT、LONG、SYMBOL、DOUBLE、DATE、TIME等不一樣類型的字段，共45列，每行336字節 ，共上傳100萬行，大小約336Mb。測試每次上傳10~100000 行的狀況下的吞吐量和時延。

該場景因爲是單用戶，而且不會涉及到磁盤操做，所以主要測試API程序數據格式到DolphinDB數據格式的轉換性能，CPU性能和網絡對測試結果會有較大的影響。各個API的測試結果以下：

表1. C++ API單用戶上傳數據到內存表測試結果

表2. Java API單用戶上傳數據到內存表測試結果

表3. C# API單用戶上傳數據到內存表測試結果

表4. Python API單用戶上傳數據到內存表測試結果

表5. R API單用戶上傳數據到內存表測試結果

表6. 各API單用戶上傳數據到內存表的寫入速度對比（單位：兆/秒）

圖1. API上傳數據到內存表性能比較

從單用戶寫入內存表的測試結果看，隨着批次大小的增長，性能提高明顯，這是由於在總的數據量相同的狀況下，一次上傳的數據行數越多，上傳次數越少，網絡通訊次數越少。

C++性能最優，C# 性能較差。Python和R底層實現都是用C++重寫，性能趨勢相同，當批次大小較小時，因爲調用C++模塊的次數較多，帶來更多的性能損失，性能也會更差。當批次大小達到1000行以上，性能提高明顯。咱們建議在使用Python和R上傳數據時，儘可能增大上傳的批次大小。

4. 多用戶併發上傳數據性能測試

本節測試經過API多用戶併發上傳數據到SERVER1的DFS數據表，在SERVER2 和 SERVER3上多個用戶同時經過網絡發起寫入操做。

每一個用戶共寫入500萬行，每次寫入25000行，每行336個字節，所以每一個用戶共寫入的數據量爲840Mb。測試在併發用戶爲1~128的狀況下，併發寫入的時延和吞吐量。

咱們把用戶數平均分配在SERVER2和SERVER3上運行，好比在測16個用戶時，兩個SERVER各運行8個客戶端程序。測試涉及到併發寫入，寫入的數據經過網絡傳輸到SERVER1上，而且存儲到磁盤上，所以能夠測試DolphinDB系統可否充分利用服務器CPU、硬盤、網絡等資源。各個API的測試結果以下：

表7. C++ API 多用戶併發上傳數據到DFS表測試結果

表8. Java API 多用戶併發上傳數據到DFS表測試結果

表9. C# API 多用戶併發上傳數據到DFS表測試結果

表10.Python API 多用戶併發上傳數據到DFS表測試結果

表11. R API 多用戶併發上傳數據到DFS表測試結果

表12. 各類API 數據上傳到DFS表測試結果比較（單位：兆/秒）

圖2. API上傳數據到DFS表性能比較

測試結果顯示，在用戶數小於16的狀況下，C++、Java性能優點明顯，Python 和C#性能稍差，吞吐量都基本上呈線性增加。當用戶數超過16時，網絡傳輸達到極限，成爲性能瓶頸，吞吐量基本維持在網絡的極限。網絡爲萬兆以太網，極限爲1G，可是因爲傳輸的數據有壓縮，因此係統吞吐量最大可達1.8G/秒。

5. 多用戶併發下載數據性能測試

本節測試經過API多用戶併發從DolphinDB下載數據的速度。數據庫部署在SERVER1上，多個用戶在SERVER2和SERVER3上同時下載數據，每一個用戶隨機選擇一個數據節點鏈接。每一個用戶下載的數據總量爲500萬行，每行45字節，共計225Mb ，每次下載數據爲25000行，分別測試併發用戶數爲1~128場景下的併發性能。

咱們測試瞭如下兩種場景下客戶端併發下載數據的性能：

• 5年數據量：從5年的數據中隨機選擇date和symbol進行下載，涉及的數據量約12T。因爲數據量大大超過系統內存，因此每次下載都須要從磁盤加載數據；
• 1週數據量：從最近一週的數據中隨機選擇symbol進行下載，涉及的數據量約60G。給DolphinDB分配的內存足以容納60G數據，全部的數據在緩存中，因此每次下載不須要從磁盤加載數據。

各API性能測試結果以下：

表13. C++ API 數據下載數據測試結果

表14. Java API 數據下載數據測試結果

表15. C# API 數據下載數據測試結果

表16. Python API 數據下載數據測試結果

表17. R API 數據下載數據測試結果

表18. 各API 5年數據下載吞吐量對比（單位：兆/秒）

圖3. API 5年數據下載吞吐量比較

從測試結果上看，在用戶數小於64的狀況下，吞吐量隨着用戶數的增長基本上呈線性增加，各個API性能差別不是很大，最大吞吐量在350M左右，因爲數據集爲12T，DolphinDB 緩存不了全部的數據，必須每次從磁盤加載，磁盤成爲系統瓶頸。

在用戶數爲128的時候性能反而下降，緣由是DolphinDB是按照分區加載數據的，若是用戶要下載某天某個股票的數據，則會把整個分區加載到內存中，再把用戶須要的數據返回給用戶。當併發用戶數太多，同時發起數據下載請求，又因爲數據量太大，數據基本都須要從磁盤中加載，128個用戶併發讀取磁盤，形成IO競爭加重，反而形成了總體吞吐量的下降。

所以，建議用戶在高併發讀取數據的場景下，各個節點儘可能配置獨立的多個數據卷，來提升IO的併發能力。

表19. 各類API 1週數據下載吞吐量比較（單位：兆/秒）

圖4. 各類API 1週數據併發下載吞吐量比較

從測試結果上看，各API的吞吐量隨着併發用戶數的增長基本成線性增長，給DolphinDB分配的內存可以所有容納一週的數據量，不須要每次從磁盤加載，所以吞吐量最大達到1.4G左右，達到了網絡的極限（網絡極限1G，因爲數據有壓縮，實際業務數據量爲1.4G）。

6. 計算併發性能測試

本節測試經過API向DolphinDB提交併發計算任務，計算某隻股票某天的分鐘級K線，計算總量約爲1億條。

咱們測試在5年數據量和1週數據量兩種場景下，不一樣併發用戶數（1~128）的計算性能。

• 5年數據量共12T，內存不能所有緩存，因此幾乎每次計算都須要從磁盤加載數據，屬於IO密集型應用場景，預期磁盤會成爲性能瓶頸。
• 1週數據量約60G，DolphinDB數據節點能所有緩存，所以是計算密集型應用場景，多用戶併發時，預期CPU會成爲性能瓶頸。

各API的測試結果以下：

表20. C++ API計算分鐘k線性能結果

表21. Java API 計算分鐘k線性能結果

表22. C# API 計算分鐘k線性能結果

表23. Python API計算分鐘k線性能結果

表24. R API計算分鐘k線性能結果

表25. 各類API 5年數據計算吞吐量比較（單位：兆/秒）

圖5. 各類API 5年數據併發計算吞吐量比較

從上圖中看出，當用戶數小於16的時候，各個API吞吐量基本呈線性增加，當用戶數到64時吞吐量達到最大；當用戶增長到128個的時候，吞吐量反而降低，緣由有兩方面，一方面，5年共12T數據，每次隨機選擇date和symbol，在併發用戶數增多到必定數量後，DolphinDB 內存不能所有容納，形成內存和磁盤之間有大量的數據交換，致使性能降低；另外一方面，併發用戶數太多，致使系統計算任務過多，任務的調度分發耗時增長，形成吞吐量反而下降。

表22. 各類API 1週數據計算吞吐量比較（單位：兆/秒）

圖5. 各類API 1週數據併發計算吞吐量比較

從測試結果中看出，在用戶數小於64時，吞吐量穩定增加，各個API性能相差不大，在64個併發用戶的時候，性能達到最大，計算數據的吞吐量接近7G/秒；當用戶達到128G，因爲系統任務太多，大大超過物理機器線程數（集羣所在物理機器共48線程），致使線程切換頻繁，集羣內部大量的任務調度分發時間增長，吞吐量反而下降。

7. 總結

本次詳細測試了DolphinDB C++、Java、C#、Python、R API在不一樣併發用戶數下數據上傳、數據下載、計算的性能，結論以下：

單用戶數據上傳到內存表，C++性能最優，吞吐量最大能到265兆/秒，Java、Python、R 也能達到160-200兆/秒，C# 性能稍差，吞吐量最大在60兆左右。並且隨着批次大小的增長，吞吐量增長明顯，Python和R 更爲顯著。所以在寫入時，在時延和內存容許的狀況下，儘可能增長批次大小。

多用戶併發寫入分佈式DFS表，隨着用戶數的增長，在達到網絡極限以前，吞吐量穩定增長，整體性能C++、Java性能優點明顯，當在32個併發用戶數左右的狀況下，網絡成爲瓶頸，各個API性能基本一致，因爲數據壓縮的緣由，系統最大吞吐量達到1.8G/秒。

多用戶併發下載數據，在數據集爲5年12T的場景下，用戶數爲64時達到最大吞吐量，爲380兆/秒左右。這個場景下全部的數據都須要從磁盤加載，讀磁盤成爲性能瓶頸，用戶數爲128的時候，因爲每一個節點要接受大量的用戶下載，磁盤IO競爭激烈，致使總體吞吐量降低。在數據集爲1周約60G的場景下，6個數據節點能夠緩存全部數據，所以全部的數據都在內存中，不須要從磁盤中加載，吞吐量能達到網絡極限，因爲數據壓縮緣由，集羣吞吐量爲1.8G/秒，並且隨着併發用戶的增長，吞吐量穩定增長。

多用戶併發計算，各個API發送計算某天某個股票的分鐘K線任務到DolphinDB，並返回計算結果，網絡傳輸的數據量很小，大部分時間都是在server端作計算，所以，各個API性能基本至關。 5年和1週數據量兩種場景下，吞吐量走勢基本一致，都是在用戶數爲64時達到最大吞吐量，5年數據量時，吞吐量最大爲1.3G，而1週數據量因爲所有數據都在內存，最大吞吐量達到7GB。而到128個用戶時，吞吐量降低，主要是因爲系統任務太多，大大超過物理機器線程數（集羣所在物理機器共48線程），致使線程切換頻繁，集羣內部大量的任務調度分發時間增長。

整體來看，DolphinDB經過API來進行數據檢索、數據上傳、數據計算等任務，隨着併發度的提升，性能穩定提高，基本上知足大部分業務的性能要求。