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须要扫描的数据块非常少，查问的响应工夫更短，并发性更杰出。