DolphinDB API性能基准测试报告
该页面提供《DolphinDB API性能基准测试报告》的标题信息，并给出作者署名与发布日期。
Source: https://dolphindb.cn/blogs/62
What this page covers
- DolphinDB 产品定位与多语言 API 范围概述。
- 测试环境：硬件、软件与集群/测试框架配置。
- 单用户上传到内存表的测试方法与结果解读。
- 多用户并发写入 DFS 的并发范围与瓶颈分析。
- 多用户并发下载在 IO/缓存条件下的表现讨论。
- 并发计算任务在不同数据集下的并发扩展特性。
- 各场景的汇总结论与建议。
技能认证特训营第二期报名入口（限时报名）
页面顶部提供活动报名提示，并给出外部报名链接。
- 页面包含“技能认证特训营第二期”的报名入口信息。
- 报名链接指向外部页面。
- 报名链接为 https://www.qingsuyun.com/h5/e/217471/5/ 。
DolphinDB API性能基准测试报告（作者与日期）
该部分给出文章标题信息，并包含作者署名与发布日期。
- 文章标题为“DolphinDB API性能基准测试报告”。
- 发布日期为 2021-08-05。
概述：DolphinDB与API测试场景
该部分介绍 DolphinDB 的产品属性、可用语言 API，并列出本文测试的交互性能场景。
- DolphinDB 的定位为高性能分布式时序数据库，属于列式关系型数据库。
- DolphinDB 实现语言为 C++。
- DolphinDB 内置并行和分布式计算框架。
- 页面提到的 API 语言包含 C++、Java、C#、Python、R。
- 测试场景包含上传、并发写入、并发下载与并发计算任务。
测试环境：硬件、软件与集群/测试框架
该部分描述测试硬件与操作系统、软件版本，以及集群部署与节点资源配置方式。
- 测试使用三台配置相同的服务器：SERVER1、SERVER2、SERVER3。
- 单台服务器型号为 PowerEdge R730xd。
- 单台服务器操作系统为 CentOS Linux release 7.6.1810。
- 软件配置包含 GCC 4.8.5、JRE 1.8.0、.net 2.2.105、Python 3.7.0、R 3.5.2、DolphinDB 0.94.2。
- DolphinDB 集群部署在 SERVER1，API 程序运行在 SERVER2 和 SERVER3。
单用户上传到内存表：数据规模、方法与结果解读
该部分描述单用户写入内存表的测试设置、数据规模与批次设置，并给出结果解释与建议。
- 在 SERVER1 创建内存表，SERVER2 运行 API 程序写入该内存表。
- 上传数据集为 45 列，并包含多种数据类型。
- 该场景总上传行数为 100 万行。
- 该场景为单用户，且不涉及磁盘操作。
- 批次越大时，上传次数与网络通信次数减少，性能提升明显。
多用户并发上传到DFS表：并发范围、数据规模与瓶颈分析
该部分描述并发写入 DFS 表的参数设定，并分析网络瓶颈与压缩影响。
- 多用户并发写入目标为 SERVER1 的 DFS 数据表。
- 并发用户范围为 1 到 128。
- 客户端用户数平均分配在 SERVER2 与 SERVER3 运行。
- 该场景通过网络传输并写入磁盘，用于测试 CPU、硬盘与网络资源利用。
- 用户数超过 16 时，网络传输达到极限并成为瓶颈。
多用户并发下载：两种数据集（5年/1周）与IO/缓存影响
该部分给出并发下载的两种数据集场景，并讨论 IO 竞争、分区加载机制与缓存命中对吞吐的影响。
- 数据库部署在 SERVER1，SERVER2 与 SERVER3 多用户同时下载。
- 场景 A 使用 5 年数据，涉及数据量约 12T。
- 在 12T 数据场景下，每次下载需要从磁盘加载数据。
- 场景 B 使用 1 周数据，涉及数据量约 60G。
- 在 60G 数据场景下，数据可在缓存中命中，下载不需要从磁盘加载。
计算并发：分钟K线任务（5年/1周）与并发扩展特性
该部分描述并发提交分钟 K 线计算任务的测试设置，并解释不同并发度下的峰值与回落原因。
- 通过 API 提交并发计算任务：计算某只股票某天的分钟级 K 线。
- 在 5 年与 1 周两种数据集场景下测试并发用户数 1 到 128。
- 5 年数据量为 12T，内存不能完全缓存，预期为 IO 密集型。
- 1 周数据量约 60G，可缓存，预期为计算密集型。
- 5 年数据场景下，64 并发吞吐最大，128 并发吞吐下降。
- 1 周数据场景下，64 并发吞吐接近 7G/秒，128 并发吞吐下降。
总结：各场景关键结论与建议
该部分汇总各场景的关键结论、吞吐峰值、瓶颈来源，并给出与批次大小和硬件配置相关的建议。
- 单用户上传内存表场景给出各语言 API 的峰值吞吐对比结论。
- 并发写入 DFS 场景指出网络在一定并发后成为瓶颈。
- 并发下载 12T 场景指出读磁盘为瓶颈，并发过高会出现 IO 竞争。
- 并发下载 60G 场景指出缓存命中时吞吐可达到网络极限。
- 并发计算场景指出多数时间在服务端计算，各 API 性能基本相当。
Facts Index
| Entity | Attribute | Value | Confidence |
|---|---|---|---|
| 技能认证特训营第二期 | 报名链接 | https://www.qingsuyun.com/h5/e/217471/5/ | high |
| DolphinDB API性能基准测试报告 | 发布日期 | 2021-08-05 | high |
| DolphinDB | 产品定位 | 高性能分布式时序数据库（time-series database），属于列式关系型数据库 | high |
| DolphinDB | 实现语言 | C++ | high |
| DolphinDB | 计算框架 | 内置并行和分布式计算框架 | high |
| DolphinDB | 适用数据类型/场景 | 可用于处理实时数据和海量历史数据 | high |
| DolphinDB | 提供的API语言 | C++、Java、C#、Python、R（并提到除脚本语言外还提供这些API） | high |
| 本文测试范围 | 测试对象 | API接口（C++、Java、C#、Python、R）与DolphinDB交互的性能 | high |
| 性能测试场景 | 场景1 | 单用户上传数据到内存表 | high |
| 性能测试场景 | 场景2 | 多用户并发上传数据到分布式（DFS）数据库 | high |
| 性能测试场景 | 场景3 | 多用户并发从DolphinDB下载数据到客户端 | high |
| 性能测试场景 | 场景4 | 多用户并发发送计算任务（计算某天某个股票的分钟级k线）到DolphinDB，并返回结果 | high |
| 测试服务器数量与命名 | 服务器 | 三台配置相同的服务器：SERVER1、SERVER2、SERVER3 | high |
| 硬件配置（单台服务器） | 主机型号 | PowerEdge R730xd | high |
| 硬件配置（单台服务器） | CPU | E5-2650 24cores 48线程 | high |
| 硬件配置（单台服务器） | 内存 | 512G | high |
| 硬件配置（单台服务器） | 硬盘 | HDD 1.8T * 12 | high |
| 硬件配置（单台服务器） | 网络 | 万兆以太网 | high |
| 硬件配置（单台服务器） | 操作系统 | CentOS Linux release 7.6.1810 | high |
| 软件配置 | C++编译器 | GCC 4.8.5 | high |
| 软件配置 | JRE | 1.8.0 | high |
| 软件配置 | C# | .net 2.2.105 | high |
| 软件配置 | Python | 3.7.0 | high |
| 软件配置 | R | 3.5.2 | high |
| 软件配置 | DolphinDB版本 | 0.94.2 | high |
| 测试框架 | 部署位置 | DolphinDB集群部署在SERVER1；API程序运行在SERVER2和SERVER3，通过网络连接SERVER1上的数据节点进行测试 | high |
| DolphinDB集群配置 | 节点构成 | 集群包含1个控制节点和6个数据节点 | high |
| DolphinDB集群配置 | 内存配置 | 32G/节点 * 6节点 = 192G | high |
| DolphinDB集群配置 | 线程配置 | 8线程/节点 * 6节点 = 48线程 | high |
| DolphinDB集群配置 | 硬盘配置 | 每个节点配置一个独立HDD：1.8T/节点 * 6 = 9.6T | high |
| 单用户上传到内存表测试 | 写入目标 | 在SERVER1的DolphinDB集群上创建内存表；SERVER2运行API程序写入SERVER1内存表 | high |
| 单用户上传数据集 | 字段/列数 | 共45列（包含STRING、INT、LONG、SYMBOL、DOUBLE、DATE、TIME等类型） | high |
| 单用户上传数据集 | 单行大小 | 每行336字节 | high |
| 单用户上传数据集 | 总行数 | 共上传100万行 | high |
| 单用户上传数据集 | 总大小 | 大小约336Mb | medium |
| 单用户上传测试 | 批次范围 | 每次上传10~100000行 | high |
| 单用户上传场景特性 | 不涉及磁盘操作 | 该场景是单用户且不会涉及磁盘操作 | high |
| 单用户上传测试关注点 | 主要测试内容 | 主要测试API程序数据格式到DolphinDB数据格式的转换性能 | high |
| 单用户上传结果解释 | 性能随批次大小变化原因 | 批次越大，上传次数与网络通信次数越少，因此性能提升明显 | high |
| 单用户上传对比结论 | 语言API相对表现 | C++性能最优，C#性能较差 | high |
| Python与R API实现 | 底层实现方式 | Python和R底层实现都是用C++重写 | high |
| Python与R上传建议 | 批次建议 | 建议上传数据时尽量增大上传批次大小（尤其在批次达到1000行以上性能提升明显） | high |
| 并发上传到DFS测试 | 写入目标与客户端位置 | 多用户并发上传数据到SERVER1的DFS数据表；SERVER2和SERVER3上多个用户通过网络发起写入 | high |
| 并发上传到DFS数据集（每用户） | 总行数 | 每个用户共写入500万行 | high |
| 并发上传到DFS数据集（每用户） | 单次写入行数 | 每次写入25000行 | high |
| 并发上传到DFS数据集（每用户） | 单行大小 | 每行336个字节 | high |
| 并发上传到DFS数据集（每用户） | 总数据量 | 每个用户共写入的数据量为840Mb | medium |
| 并发上传到DFS测试 | 并发范围 | 并发用户为1~128 | high |
| 并发上传客户端分配策略 | 分配方式 | 用户数平均分配在SERVER2和SERVER3上运行（例如16用户时两个SERVER各运行8个客户端程序） | high |
| 并发上传到DFS场景特性 | 资源压力来源 | 写入数据通过网络传输到SERVER1并存储到磁盘，可测试CPU、硬盘、网络等资源利用 | high |
| 并发上传结果结论 | 低并发性能差异 | 用户数小于16时，C++、Java性能优势明显，Python和C#稍差，吞吐量基本线性增长 | high |
| 并发上传瓶颈 | 瓶颈条件 | 用户数超过16时网络传输达到极限成为瓶颈，吞吐量基本维持在网络极限 | high |
| 网络极限（万兆以太网） | 极限值与压缩影响 | 网络极限为1G；由于传输数据有压缩，系统吞吐量最大可达1.8G/秒 | medium |
| 并发下载测试 | 部署与连接策略 | 数据库部署在SERVER1；SERVER2和SERVER3多个用户同时下载；每个用户随机选择一个数据节点连接 | high |
| 并发下载数据量（每用户） | 总行数 | 每个用户下载500万行 | high |
| 并发下载数据量（每用户） | 单行大小 | 每行45字节 | high |
| 并发下载数据量（每用户） | 总大小 | 共计225Mb | medium |
| 并发下载测试 | 每次下载行数 | 每次下载25000行 | high |
| 并发下载测试 | 并发范围 | 并发用户数1~128 | high |
| 下载场景A | 数据范围与大小 | 5年数据量：从5年的数据中随机选择date和symbol下载，涉及数据量约12T | high |
| 下载场景A | 缓存/IO特性 | 数据量大大超过系统内存，每次下载需要从磁盘加载数据 | high |
| 下载场景B | 数据范围与大小 | 1周数据量：从最近一周数据中随机选择symbol下载，涉及数据量约60G | high |
| 下载场景B | 缓存/IO特性 | 分配给DolphinDB的内存足以容纳60G数据，数据在缓存中，每次下载不需要从磁盘加载 | high |
| 5年下载总体趋势 | 吞吐增长与上限 | 用户数小于64时吞吐量基本线性增长，API性能差异不大，最大吞吐量在350M左右 | medium |
| 5年下载瓶颈 | 主要瓶颈 | 由于数据集为12T缓存不了，必须从磁盘加载，磁盘成为系统瓶颈 | high |
| 5年下载在128并发时吞吐下降原因 | 原因说明 | 分区加载机制会将整个分区加载到内存再返回所需数据；并发过多且需从磁盘加载导致IO竞争加剧，整体吞吐降低 | high |
| 高并发读优化建议 | 存储配置建议 | 建议各节点尽量配置独立的多个数据卷以提高IO并发能力 | high |
| 1周下载吞吐与网络极限 | 吞吐量上限与原因 | 吞吐量最大达到1.4G左右，达到网络极限（网络极限1G，由于数据压缩实际业务数据量为1.4G） | medium |
| 并发计算任务 | 任务内容与规模 | 通过API提交并发计算任务：计算某只股票某天的分钟级K线；计算总量约1亿条 | high |
| 并发计算测试 | 并发范围与数据场景 | 在5年数据量与1周数据量两种场景下测试并发用户数1~128 | high |
| 并发计算场景（5年） | 数据量与瓶颈预期 | 5年数据量共12T，内存不能全部缓存，几乎每次计算需从磁盘加载，属于IO密集型，预期磁盘为瓶颈 | high |
| 并发计算场景（1周） | 数据量与瓶颈预期 | 1周数据量约60G，数据节点能全部缓存，属于计算密集型，多用户并发时预期CPU为瓶颈 | high |
| 计算并发总体结论（5年数据） | 吞吐趋势与下降原因 | 用户数小于16时吞吐量线性增长；64并发吞吐最大；128并发吞吐下降，原因包括内存不足导致内存/磁盘大量交换与任务调度分发耗时增加 | high |
| 计算并发总体结论（1周数据） | 峰值与下降原因 | 用户数小于64时吞吐量稳定增长；64并发吞吐接近7G/秒；128并发因任务过多超过物理机器线程数（48线程）导致线程切换与调度分发时间增加，吞吐下降 | medium |
| 物理机器线程数（集群所在物理机器） | 线程数 | 48线程 | high |
| 总结：单用户上传到内存表 | 峰值吞吐结论 | C++吞吐量最大能到265兆/秒；Java、Python、R可达160-200兆/秒；C#最大在60兆左右；批次越大吞吐量越高，Python和R更显著 | medium |
| 总结：并发写入DFS表 | 网络瓶颈与最大吞吐 | 达到网络极限前吞吐量随用户数稳定增加；约32并发时网络成为瓶颈，各API性能基本一致；因数据压缩系统最大吞吐量达1.8G/秒 | medium |
| 总结：并发下载（5年12T） | 峰值与瓶颈 | 64并发时最大吞吐量约380兆/秒；需从磁盘加载，读磁盘为瓶颈；128并发时磁盘IO竞争激烈导致吞吐下降 | medium |
| 总结：并发下载（1周约60G） | 缓存与网络极限吞吐 | 6个数据节点可缓存所有数据，数据在内存无需从磁盘加载；吞吐达到网络极限；因压缩原因集群吞吐量为1.8G/秒，并随并发增加稳定提升 | medium |
| 总结：并发计算 | API差异与峰值吞吐 | 网络传输数据量小，大部分时间在server端计算，各API性能基本相当；两种数据量下走势一致，64并发达峰值：5年最大1.3G，1周最大7GB；128并发因任务过多超过48线程导致吞吐下降 | medium |
| 总体结论 | 并发提升下的总体表现 | 通过API进行数据检索、上传、计算等任务时，随着并发度提高性能稳定提升，基本满足大部分业务性能要求 | low |