干货丨时序数据库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来进行数据检索、数据上传、数据计算等任务，随着并发度的提升，性能稳定提高，基本上知足大部分业务的性能要求。