AnalyticDB PostgreSQL 高性能【基础版】,双倍性能解锁数仓新选择

本文涉及的产品
阿里云百炼推荐规格 ADB PostgreSQL,4核16GB 100GB 1个月
云原生数据仓库AnalyticDB MySQL版,基础版 8ACU 100GB 1个月
简介: 大幅提升IO性能的同时降低近一半存储成本的同时,极大的提升了产品性价比。


高性能【基础版】介绍


云原生数据仓库AnalyticDB PostgreSQL版(下文简称ADB PG)是阿里云数据库团队基于PostgreSQL内核(下文简称PG)打造的一款云原生数据仓库产品。在数据实时交互式分析、HTAP、ETL才、BI报表生成等业务场景,ADB PG都有着独特的技术优势。


对于离线报表分析等公有云典型场景,对数仓的可用性的要求并不苛刻,因此ADB PG推出了单副本形态,在大幅提升IO性能的同时降低近一半存储成本的同时,极大的提升了产品性价比。


核心架构设计

ADB PG高可用版实例采用双副本模式,部署结构如下:


image.png


高性能【基础版】实例相比高可用版实例,master和segment均采用单节点部署,即省略了上图中master node的副本standby node,和所有compute node中primary节点的副本mirror。这样做一方面在compute node上节约了一半的存储空间,并且直接节省了standby node;另一方面,省略了primary和mirror的同步过程,提升了写入场景下的IO能力:


image.png



产品优势介绍


性能优势


高性能【基础版】 采用单副本相比高可用版双副本设计,IO性能有比较明显的提升,2C规格下,最高可达到原有相同规格集群的2.5倍;此外,在含有大量数据写入的场景下,高性能【基础版】节省了向副本进行数据同步和流复制的过程,这种场景下又有额外的接近1倍的IO提升。


对计算节点规格均为2C,节点存储均为400G的高性能【基础版】和高可用版集群进行以下测试:


  1. 大小约为90G的行存表进行本地复制测试:

create table lineitem2 as (select * from lineitem);




基础版(单副本)

高可用版(双副本)

用时(s)

249

1307



本地表CTAS,INSERT INTO SELECT,这类IO密集型场景,提升十分明显,上述场景有5倍性能提升。


  1. TPC-H测试

TPC-H 测试是数据仓库最常用的基准测试之一,包括 22 个SQL(Q1~Q22),主要评价指标是各个查询的执行时间


  • 在计算节点规格均为2C,计算节点存储均为400G,计算节点个数均为4的情况下,对高性能【基础版】和高可用版进行数据集总大小为100G的TPC-H数据集进行基准测试,结果如下(单位:s):

SQL

高可用版(双副本)

高性能【基础版】(单副本)

1

201

108

2

42

36

3

286

182

4

280

212

5

285

163

6

201

78

7

260

192

8

320

152

9

284

175

10

238

162

11

27

20

12

228

111

13

61

67

14

212

92

15

202

79

16

52

43

17.1

667

478

17.2

345

170

18

413

213

19

172

71

20

217

163

21

645

413

22

73

70

sum

5713

3450


image.png


可以看到由于IO性能的提升,相比于高可用版,高性能【基础版】的TPCH基准测试用时降低了40%。


成本优势


高性能【基础版】成本优势主要体现在两方面:第一是相同规格下,节省了一个副本的存储空间,降低了50%的存储成本;另一方面,计算节点在相同算力下降低了价格。



存储价格

计算节点价格

总价格

高性能【基础版】

高可用版

价格下降

高性能【基础版】

高可用版

价格下降

高性能【基础版】

高可用版

价格下降

入门配置价格

100元/月

400元/月

75%

765元/月

1756.3元/月

56.44%

865元/月

2156.3元/月

59.88%

常用配置价格

400元/月

800元/月

50%

2910元/月

3463.96元/月

15.99%

3310元/月

4263.96元/月

22.37%


入门配置为所能购买的最低配置,高性能【基础版】为2C 50G 2计算节点,高可用版为2C 50G 4计算节点。相比高可用版,高性能【基础版】入门价格降低了59%


常用配置下,高性能【基础版】和高可用版均为为4C 100G 4节点。相比高可用版,配置相同的情况下,价格降低了22%


稳定性能力优势


维持高数据可靠性


ADB PG可保证99.99999999%的数据可靠性,即使发生计算节点宕机,也可保证无数据丢失。ADB PG使用阿里云ESSD云盘作为存储介质,ESSD云盘自身采用了三副本技术,故可保证即使在单副本模式下,依然提供超高的数据可靠性,为客户的数据保驾护航。


