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

42次阅读

共计 3689 个字符,预计需要花费 10 分钟才能阅读完成。

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

正文完
 0