AnalyticDB for PostgreSQL 黑科技解析 - 列存储 Meta Scan 性能加速

简介: 本文介绍阿里云 AnalyticDB for PostgreSQL(原HybridDB for PostgreSQL) 产品,即 MPP 数据仓库服务,其列存储 meta scan机制,及其对 分析场景的性能提升。

作者:张晓博
2011年毕业于武汉理工大学,曾任职于人大金仓、北大方正信产研究院、百分点等公司,从事数据库内核开发工作,现在任职于阿里云数据库事业部,云化数据仓库服务 AnalyticDB for PostgreSQL 数据库内核开发技术专家。

1. 概述

AnalyticDB for PostgreSQL (原HybridDB for PostgreSQL,以下简称 ADB PG)是阿里云上的MPP数据仓库服务,其内核采用PostgreSQL引擎,基于开源数据库 Greenplum 改造,并在此基础上优化分析性能,其中列存储 metascan 就是提升数据库查询性能的一个关键特性。
ADB PG支持列存储格式,具有较高的数据压缩能力,以及查询性能,但是当针对有较高过滤率的查询条件时,依然要做整列数据读取,或者建 B-Tree 索引,但是索引也有其应用的约束:一是索引无压缩,数据膨胀较严重;二是结果集大的时候,索引代价比 tablescan 高,索引失效等问题。为此 ADB PG 开发了meta scan 功能,具有很好的过滤性能,并且占用的存储空间也基本可以忽略不计。
ADB PG 的meta scan是对列存表的一种加强,通过收集列存表列的max/min,并配合 block offset机制,可以实现类似于索引的过滤功能。meta信息里保存列的每个block的max、min,offset,max/min用于条件过滤,block offset用于跳过不满足过滤条件的block,以达到最大程度的减少列存读取的IO和block解压的CPU消耗,从而实现查询性能的提升。TPC-H 1TB 测试整体提升 29%,对于有高过滤率条件的查询里,可以提升最高5倍性能,比如 TPC-H的 Q06、Q12、Q14、Q15。

2. 列存 metascan的实现

ADB PG的 meta scan 机制类似于开源格式 ORC 或者 PARQUET的元信息,通过meta 信息过滤掉不满足条件的列存 block,来提升性能。
a3

如上图所示,ADB PG的每张列存表的数据分为2部分,一部分是表数据,一部分是meta数据,存储收集的meta信息。在scan的时候,先读取meta数据,根据min、max过滤掉不需要读取的block,通过block offset直接读取满足条件的block,然后把tuple返回给executor,executor计算后,把结果返回给客户端。
ADB PG meta存储格式如下:
metascan2

meta信息按行分为两级meta:row group meta和batch group meta

  • row group meta:
    每张表的meta信息有多个row group meta组成,每个row group meta的max/min反应了连续的1w行的meta信息。每个row group meta包含10个row batch meta,如上图所示,row group的meta为:(min, max) = (1, 4000)。
  • row batch meta:
    每个row batch meta的min/max反应了连续1000个行的meta信息。与row group meta不同的是row batch meta还会记录覆盖的第一行所在的block 的block offset。

metascan 在扫描时,会顺序读取row group meta,如果过滤条件满足当前row group的min/max,则依次遍历每个row batch meta,如果过滤条件满足row batch meta的min/max,则会根据block offset,直接定位到文件中的block,否则扫描下一个row batch meta;如果过滤条件不满足当前的row group,这读取下一个row group meta,如此循环,直到所有的数据遍历完全。
a2
为了简单并且满足事务特性,meta信息我们采用heap表的形式保存,即meta保存到辅助表中。在创建一个列存表时,同时创建meta表。这样通过heap表的mvcc以及事务机制,可以自然的实现meta信息与表数据信息的一致性和原子性。
但是该实现方式有一个问题,按这种方式meta必须覆盖所有的数据,即表上的每一行数据更新,必须更新meta,如果用户使用单条insert这种方式插入数据,则meta信息会被频繁更新,这样既会降低写入的性能又会降低查询是scan meta信息的性能。为解决这个问题,我们把meta 表分成两个primary meta 表和secordary meta 表。随着insert/update主表,meta信息会同步更新到secordary meta表中,当每个row group meta覆盖1w个行时,把meta信息从secordary meta表移动到primary meta表中,查询的时候只查询primary meta表,这样就不会因为主表数据的频繁小量insert/update而导致primary meta膨胀。但是使用这种meta维护方式,scan就需要对primary meta 没有覆盖的行做特殊处理,因此meta scan执行逻辑如下:
a1
meta信息的收集是按segfile来划分的,所以当一个segfile的meta读取完后,需要把该segfile文件尾部的tuple顺序返回给executor。对于primary meta表没有记录的segfile,scan完primary meta后,同样的把这些segfile顺序扫描一遍。这样通过meta scan就可以扫描所有的表数据。