可用性能力变化


1、WAL和checkpoint

ADB PG中,事务的每次修改数据的操作都必须首先被记录至WAL(Write Ahead Log)文件中。即每次事务提交时,会保证WAL日志已落盘。当数据库需要恢复数据时,可以通过回放WAL日志的方法来恢复已经提交但是尚未写入磁盘的数据库的数据更改。


checkpoint相当于在WAL日志中写入的一个恢复点标记,并将该标记之前的修改全部落盘。数据库恢复数据时,只需要回放到最近一次恢复点即可。ADB PG会定期执行checkpoint操作;当WAL日志过长时,也会自动执行checkpoint进行落盘。


2、Recovery模式


SQL崩溃时,主要是出现coredump或者out of memory等情况,会使ADB PG集群进入recovery模式,recovery模式中,会对残留的锁,内存等执行一些清理工作,并通过回放WAL文件来保证数据的完整性。Recovery期间,集群会暂时无法服务;完成recovery之后,集群会恢复正常。高可用版实例recovery时间大多在5-10min,而高性【基础版】实例通过更改checkpoint机制等方式,recovery的时间可缩短至10s左右。


3、计算节点宕机

高性能【基础版】实例省略了一个副本,必然带来可用性的下降。高可用版的某个计算节点宕机之后,会立刻无缝切换对应副本,集群可以正常运行,宕机的计算节点的角色会切换为副本,在后台被自动重启;而高性能【基础版】实例单个节点宕机会导致整个集群不可用,必须重启整个集群恢复。


4、计算节点宿主机宕机


计算节点宿主机宕机属于比较少见的极端情况,会触发宿主机的自动迁移。对于高可用版实例,仍然可以触发副本自动切换,集群可以正常运行,同时后台自动完成宿主机的迁移;高性能【基础版】实例则需要等待宿主机迁移成功后,再重启恢复集群,这个等待时间一般在15min左右。


ADB PG 高性能【基础版】由于省略了一个副本,在高可用方面出现了一些下降,在物理机宕机等极端情况下,集群恢复的时间变长。但通过ESSD多副本技术,仍保留了完整的数据可靠性,并且通过更改checkpoint机制的方式,减少了recovery的时间。根据以往公共云运行情况,recovery模式为出现概率最大的场景(远大于另外两个场景),而该场景下高性能【基础版】恢复速度当前要优于高可用版。


创建高性能【基础版】实例


可选地域


第一批高性能【基础版】实例覆盖5个核心区域, 用户可在北京可用区I,杭州可用区J,上海可用区L,深圳可用区F,新加坡可用区C 等5个可用区抢先使用。

image.png


选择实例规格


image.png

在首批开通的5个核心可用区中, 在实例系列提供“高性能【基础版】”实例的选项。由于对单点计算能力的加强,ADBPG进一步降低了起步门槛,允许最小的计算节点从2个节点起,综合起步成本降低了59%。


实例系列

高性能【基础版】为单副本实例,高可用版为双副本实例

节点数量(master)

购买实例对应的master数量,最小单位为1。

节点规格(segment)

计算资源单位,不同的计算组规格有不同的内存大小和计算能力.

节点数量(segment)

所购买的“节点”数量,基础版最小单位为2个,高可用版最小单位为4个,节点个数的增加可以线性地提升性能。


配置存储空间置后,可选择想要购买的时长(若有稳定需求,建议购买一年期,享85折优惠),总配置费用一栏会显示当前配置的费用,确认后点击右下角的立即购买,即完成创建!


image.png

总结

高性能【基础版】实例最大程度的适配非核心业务的IO密集型分析场景,大幅降低了产品的入门门槛,使用成本。未来ADB PG将持续深耕性价比,提高用户使用体验。


