关于大数据处理:干货丨DolphinDB-API性能基准测试报告

1. 概述

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，并返回后果

1. 测试环境

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

1. 单用户上传数据性能测试

本节测试单用户通过 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 上传数据时，尽量增大上传的批次大小。

1. 多用户并发上传数据性能测试

本节测试通过 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/ 秒。

1. 多用户并发下载数据性能测试

本节测试通过 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 来进行数据检索、数据上传、数据计算等工作，随着并发度的进步，性能稳固晋升，基本上满足大部分业务的性能要求。