目前的metascan支持如下的数据类型和操作符:

  • 支持的类型:
    Int2/int4/int8
    Float4/float8
    Time/timetz/timestamp/timestamptz
    Varchar/text/bpchar
    cash
  • 支持的操作符
    =、<、<=、>、>=
    and 逻辑运算符

sortkey 是AnalyticDB for PostgreSQL的另一个特性,可以让表按指定的列排序,其用来指定在单分区内数据进行排序。把metascan与sortkey结合使用,可以更有效的提高meta scan执行的性能。如果列的值在数据文件中分布比较分散,即使过滤性比较好,meta scan的执行性能可能不好,因为列的值分散在太多的block内,导致只能跳过极少的block。这种情况就可以在表上创建 sortkey,使得在单分区内数据有序排列,让表按照过滤字段排序,这样相同的值都会集中在一起,这些block都是连续的,这样在执行metascan时,就可以跳过掉大部分block,从而提升扫描的性能。

3. TPC-H测试

TPCH 是一个测试OLAP数据仓库性能的标准测试集,其主要评价指标是各个查询的响应时间,即从提交查询到结果返回所需时间,我们在ADB PG上针对meta scan特性测试对tpch的加速效果,针对tpch 1TB数据HDD硬盘测试,在其中4个表上创建了sortkey:

table name sort key
customer c_mktsegment
part p_brand
lineitem l_shipdate
orders o_orderdate

tpch 测试结果如下:

query metascan tablescan 性能提升 (%)
q01 19.347 11.199 0.00%
q02 55.696 59.996 7.72%
q03 170.492 206.383 21.05%
q04 108.586 129.101 18.89%
q05 160.95 165.855 3.05%
q06 19.564 53.544 173.69%
q07 646.875 629.539 0.00%
q08 153.666 156.489 0.00%
q09 724.835 725.829 0.00%
q10 217.339 248.316 14.25%
q11 30.574 29.692 0.00%
q12 44.796 113.121 152.52%
q13 178.811 199.52 11.58%
q14 12.194 72.635 495.66%
q15 39.285 115.22 193.29%
q16 58.443 64.909 11.06%
q17 1446.869 1394.215 0.00%
q18 1118.851 1110.468 0.00%
q19 212.091 225.613 6.38%
q20 331.7 365.711 10.25%
q21 1027.04 1015.196 0.00%
q22 165.681 167.305 0.00%
Total (GEOMEAN) 163.315 211.372 29.43%

从测试结果看,对于Q03、Q04、Q06、Q10、Q12、Q14、Q15有非常显著的性能提升,最多提升了5倍左右。对于tpch 整体性能,按Geomean算后,有22%的提升。
对于剩余的查询无明显的性能提升。分析这些查询的特性,meta scan对于tpch中有强过滤条件的查询,性能提升较明显,但对于全表scan或者join则没有效果。

4. 既有实例升级 meta scan

对于阿里云 AnalyticDB for PostgreSQL 的现有实例,如何使用新的meta scan机制? meta scan在实现的时候做了存储格式的前向兼容,现有实例通过小版本升级后,如果要使用新的meta scan特性,则需要刷新列存表的 meta 信息,可以使用如下的 UDF 来刷新某张表的meta信息:

CREATE OR REPLACE FUNCTION UPGRADE_AOCS_TABLE_META(tname TEXT) RETURNS BOOL AS 
$$

