干货丨时序数据库DolphinDB与Aliyun HybridDB for PostgreSQL在金融数据集上的比较

1. 概述

DolphinDB 是一款高性能混合列式数据库和数据分析系统，尤其擅长处理时间序列数据。Aliyun HybridDB for PostgreSQL（以下简称HybridDB）是由阿里巴巴提供的基于开源Greenplum定制的MPP架构企业级通用数据仓库产品。

在本报告中，我们对DolphinDB和HybridDB，在时间序列数据集上进行了性能对比测试。测试涵盖了CSV文件的加载、单个查询的执行、并发查询的执行等三方面。在我们进行的所有测试中，DolphinDB均表现得更出色，主要结论如下：

• 在加载数据的测试中，DolphinDB的速度是HybridDB的3倍
• 在查询的测试中，DolphinDB的速度领先HybridDB约1~2个数量级
• 在并发查询的测试中，DolphinDB仍然保持1个数量级以上的优势，而且随着并发用户的增加，优势更加明显。

本测试仅限于时间序列数据，结论不适用于更为通用的数据领域。

2. 测试环境

DolphinDB部署在5个ecs.r5.large节点上，每个节点基本配置如下：

• 操作系统：Ubuntu 16.04
• 处理器：Intel Xeon Platinum 8163 (2 Cores)
• 内存：16 GB
• 硬盘：150 GB SSD

HybridDB采用2C SSD配置，拥有4个计算节点，每个节点基本配置如下：

• 处理器：2 Cores
• 内存：16 GB
• 硬盘：160 GB SSD

DolphinDB采用1个主节点，4个计算节点，配置8个worker和2个local executor，每个计算节点限制使用12 GB内存。

HybridDB直接使用，不做任何进一步的配置，每个计算节点2个段数据库。经过测试开启Pivotal Query Optimizer时HybridDB表现更差，因此本报告中所有测试都默认只使用Legacy Query Optimizer。

压缩为gzip的CSV数据存放在阿里云OSS服务器上。DolphinDB通过内网获得OSS上的数据后解压并加载，HybridDB直接通过oss协议定义外部表从内网传输、解压并加载OSS上的数据。

3. 数据

我们使用的数据是2007年8月的股票报价数据，大约有65.6亿条记录，每天的数据保存在一个CSV文件中。未压缩的CSV文件有273 GB，压缩为gzip的文件有23 GB。压缩后的数据被上传到阿里云OSS上。

4. 数据加载对比

表4.1是DolphinDB和HybridDB加载CSV文件时各变量数据类型，分区方案如下

• DolphinDB使用date和symbol进行组合分区。根据date产生了23个值分区，根据symbol产生了128个范围分区。分区总数是23*128=2944个。每个分区写入两个副本。
• HybridDB根据symbol散列分布数据，根据date按日期范围分区，在压缩的情况下对symbol施加sort key有不到10%的性能下降，在不压缩的情况下对symbol施加sort key有不到10%的性能上升，随后的测试中都没有使用sort key。

两个平台的数据加载对比结果如表4.2所示，由于DolphinDB和HybridDB都从OSS上获取压缩数据，因此可以认为HybridDB的数据传输和解压时间与DolphinDB基本一致，则HybridDB的数据载入时间可以认为是90-9-12=69分钟。DolphinDB的数据载入速度约为HybridDB的3倍。

表4.1 数据类型对应关系

表4.2 数据处理并载入对比

DolphinDB采用LZ4格式的压缩，HybridDB基于开源Greenplum，不支持QuickLZ格式，因此采用了ZLIB的3级压缩。压缩后的磁盘空间（28G）占用少于DolphinDB（51G）。上表中DolphinDB的空间占用达到了102G是因为有两个副本。

5. 查询性能对比

我们在两个系统中分别测试了8种查询。这些查询涉及数据过滤、排序、分组和聚合，由于DolphinDB与HybridDB的语法有差异，具体查询语句见表5.1。

每条查询需要扫描不同范围的数据，下述8条测试查询覆盖了局部扫描到全表扫描。遗憾的是在HybridDB中对第7条查询支持较差，在系统压力大的情况下会出现内部错误（Unexpected Internal Error），因此在HybridDB的测试中将除去第7条查询。

