HTAP 应用场景实践 | 学习笔记

本文涉及的产品
云原生数据库 PolarDB MySQL 版,通用型 2核4GB 50GB
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
简介: 快速学习 HTAP 应用场景实践,介绍了 HTAP 应用场景实践系统机制, 以及在实际应用过程中如何使用。

开发者学堂课程【7天突破PolarDB for PostgreSQL 2022版HTAP 应用场景实践】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址:https://developer.aliyun.com/learning/course/992/detail/14980


HTAP 应用场景实践


内容介绍:

一、PolarDB for PostgreSQL HTAP 架构基本内容

二、实例实践


一、PolarDB for PostgreSQL HTAP 架构基本内容

这里所说的 HTAP 架构是指数据库是指可以同时应对 OLTP 事务性查询结构和 OLAP 分析性查询请求这样一个混合负载的特性和功能。针对 OLTP 事务性查询是通过主节点进行执行,针对 OLAP 分析性查询是通过分布式并行引擎进行查询加速。

image.png

常见的分布式并行引擎是基于 shared nothing 架构PolarDB 的分布式并行引擎是基于 Shared Storage 架构,也就是共享存储架构。


二、实例实践

利用 PolarDB HTAP 能力加速 TPC-H

1.前期准备

(1)部署 PolarDB PG

在运行前默认已经通过文档《实例部署:基于单机本地存储中部署好本地多节点HTAP 实例,一共1个主节点(运行于5432端口),2个只读节点(运行于5433/5434端口)

可以通过 ps xf 来查询具体的进程

image.png

可以看到,一共有3个进程,一个是主节点的进程,另外两个是只读节点的进程,分别占了5433和5434

然后确保通过 psql 命令进入 postgres 客户端

image.png

(2)生成 TPC-H 测试数据集

TPC-H 是专门测试数据库分析型场景性能的数据集,一共有 22 条分析型场景下的 SQL。用 TPC-H 可以有效测试 PolarDB 的 HTAP 的能力。通过 tpch-dbgen 工具来生成任意大小的数据集。

①下载 tpch-dbgen

可以通过下面这条命令来下载这样一条代码:

gitclone https://github.com/qiuyuhang/tpch-dbgen.git

下载成功:

image.png

编译代码

cd tpch-dbgen

make

编译成功:

image.png

执行如下命令,生成模拟数据:

./dbgen -s 10

注意:建议先按照该命名,从10GB 大小的数据开始体验完本案例后还可尝试 100GB 的数据,即将该命令行中的 10 替换为 100。这里需要注意不要超过本机外存容量。

下面是生成好的数据:

image.png

简单说明一下 tpch-dbgen 里面的各种文件:

后缀为 .tbl 表示生成的表数据;

queries/ 中存放的是 TPC-H 的 22 条 SQL;

含有 explain 的 .sql 文件只打印计划,并不实际执行;

answers/ 中存储了 TPC-H 中 22 条 SQL 的执行结果;

22条具体 SQL 的执行结果

image.png

2.导入数据

# 创建表(一定要进入 tpch-dbgen 目录中)

psql -f dss.ddl(粘贴该命令就可以实现导入数据的目的)

# 进入 psql 命令行

psql

# 导入数据

\copy nation from 'nation.tbl' DELIMITER '|';

\copy region from 'region.tbl' DELIMITER '|';

\copy supplier from 'supplier.tbl' DELIMITER '|';

\copy part from 'part.tbl' DELIMITER '|';

\copy partsupp from 'partsupp.tbl' DELIMITER '|';

\copy customer from 'customer.tbl' DELIMITER '|';

\copy orders from 'orders.tbl' DELIMITER '|';

\copy lineitem from 'lineitem.tbl' DELIMITER '|';

数据导入完成后,逐行执行如下命令,对创建的表设置最大并行度:

# 对需要 PX(并行执行) 查询的表设置最大并行度(若不设置则不会进入 PX 查询)

alter table nation set (px_workers = 100);

alter table region set (px_workers = 100);

alter table supplier set (px_workers = 100);

alter table part set (px_workers = 100);

alter table partsupp set (px_workers = 100);

alter table customer set (px_workers = 100);

alter table orders set (px_workers = 100);

alter table lineitem set (px_workers = 100);

px_workers 表示工作的最大并行度

3. 执行 PostgreSQL 单机并行执行

接下来会进行一个对比,分别对比的是 pg 本身带有的单机并行查询的能力与 px 并行执行的并行查询能力、他们计划的区别和运行时间的区别。在模拟数据导入 pg 后用 qsql 联入。

(1)psql 连入后,执行如下命令,开启计时。

\timing

image.png

(2)通过 max_parallel_workers_per_gather 参数设置单机并行度:

set max_parallel_workers_per_gather=2; -- 并行度设置为 2

(单机并行度与和数有关,和数越多,可以设置的单机并行度越高)

image.png

这里的 set 是可以看对应参数的操作,看参数具体的值可以通过 show 方式查看,上图所示。

(3)执行如下命令,查看执行计划。

\i queries/q18.explain.sql

可以看到如图所示的 2 个并行度的并行计划:

image.png

(4)执行如下 SQL

\i queries/q18.sql

可以看到部分结果和运行时间(10gb 也需要一分多钟的时间运行在数据量大的情况下,可以选择将程序放在后台运行)

image.png

如果想查看更多,可以回车查看更多,不需要则可按  q 退出。

退出可以看到运行时间,下图可知运行时间为1分23秒。

image.png