DECLARE
    tcount INT := 0;
BEGIN
    -- CHECK TABLE NAME
    EXECUTE 'SELECT COUNT(1) FROM PG_AOCSMETA WHERE RELID = ''' || tname || '''::REGCLASS' INTO tcount;
    IF tcount IS NOT NULL THEN
        IF tcount > 1 THEN
            RAISE EXCEPTION 'found more than one table of name %', tname;
        ELSEIF tcount = 0 THEN
            RAISE EXCEPTION 'not found target table in pg_aocsmeta, table name:%', tname;
        END IF;
    END IF;

    EXECUTE 'ALTER TABLE ' || tname || ' SET WITH(REORGANIZE=TRUE)';
    RETURN TRUE;
END;

$$
  LANGUAGE PLPGSQL;

select UPGRADE_AOCS_TABLE_META(tname);

AnalyticDB for PostgreSQL 提供了配置参数rds_enable_column_meta_scan用来启动和关闭metascan,可以使用如下sql启动或者关闭当前session的metascan:

-- disable metascan
set rds_enable_column_meta_scan = off;
-- enable metascan
set rds_enable_column_meta_scan = on;
-- show metascan is enable?
show rds_enable_column_meta_scan;

如果需要实例级别的开启或者关闭metascan,可以提工单联系我们的技术支持同学修改。

5. 结论

ADB PG 的列存储 meta scan主要是通过row group 和batch group的max/min 过滤不满足的block,通过block offset,直接读取满足条件的block,这种方式减少扫描是的IO以及block解压时的CPU消耗,因此在查询的filter具有一定的过滤性时,meta scan可以有比较明显的性能提升。
ADB PG 基于开源数据库PostgreSQL/Greenplum构建,由阿里云数据库 OLAP 数据库团队维护演进,近期会将全部功能增强开源,回馈开源社区。

相关实践学习
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
目录
相关文章
|
存储 SQL 监控
数据中台架构解析:湖仓一体的实战设计
在数据量激增的数字化时代,企业面临数据分散、使用效率低等问题。数据中台作为统一管理与应用数据的核心平台,结合湖仓一体架构,打通数据壁垒,实现高效流转与分析。本文详解湖仓一体的设计与落地实践,助力企业构建统一、灵活的数据底座,驱动业务决策与创新。
|
SQL 缓存 分布式计算
vivo 湖仓架构的性能提升之旅
聚焦 vivo 大数据多维分析面临的挑战、StarRocks 落地方案及应用收益。 在 **即席分析** 场景,StarRocks 使用占比达 70%,查询速度提升 3 倍,P50 耗时从 63.77 秒缩短至 22.30 秒,查询成功率接近 98%。 在 **敏捷 BI** 领域,StarRocks 已完成 25% 切换,月均查询成功数超 25 万,P90 查询时长缩短至 5 秒,相比 Presto 提升 75%。 在 **研发工具平台** 方面,StarRocks 支持准实时数据查询,数据可见性缩短至 3 分钟,查询加速使 P95 延迟降至 400 毫秒,开发效率提升 30%。
vivo 湖仓架构的性能提升之旅
|
存储 缓存 网络协议
阿里云特惠云服务器99元与199元配置与性能和适用场景解析:高性价比之选
2025年,阿里云长效特惠活动继续推出两款极具吸引力的特惠云服务器套餐:99元1年的经济型e实例2核2G云服务器和199元1年的通用算力型u1实例2核4G云服务器。这两款云服务器不仅价格亲民,而且性能稳定可靠,为入门级用户和普通企业级用户提供了理想的选择。本文将对这两款云服务器进行深度剖析,包括配置介绍、实例规格、使用场景、性能表现以及购买策略等方面,帮助用户更好地了解这两款云服务器,以供参考和选择。
|
存储 缓存 负载均衡
阿里云服务器实例选择指南:热门实例性能、适用场景解析对比参考
2025年,在阿里云的活动中,主售的云服务器实例规格除了轻量应用服务器之外,还有经济型e、通用算力型u1、计算型c8i、通用型g8i、计算型c7、计算型c8y、通用型g7、通用型g8y、内存型r7、内存型r8y等,以满足不同用户的需求。然而,面对众多实例规格,用户往往感到困惑,不知道如何选择。本文旨在全面解析阿里云服务器实例的各种类型,包括经济型、通用算力型、计算型、通用型和内存型等,以供参考和选择。
|
运维 API 开发工具
【阿里云】操作系统控制台操作体验与性能评测全解析
操作系统控制台是现代云计算环境中进行系统管理和运维的重要工具,提供系统概览、诊断、观测、管理等功能,支持API、SDK、CLI等管理方式。通过创建角色、系统配置和组件安装等操作,用户可以高效管理云端资源,提升操作系统的使用效率和稳定性。尤其适合需要高效管理操作系统的用户及学习云计算、网络管理的学生。建议增强自定义功能、优化性能报告和完善文档支持,以进一步提升用户体验。
544 21
【阿里云】操作系统控制台操作体验与性能评测全解析
|
存储 机器学习/深度学习 应用服务中间件
阿里云服务器架构解析:从X86到高性能计算、异构计算等不同架构性能、适用场景及选择参考
当我们准备选购阿里云服务器时,阿里云提供了X86计算、ARM计算、GPU/FPGA/ASIC、弹性裸金属服务器以及高性能计算等多种架构,每种架构都有其独特的特点和适用场景。本文将详细解析这些架构的区别,探讨它们的主要特点和适用场景,并为用户提供选择云服务器架构的全面指南。
1440 18
|
存储 弹性计算 安全
阿里云服务器ECS通用型规格族解析:实例规格、性能基准与场景化应用指南
作为ECS产品矩阵中的核心序列,通用型规格族以均衡的计算、内存、网络和存储性能著称,覆盖从基础应用到高性能计算的广泛场景。通用型规格族属于独享型云服务器,实例采用固定CPU调度模式,实例的每个CPU绑定到一个物理CPU超线程,实例间无CPU资源争抢,实例计算性能稳定且有严格的SLA保证,在性能上会更加稳定,高负载情况下也不会出现资源争夺现象。本文将深度解析阿里云ECS通用型规格族的技术架构、实例规格特性、最新价格政策及典型应用场景,为云计算选型提供参考。
|
存储 机器学习/深度学习 人工智能
阿里云服务器第八代通用型g8i实例评测:性能与适用场景解析
阿里云服务器通用型g8i实例怎么样?g8i实例采用CIPU+飞天技术架构,并搭载最新的Intel 第五代至强可扩展处理器(代号EMR),不仅性能得到大幅提升,同时还拥有AMX加持的AI能力增强,以及全球范围内率先支持的TDX机密虚拟机能力。这些特性使得g8i实例在AI增强和全面安全防护两大方面表现出色,尤其适用于在线音视频及AI相关应用。本文将深入探讨g8i实例的产品特性、优势、适用场景及规格族,以帮助您更好地了解这款产品,以供参考和选择。
|
关系型数据库 MySQL OLAP
无缝集成 MySQL,解锁秒级 OLAP 分析性能极限,完成任务可领取三合一数据线!
通过 AnalyticDB MySQL 版、DMS、DTS 和 RDS MySQL 版协同工作,解决大规模业务数据统计难题,参与活动完成任务即可领取三合一数据线(限量200个),还有机会抽取蓝牙音箱大奖!
|
SQL 关系型数据库 OLAP
云原生数据仓库AnalyticDB PostgreSQL同一个SQL可以实现向量索引、全文索引GIN、普通索引BTREE混合查询,简化业务实现逻辑、提升查询性能
本文档介绍了如何在AnalyticDB for PostgreSQL中创建表、向量索引及混合检索的实现步骤。主要内容包括:创建`articles`表并设置向量存储格式,创建ANN向量索引,为表增加`username`和`time`列,建立BTREE索引和GIN全文检索索引,并展示了查询结果。参考文档提供了详细的SQL语句和配置说明。
752 2

热门文章

最新文章

相关产品

  • 云数据库 RDS PostgreSQL 版
  • 推荐镜像

    更多