- 概述
DolphinDB是一款高性能分布式时序数据库(time-series database),属于列式关系型数据库,由C++编写,具备内置的并行和分布式计算框架,可用于解决实时数据和海量历史数据。
DolphinDB database除了提供本人的脚本语言外,还提供了C++、Java、C#、Python、R等编程语言API,便于开发者在各种不同的开发环境中应用DolphinDB。
本文将测试API接口(C++、Java、C#、Python、R)与DolphinDB交互的性能,具体包含以下场景:
- 单用户上传数据到内存表
- 多用户并发上传数据到分布式(DFS)数据库
- 多用户并发从DolphinDB下载数据到客户端
- 多用户并发发送计算工作(计算某天某个股票的分钟级k线)到DolphinDB,并返回后果
- 测试环境
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
- 单用户上传数据性能测试
本节测试单用户通过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上传数据时,尽量增大上传的批次大小。
- 多用户并发上传数据性能测试
本节测试通过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/秒。
- 多用户并发下载数据性能测试
本节测试通过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来进行数据检索、数据上传、数据计算等工作,随着并发度的进步,性能稳固晋升,基本上满足大部分业务的性能要求。