单个复杂查询的对比结果如表5.2所示，每条查询的测试连续进行2次，表中列出第1次的结果，DolphinDB比HybridDB快3~240倍，并且在缓存的支持下，第1至3条查询缓存后进行的第2次测试用时分别为26ms，16ms和16ms。

从结果中可以看出，第1、3和6条查询是DolphinDB显著领先的，这些查询在where分句中均指定了明确的symbol。回顾两个系统的分区策略，由于HybridDB不支持字符串类型的范围分区，因此涉及到不同的symbol的查询就会因为分区不够灵活而导致部分节点实际扫描的数据远多于目标数据而性能劣化。

表5.1 具体执行的查询语句

表5.2 单独执行每个查询的用时对比

6. 并发性能对比

6.1 多用户并发简单查询

在本节，我们将进行多用户并发查询测试对比。结果表明，即使在多用户并发查询的情况下，DolphinDB仍然比HybridDB更具优势。

我们首先进行简单的select查询并发测试。步骤如下：

（1）我们从2007年8月的股票数据中选择了记录最多的100只股票。这100只股票的记录占了总记录的20%。

（2）建立n（1~32）个数据库连接。每个数据库连接都是并发用户。在每个数据连接中，先从步骤1得到的100只股票中随机选取10只（如AMZN），然后在2007年8月中随机选择一个交易日（如2007年8月21日）来生成简单查询。例如：

select * from quotes where date = 2007.08.21 and symbol="AMZN"

通过n（1~32）个数据库连接，把步骤2生成的10个查询的批处理请求同时发送给数据库。

（3）每个并发用户数量的测试都执行三次，并取平均用时作为结果。

HybridDB集群每个计算节点提供了2个CPU核心，从结果中可以看出，HybridDB在并发用户数每增加2个时，消耗时间显著增加，这是因为HybridDB底层由PostgreSQL实例构成，每条查询只会用到1个CPU核心，当只有奇数个并发用户时另一个核心会处于空闲状态而不会被充分利用起来，导致了资源的浪费。同时HybridDB的MPP架构会将数据分散到各个节点，最后只有拥有相关数据的节点会执行查询，另外的节点会闲置。回顾第5节中的结论，由于简单select查询均涉及symbol，因此HybridDB也会有较大性能瓶颈。

表6.1 多用户并发简单查询用时对比

6.2 多用户并发复杂查询

在多用户并发简单查询的基础上，我们还测试了前述的7个复杂查询（8个复杂查询除去无法在HybridDB上使用的第7条）的并发性能。单用户执行7个查询的耗时，与7个查询单独测试时的耗时累加相接近，符合预期。随着并发用户的增加，DolphinDB对HybridDB的优势同样不断扩大，与并发简单查询的结果吻合。

可以预见，随着并发数量的持续增加，DolphinDB对HybridDB的优势则会不断扩大。

表6.2 多用户并发复杂查询用时对比

7. DolphinDB的性能优势分析

DolphinDB database 对于HybridDB的性能优势来源于多个方面，包括内存管理优化、对字符串处理的优化、算法上的优化等等，但最主要的优势来源于DolphinDB database 基于分布式文件系统的架构设计。

基于Greenplum的HybridDB集群是由一个主节点（master node）和多个承载PostgreSQL实例的计算节点 (segment host node) 组成，采用传统的大规模并行处理（MPP）架构。这种结构设计上十分简洁。写入数据时，主节点确定数据分发方式，随后每个节点并发写入，并将不属于自己的数据传输给其他节点。查询时，主节点会把查询经过优化器处理后分配给计算节点。简单地说，HybridDB在数据存储和计算查询时采用树状结构；而DolphinDB采用更为扁平的网状结构，每个节点不分主次。采用树状结构，容易出现数据分布的不均衡，或者在用户不饱和或查询的数据只存在于部分节点时反而会出现明显的资源闲置和系统瓶颈。

在分区上，HybridDB支持范围分区、值分区和组合分区，但是范围分区只支持数值或时间类型，灵活性不如DolphinDB。DolphinDB database支持值分区、范围分区、散列分区和列表分区等多种分区方案，并且每个表可以根据多个字段进行组合分区，同时范围分区支持字符串等非数值类型。在分区数量上，DolphinDB中的单表支持百万级以上的分区数，分区粒度更细，不易出现数据或查询集中到某几个节点的状况。在执行基于多个列的范围查询或者点查询时，DolphinDB需要扫描的数据块非常少，查询的响应时间更短，并发性更出色。