相关实践学习
AnalyticDB MySQL海量数据秒级分析体验
快速上手AnalyticDB MySQL,玩转SQL开发等功能!本教程介绍如何在AnalyticDB MySQL中,一键加载内置数据集,并基于自动生成的查询脚本,运行复杂查询语句,秒级生成查询结果。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
相关文章
|
6月前
|
存储 关系型数据库 MySQL
PolarDB优势功能
PolarDB优势功能
|
3月前
|
关系型数据库 MySQL 分布式数据库
PolarDB 与传统数据库的性能对比分析
【8月更文第27天】随着云计算技术的发展,越来越多的企业开始将数据管理和存储迁移到云端。阿里云的 PolarDB 作为一款兼容 MySQL 和 PostgreSQL 的关系型数据库服务,提供了高性能、高可用和弹性伸缩的能力。本文将从不同角度对比 PolarDB 与本地部署的传统数据库(如 MySQL、PostgreSQL)在性能上的差异。
232 1
|
6月前
|
监控 关系型数据库 分布式数据库
【PolarDB 开源】PolarDB HTAP 实践:混合事务与分析处理的性能优化策略
【5月更文挑战第21天】PolarDB开源后在HTAP领域表现出色,允许在同一系统处理事务和分析工作负载,提高数据实时性。通过资源分配、数据分区、索引优化等策略提升性能。示例代码展示了创建和查询事务及分析表的基本操作。PolarDB还提供监控工具,帮助企业优化系统并应对业务变化。其HTAP能力为开发者和企业提供了强大支持,推动技术进步,加速数字化时代的业务发展。
435 1
|
3月前
|
关系型数据库 MySQL 分布式数据库
PolarDB 并行查询问题之提升对复杂查询的处理能力如何解决
PolarDB 并行查询问题之提升对复杂查询的处理能力如何解决
24 1
|
5月前
|
SQL 关系型数据库 分布式数据库
PolarDB产品使用问题之如何开启并行查询
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务,旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境,满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能,实现数据库的高效运维与持续优化。
|
SQL Cloud Native 关系型数据库
找不到目标用户?云原生数仓AnalyticDB MySQL秒级圈人功能大揭秘
营销域中的洞察分析/智能圈人/经营报表等场景是OLAP分析型数据库的重要应用场景,阿里云瑶池旗下的云原生数据仓库AnalyticDB MySQL在淘宝、饿了么、菜鸟、优酷、盒马等业务的营销场景有比较长时间的积累和沉淀,我们将通过一系列文章来介绍AnalyticDB MySQL在营销域数据产品中的落地与应用,之前文章介绍了“漏斗分析”的实现与应用,本文主要介绍“秒级圈人&画像分析”的实现与应用。
|
6月前
|
存储 关系型数据库 分布式数据库
阿里云PolarDB解决乐麦多源数据存储性能问题
乐麦通过使用PolarDB数据库,使整个系统之间的数据查询分析更加高效
416 3
|
缓存 关系型数据库 Serverless
数据库内核那些事,PolarDB HTAP Serverless,打造经济易用的实时分析系统
下本从IMCI Serverless核心优势角度的介绍各优化工作内容。
数据库内核那些事,PolarDB HTAP Serverless,打造经济易用的实时分析系统
|
负载均衡 Kubernetes 关系型数据库
更快、更准、更灵活,AnalyticDB MySQL多集群自动弹性技术解析
在全球经济增长放缓的大背景之下,企业在加强数字化建设的过程中,降本增效成为一个绕不开的话题。云原生数仓AnalyticDB MySQL湖仓版(以下简称ADB MySQL) 在发布之初提供了定时弹性功能,帮助业务有规律的客户定时升降配计算资源以节省成本。时隔一年,ADB MySQL针对用户痛点,在今年云栖大会上重磅推出Multi-Cluster弹性资源模式,它具备贴合用户负载、自动配置、性能线性提升等优点,进一步帮用户节省成本,提高计算效率。
|
关系型数据库 测试技术 分布式数据库
PolarDB | PostgreSQL 高并发队列处理业务的数据库性能优化实践
在电商业务中可能涉及这样的场景, 由于有上下游关系的存在, 1、用户下单后, 上下游厂商会在自己系统中生成一笔订单记录并反馈给对方, 2、在收到反馈订单后, 本地会先缓存反馈的订单记录队列, 3、然后后台再从缓存取出订单并进行处理. 如果是高并发的处理, 因为大家都按一个顺序获取, 容易产生热点, 可能遇到取出队列遇到锁冲突瓶颈、IO扫描浪费、CPU计算浪费的瓶颈. 以及在清除已处理订单后, 索引版本未及时清理导致的回表版本判断带来的IO浪费和CPU运算浪费瓶颈等. 本文将给出“队列处理业务的数据库性能优化”优化方法和demo演示. 性能提升10到20倍.
836 4

热门文章

最新文章

相关产品

  • 云原生数据仓库AnalyticDB MySQL版
  • 云原生数据仓库 AnalyticDB PostgreSQL版