DolphinDB与Aliyun HybridDB for PostgreSQL在金融数据集上的比较
文章提供标题信息，并标注作者署名与发布日期。
Source: https://dolphindb.cn/blogs/53
What this page covers
- 两款产品定义、测试范围、主要结论与适用范围限制。
- 测试环境配置与数据来源/载入方式设置。
- 金融时间序列数据集的时间范围与数据规模说明。
- 数据加载对比：分区/分布策略、载入耗时推断、压缩与空间占用。
- 查询性能对比：覆盖的查询类型、HybridDB限制、分区影响解释。
- 并发性能对比：并发测试方法、现象与原因、复杂查询并发结论。
- 性能优势原因分析：架构形态与分区能力差异。
技能认证特训营第二期报名促销
页面顶部提供活动通知与报名引导信息。
- 该区块用于引导用户报名。
- 该区块强调活动相关的福利或优惠信息。
DolphinDB与Aliyun HybridDB for PostgreSQL在金融数据集上的比较（标题、作者与日期）
该部分给出文章标题，并提供作者署名与发布日期。
- 发布日期为 2021-08-05。
- 作者署名为 Junxi。
概述与主要结论
该部分定义两款产品，并概述在时间序列数据集上的对比测试范围、主要结论与适用范围限制。
- DolphinDB 被描述为高性能混合列式数据库与数据分析系统，擅长时间序列数据。
- HybridDB 被描述为基于开源 Greenplum 定制的 MPP 架构数据仓库产品。
- 测试覆盖 CSV 文件加载、单个查询执行与并发查询执行。
- 总体结论表述为：所有测试中 DolphinDB 表现更出色。
- 结论适用范围被限定为时间序列数据场景。
测试环境
该部分描述两平台部署配置、资源限制、优化器选择，以及数据存放与载入方式。
- DolphinDB 部署在 5 个 ecs.r5.large 节点上。
- DolphinDB 测试节点操作系统为 Ubuntu 16.04。
- DolphinDB 集群为 1 个主节点与 4 个计算节点。
- HybridDB 测试默认使用 Legacy Query Optimizer。
- 测试数据以 gzip 压缩 CSV 存放在阿里云 OSS，并通过内网传输、解压与加载。
数据集说明
该部分说明金融时间序列数据的时间范围、记录规模与文件大小，并描述按日文件组织方式。
- 数据集为 2007 年 8 月的股票报价数据。
- 数据规模约为 65.6 亿条记录。
- CSV 未压缩大小为 273 GB。
- gzip 压缩后大小为 23 GB。
- 数据按天存放，每天一个 CSV 文件。
数据加载对比（分区方案、载入耗时与压缩/空间）
该部分对比两平台的数据分区/分布策略、载入耗时推断，以及压缩格式与磁盘空间占用差异。
- DolphinDB 使用 date 与 symbol 组合分区，总分区数为 2944。
- DolphinDB 每个分区写入两个副本。
- HybridDB 按 symbol 散列分布，并按 date 范围分区。
- 文中推断 HybridDB 载入时间可视为 69 分钟。
- 压缩后空间占用对比：HybridDB 为 28G，DolphinDB 为 51G。
查询性能对比（单查询、缓存与分区影响）
该部分对比多类查询的单次执行表现与缓存后耗时，并讨论分区策略对性能的影响与限制。
- 查询测试覆盖 8 种查询，包含过滤、排序、分组与聚合。
- HybridDB 在系统压力大时可能出现内部错误，测试中排除第 7 条查询。
- 单个复杂查询对比中，DolphinDB 比 HybridDB 快 3~240 倍。
- 缓存后，查询 1~3 的第 2 次用时分别为 26ms、16ms、16ms。
- DolphinDB 显著领先的查询编号包括第 1、3、6 条。
并发性能对比（简单查询与复杂查询）
该部分描述并发测试方法与并发下的现象，并给出原因解释与复杂查询并发结论。
- 并发测试建立 n（1~32）个数据库连接，每个连接代表一个并发用户。
- 并发简单查询从记录最多的 100 只股票中选择，约占总记录的 20%。
- 每个连接随机选取 10 只股票与一个交易日生成简单查询。
- 通过 n 个连接把生成的 10 个查询批处理请求同时发送到数据库。
- 每个并发用户数量的测试执行三次，并取平均用时作为结果。
- HybridDB 中每条查询只会用到 1 个 CPU 核心。
- 并发复杂查询结论：并发用户增加时，DolphinDB 的优势扩大。
DolphinDB的性能优势分析（架构与分区能力）
该部分从架构形态与分区能力差异解释性能优势来源。
- HybridDB 集群包含主节点与多个承载 PostgreSQL 实例的计算节点。
- HybridDB 被描述为传统 MPP 架构，存储与计算采用树状结构。
- DolphinDB 被描述为更扁平的网状结构，各节点不分主次。
- HybridDB 的范围分区只支持数值或时间类型。
- DolphinDB 支持多种分区方案，且范围分区支持字符串等非数值类型。
Facts Index
| Entity | Attribute | Value | Confidence |
|---|---|---|---|
| 文章 | 发布日期 | 2021-08-05 | high |
| 文章 | 作者署名 | Junxi | high |
| DolphinDB | 产品定位/描述 | 高性能混合列式数据库和数据分析系统，尤其擅长处理时间序列数据 | medium |
| Aliyun HybridDB for PostgreSQL（HybridDB） | 产品定位/描述 | 阿里巴巴提供的、基于开源 Greenplum 定制的 MPP 架构企业级通用数据仓库产品 | medium |
| 对比测试范围 | 测试内容 | 在时间序列数据集上进行性能对比测试，涵盖 CSV 文件加载、单个查询执行、并发查询执行 | high |
| 对比测试总体结论 | 总体表现 | 所有测试中 DolphinDB 均表现更出色 | medium |
| 数据加载测试（DolphinDB vs HybridDB） | 速度倍数 | DolphinDB 的速度是 HybridDB 的 3 倍 | high |
| 查询测试（DolphinDB vs HybridDB） | 速度领先幅度 | DolphinDB 领先 HybridDB 约 1~2 个数量级 | high |
| 并发查询测试（DolphinDB vs HybridDB） | 性能优势 | DolphinDB 仍保持 1 个数量级以上优势，且并发用户增加时优势更明显 | medium |
| 结论适用范围 | 适用限制 | 本测试仅限于时间序列数据，结论不适用于更为通用的数据领域 | high |
| DolphinDB 测试部署 | 节点规格 | 部署在 5 个 ecs.r5.large 节点上 | high |
| DolphinDB 测试节点 | 操作系统 | Ubuntu 16.04 | high |
| DolphinDB 测试节点 | 处理器 | Intel Xeon Platinum 8163 (2 Cores) | high |
| DolphinDB 测试节点 | 内存 | 16 GB | high |
| DolphinDB 测试节点 | 硬盘 | 150 GB SSD | high |
| HybridDB 测试部署 | 配置/节点数 | 采用 2C SSD 配置，拥有 4 个计算节点 | high |
| HybridDB 测试计算节点 | 处理器 | 2 Cores | high |
| HybridDB 测试计算节点 | 内存 | 16 GB | high |
| HybridDB 测试计算节点 | 硬盘 | 160 GB SSD | high |
| DolphinDB 集群角色与资源限制 | 节点与执行资源 | 1 个主节点、4 个计算节点；配置 8 个 worker 和 2 个 local executor；每个计算节点限制使用 12 GB 内存 | high |
| HybridDB 测试设置 | 优化器选择 | 开启 Pivotal Query Optimizer 时表现更差；报告中默认只使用 Legacy Query Optimizer | high |
| HybridDB 测试设置 | 每计算节点段数据库数量 | 每个计算节点 2 个段数据库 | high |
| 数据源与载入方式 | CSV 数据存放位置与获取方式 | 压缩为 gzip 的 CSV 数据存放在阿里云 OSS；DolphinDB 通过内网获取后解压并加载；HybridDB 通过 oss 协议定义外部表从内网传输、解压并加载 | high |
| 测试数据集 | 时间范围 | 2007 年 8 月的股票报价数据 | high |
| 测试数据集 | 记录数 | 约 65.6 亿条记录 | high |
| 测试数据集 CSV 文件 | 未压缩大小 | 273 GB | high |
| 测试数据集 CSV 文件 | gzip 压缩后大小 | 23 GB | high |
| 测试数据集文件组织 | 按日存储方式 | 每天的数据保存在一个 CSV 文件中 | high |
| 数据加载分区方案（DolphinDB） | 分区键与分区数量 | 使用 date 和 symbol 组合分区；date 产生 23 个值分区；symbol 产生 128 个范围分区；分区总数 23*128=2944；每个分区写入两个副本 | high |
| 数据加载分区/排序设置（HybridDB） | 分布/分区与 sort key 使用 | 根据 symbol 散列分布数据，根据 date 按日期范围分区；测试中未使用 sort key（因其在压缩/不压缩情况下带来不到 10% 的性能变化） | high |
| HybridDB 数据载入时间推断 | 计算方式与结果 | 可认为数据传输与解压时间与 DolphinDB 基本一致，因此载入时间可认为是 90-9-12=69 分钟 | medium |
| 数据载入速度对比（DolphinDB vs HybridDB） | 速度倍数 | DolphinDB 数据载入速度约为 HybridDB 的 3 倍 | high |
| DolphinDB | 压缩格式 | 采用 LZ4 格式的压缩 | high |
| HybridDB（基于开源 Greenplum） | 不支持的压缩格式 | 不支持 QuickLZ 格式 | high |
| HybridDB | 压缩方式 | 采用 ZLIB 的 3 级压缩 | high |
| 压缩后磁盘空间占用对比 | HybridDB 压缩后占用 | 28G（少于 DolphinDB 的 51G） | high |
| 压缩后磁盘空间占用对比 | DolphinDB 压缩后占用 | 51G | high |
| DolphinDB 空间占用解释 | 双副本影响 | 表中 DolphinDB 空间占用达到 102G 是因为有两个副本 | high |
| 查询性能测试 | 查询数量与类型覆盖 | 分别测试 8 种查询，涉及过滤、排序、分组和聚合；覆盖局部扫描到全表扫描 | high |
| HybridDB 对第 7 条查询的支持 | 问题表现 | 系统压力大时会出现内部错误（Unexpected Internal Error），因此 HybridDB 测试中除去第 7 条查询 | high |
| 单个复杂查询性能（DolphinDB vs HybridDB） | 加速倍数范围 | DolphinDB 比 HybridDB 快 3~240 倍 | high |
| 单个复杂查询测试方法 | 重复次数与取值 | 每条查询连续进行 2 次，表中列出第 1 次结果 | high |
| DolphinDB 缓存后第 2 次测试用时（查询 1~3） | 用时 | 分别为 26ms、16ms、16ms | high |
| DolphinDB 显著领先的查询编号 | 查询编号 | 第 1、3、6 条查询 | high |
| DolphinDB 显著领先查询的共同点 | where 条件特征 | where 分句中均指定了明确的 symbol | high |
| HybridDB 分区能力 | 范围分区对字符串的支持 | 不支持字符串类型的范围分区 | high |
| HybridDB 在涉及不同 symbol 查询时的性能原因解释 | 原因 | 分区不够灵活导致部分节点实际扫描的数据远多于目标数据而性能劣化 | medium |
| 并发简单查询测试数据选择 | 股票选择规则 | 从 2007 年 8 月股票数据中选择记录最多的 100 只股票；这 100 只股票记录占总记录的 20% | high |
| 并发简单查询测试方法 | 并发连接数 | 建立 n（1~32）个数据库连接，每个连接代表一个并发用户 | high |
| 并发简单查询测试方法 | 单连接生成查询方式 | 每个连接从 100 只股票中随机选取 10 只，并在 2007 年 8 月随机选择一个交易日生成简单查询 | high |
| 并发简单查询示例 | SQL 示例 | select * from quotes where date = 2007.08.21 and symbol="AMZN" | high |
| 并发简单查询测试方法 | 请求发送方式 | 通过 n（1~32）个连接，将生成的 10 个查询的批处理请求同时发送给数据库 | high |
| 并发简单查询测试方法 | 重复次数与统计口径 | 每个并发用户数量的测试执行三次，取平均用时作为结果 | high |
| HybridDB 集群计算节点资源 | CPU 核心数 | 每个计算节点提供 2 个 CPU 核心 | high |
| HybridDB（由 PostgreSQL 实例构成） | 单查询 CPU 利用限制 | 每条查询只会用到 1 个 CPU 核心 | high |
| HybridDB 并发耗时变化现象 | 随并发增加的趋势 | 并发用户数每增加 2 个时，消耗时间显著增加 | medium |
| HybridDB 资源浪费原因（并发奇数用户） | 原因 | 只有奇数个并发用户时另一个核心会处于空闲状态，导致资源浪费 | medium |
| HybridDB MPP 架构并发查询执行特性 | 节点利用情况 | 数据分散到各节点后，最终只有拥有相关数据的节点会执行查询，其他节点会闲置 | medium |
| 并发简单查询与分区瓶颈关系（HybridDB） | 瓶颈来源 | 简单 select 查询涉及 symbol，HybridDB 会有较大性能瓶颈（关联第 5 节结论） | medium |
| 并发复杂查询测试设置 | 查询数量 | 测试前述 7 个复杂查询（8 个复杂查询除去在 HybridDB 上无法使用的第 7 条） | high |
| 并发复杂查询单用户耗时验证 | 与单独测试关系 | 单用户执行 7 个查询的耗时与 7 个查询单独测试耗时累加相接近，符合预期 | medium |
| 并发复杂查询结论 | 优势趋势 | 随着并发用户增加，DolphinDB 对 HybridDB 的优势不断扩大，与并发简单查询结果吻合 | medium |
| 并发数量继续增加的预期 | 趋势判断 | 可预见随着并发数量持续增加，DolphinDB 对 HybridDB 的优势会不断扩大 | low |
| DolphinDB 性能优势来源（概述） | 来源 | 包括内存管理优化、字符串处理优化、算法优化等，但最主要来源于基于分布式文件系统的架构设计 | medium |
| HybridDB（基于 Greenplum 的集群） | 集群组成 | 由一个主节点（master node）和多个承载 PostgreSQL 实例的计算节点（segment host node）组成 | high |
| HybridDB | 架构类型 | 传统大规模并行处理（MPP）架构；数据存储和计算查询采用树状结构 | medium |
| DolphinDB | 架构形态 | 采用更为扁平的网状结构，每个节点不分主次 | medium |
| 树状结构的潜在问题（对比解释） | 影响 | 容易出现数据分布不均衡；用户不饱和或查询数据只在部分节点时会出现资源闲置和系统瓶颈 | medium |
| HybridDB | 支持的分区类型 | 支持范围分区、值分区和组合分区 | high |
| HybridDB | 范围分区类型限制 | 范围分区只支持数值或时间类型 | high |
| DolphinDB | 支持的分区方案 | 支持值分区、范围分区、散列分区和列表分区等多种方案；每个表可按多个字段进行组合分区；范围分区支持字符串等非数值类型 | high |
| DolphinDB | 单表支持的分区数量级 | 支持百万级以上的分区数 | medium |
| DolphinDB 分区粒度对性能的影响（解释性结论） | 效果 | 分区粒度更细，不易出现数据或查询集中到少数节点；多列范围查询或点查询需要扫描的数据块更少，响应更短，并发性更出色 | medium |