提示:如果单机并行度太高,可能会出现如下的错误提示:pq: could not resize shared memory segment "/PostgreSQL.2058389254" to 12615680 bytes: No space left on device。原因是 Docker 预设的 shared memory 空间不足,可以设置参数并重启 Docker 进行解决参考链接:https://stackoverflow.com/questions/56751565/pq-could-not-resize-shared-memory-segment-no-space-left-on-device

4.执行 跨机并行查询,并进行耗时对比

在体验完单机并行查询后,开启 PolarDB HTAP 的并行执行,在单机上重新体验一下查询性能。

(1)在 psql 后,执行如下命令,开启计时(若已开启,可跳过)。

\timing

(2)执行如下命令,开启跨机并行查询(PX)。

set polar_enable_px=on;

(3)设置每个节点的并行度为 1。

每个节点并行度:

每个节点有一个读写节点和两个只读节点,因为这里是单机的,如果是分布式的话,这里具体的两个只读节点代表两台 slot ,每台 slot 上可以设置并行度,如果是1的话,就是每台并行度只启一个 work 来并行执行,如果是2的话,每台机器有2个 work ,一共就是4个 work来执行。这是原来单机并行不具备的能力,原来的 pg 只能在单机上并行,不具有分布式的能力,但是可以扩展到多机来执行并行

set polar_px_dop_per_node=1;
image.png

查看两个参数是否设置成功

Show polar_enable_px;

Show polar_px_dop_per_node;

image.png

4、执行如下命令,查看执行计划。

\i queries/q18.explain.sql

该引擎集群带有 2 个 RO 节点,开启 PX 后默认并行度为 2x1=2 个:

image.png 

PX Hash 就是以 hash 的方式把两个节点所查询到的数据分散到其他两个节点上。

Coordinator 指具体的意思,Coordinator 2:1 是会收集两个节点到主节点上。

PolarDB PX Optimizer 说明生成了分布式计划,可以通过分布式计划来执行一共跨机并行查找。

5、执行 SQL:

\i queries/q18.sql

可以看到部分结果(按 q 不查看全部结果)和运行时间,运行时间为 1 分钟,比单机并行的结果降低了 27.71% 的运行时间。感兴趣的同学也可加大并行度或者数据量查看提升程度。

image.png跨机并行查询会去获取全局一致性视图,因此得到的数据是一致的,无需担心数据正确性。可以通过如下方式手动设置跨机并行查询的并行度:

set polar_px_dop_per_node = 1;

\i queries/q18.sql

set polar_px_dop_per_node = 2;

\i queries/q18.sql

set polar_px_dop_per_node = 4;

\i queries/q18.sql

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
23天前
|
SQL 存储 分布式计算
数据仓库的性能问题及解决之道
随着数据量的增长和业务复杂度的提升,数据仓库性能问题日益凸显,如查询慢、跑批不完等。传统解决方案如集群、预计算和优化引擎虽有一定效果,但成本高、灵活性差或性能提升有限。esProc SPL 提供了一种新的解决思路,通过非 SQL 的计算体系,结合高性能算法和优化的数据存储,实现更高效的数据处理,尤其适用于复杂计算场景。
|
SQL 分布式计算 运维
开源大数据 OLAP 引擎最佳实践 | 学习笔记(二)
快速学习开源大数据 OLAP 引擎最佳实践
开源大数据 OLAP 引擎最佳实践 | 学习笔记(二)
|
5月前
|
存储 关系型数据库 大数据
PolarDB 大数据处理能力及其应用场景
【8月更文第27天】随着数据量的爆炸性增长,传统的数据库系统面临着存储和处理大规模数据集的挑战。阿里云的 PolarDB 是一种兼容 MySQL、PostgreSQL 和高度可扩展的关系型数据库服务,它通过其独特的架构设计,能够有效地支持海量数据的存储和查询需求。
126 0
|
7月前
|
存储 SQL 数据库
数据库技术探索:基础架构、应用场景与未来展望
一、引言 数据库技术是信息时代的基石,为企业和组织提供了数据存储、检索、分析和管理的核心支撑
|
8月前
|
存储 运维 监控
大数据分析平台之 OLAP 架构的最佳实践
本文将分享聚水潭云原生 OLAP 架构的最佳实践。
|
存储 分布式计算 Oracle
OLAP架构及技术实现的演进简介
这个阶段中,OLAP主要基于以Oracle、MySQL为代表的一众关系型数据实现。在ROLAP架构下,直接使用这些数据库作为存储与计算的载体。在MOLAP架构下,则借助物化视图的形式实现各数据操作。但难以解决的问题是,不论是ROLAP还是MOLAP,在数据体量大、维度数目多的情况下都存在严重的性能问题。
614 0
OLAP架构及技术实现的演进简介
|
SQL 消息中间件 分布式计算
开源大数据 OLAP 引擎最佳实践 | 学习笔记(一)
快速学习开源大数据 OLAP 引擎最佳实践
开源大数据 OLAP 引擎最佳实践 | 学习笔记(一)
|
关系型数据库 MySQL
《如何支撑HTAP场景-HybridDB for MySQL系统架构和技术演进》电子版地址
如何支撑HTAP场景-HybridDB for MySQL系统架构和技术演进
67 0
《如何支撑HTAP场景-HybridDB for MySQL系统架构和技术演进》电子版地址
|
SQL 存储 大数据
kudu入门_应用场景_方案二|学习笔记
快速学习kudu入门_应用场景_方案二
108 0
kudu入门_应用场景_方案二|学习笔记
|
SQL 消息中间件 存储
Kudu入门_应用场景_方案一|学习笔记
快速学习Kudu入门_应用场景_方案一
115 0
Kudu入门_应用场景_方案一|学习笔记