postgresql|数据库|提升查询性能的物化视图解析

本文涉及的产品
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
云原生数据库 PolarDB MySQL 版,通用型 2核8GB 50GB
简介: postgresql|数据库|提升查询性能的物化视图解析

前言:

我们一般认为数字的世界是一个虚拟的世界,OK,但我们其实有些需求是和现实世界一模一样的,比如,数据库尤其是关系型数据库,希望在使用的数据库能够更快(查询速度),更高(性能上限更高),更强(并发性能,写能力这些属性),正如奥林匹克的体育精神:更快,更高,更强,但是很可惜,愿望就是愿望了,要想实现这样的愿望需要更多的技术,想法。

那么,毫无疑问的,物化视图是一个专门针对查询性能的关系型数据库内的一个对象。

等等,视图?物化视图?

是的,就是物化视图,我只能告诉大家一个残酷的事实(结论先给了,不服气的接着看),物化视图虽然可以对数据库的查询性能起到一个比较大的提升,但物化视图有很大的局限性,也可以简单的理解为物化视图是一个双刃剑,用好了可以使得数据库系统查询速度飞快,用不好可能会造成系统崩溃这样的惨烈后果。

下面,我将就物化视图的优缺点,适用场景,如何使用物化视图做一个简单的介绍。

一,

物化视图是什么?

###注:基表,也就是基础表,查询结果不是凭空出现的,自然是从一个或者N个表内查询得出的结果,一个或者N个表也就省略称之为基表了

物化视图是介于表和视图之间的一个关系型数据库的对象,可以将它想象成一个查询基表产生的结果集,但这个结果集可以很复杂,可以是多表联查的结果集,可以是一个简单的单表查询结果集。

和普通视图相比,更为关键的是,物化视图是有对应的存放于$PGDATA目录下的物理文件,也就是它不是一个虚幻的虚拟的东西了,而是一个真真切切存在的可操作的对象了,这也是为什么叫物化视图的原因了。

那么,很多同学就会有疑问了:普通视图也是一个基于基表的查询而产生的结果集,为毛要用什么物化视图?有毛病吗?

OK,普通视图是无法添加索引的,而我们都知道索引是可以加快查询速度的,也就是基于合适的索引,我们是可以加快查询效率的,因此,一个设计良好的物化视图的查询速度会远远超过一个设计良好的普通视图

和表相比,物化视图仅仅是一个查询结果集,那自然是没有insert,update这些功能了,也就是说,物化视图不可改变其内的数据。

当然,在navicat里,这个物化视图叫实体化视图,目前只需要明白一点,叫什么都无所吊谓的

二,

物化视图的优缺点和适用场景

OK,现在来总结一下物化视图的优缺点

优点:

  1. 提高性能:通过预先计算并存储结果,可以避免在每次查询时都需要执行复杂的联接操作或聚合运算,从而大大提高查询速度。
  2. 减少磁盘空间:由于物化视图只存储部分数据,而不必存储所有基础表的所有数据,因此可以减少磁盘空间的需求。
  3. 支持快速数据刷新:大多数数据库系统都支持物化视图的快速刷新,可以在较短的时间内更新物化视图中的数据,以便及时反映底层数据的变化。
  4. 物化视图可以添加索引,而索引可以有效的提升查询效率

缺点:

  1. 需要额外的存储空间:物化视图需要占用额外的磁盘空间来存储其结果集。
  2. 更新延迟:由于物化视图通常需要定期刷新,因此在底层数据发生变化后,可能需要一段时间才能反映到物化视图中。因此,如果是经常更新的基表,而对物化视图的准确性有较高的要求的情况下,更新需求会是一个不得不考虑的问题,so,建议基表更新太多的基表不建议使用物化视图
  3. 维护复杂性:由于物化视图需要定期刷新,而且在某些情况下还需要执行复杂的计算,因此需要更多的硬件资源提供支持。
  4. 不适合高并发环境:在高并发环境下,如果多个用户同时访问物化视图,可能会出现锁竞争问题,影响性能。主要原因是在刷新或者说同步物化视图这样的操作的时候,会有锁的问题。

由于这些优缺点,因此,可以得出物化视图并不是万能的,很有可能是一个双刃剑,物化视图需要在一个适用的环境下才可以使用。
OK,物化视图的适用场景一般为:

  1. 基表更新不是非常频繁,这个可以有一些时间上的量化,例如,更新条目在分钟级附近。
  2. 相对物化视图来说,并发程度不是太高,多用户同时查询不会影响到物化视图的更新正常完成。
  3. 数据库的硬件条件比较高,可以承担物化视图的频繁更新,主要是CPU和内存能够满足物化视图的刷新任务
  4. 对外提供数据,例如A向B提供数据,A这边按规做好物化视图,并确定合适的刷新物化视图规则,就可以以合规数据形式提供给B了。
  5. 某些复杂查询,应用的频率比较高。

三,

物化视图的创建

CREATE MATERIALIZED view 物化视图名称 as 查询语句 with DATA

说明:with后接data或者no data,no data表示不填充此物化视图,仅仅生成数据结构,默认是with data

下面就以pgbench的一个表pgbench_accounts为例来说明物化视图的创建和管理

创建物化视图

CREATE MATERIALIZED view vvv as SELECT * FROM pgbench_accounts;

查看物化视图:

OK,此时如果基表pgbench_accounts 改变了的话,物化视图vvv并不会跟随改变,因为规定必须是刷新(同步)pgbench_accounts这个表

修改基本的aid等于48的 abalance值为123456789,修改后查询确认是修改了

UPDATE pgbench_accounts set abalance='123456789' WHERE aid='48' 
SELECT * from pgbench_accounts where aid='48'

此时查询物化视图vvv,可以看到aid 48 并没有改变:

手动刷新该物化视图:

refresh MATERIALIZED VIEW  vvv with data;

还一种刷新是不影响现有物化视图使用的,也就是不加锁的并行刷新,如果该物化视图比较大的时候:

REFRESH MATERIALIZED VIEW CONCURRENTLY vvv

但此时这样刷新会报错:

REFRESH MATERIALIZED VIEW CONCURRENTLY vvv
> ERROR:  cannot refresh materialized view "public.vvv" concurrently
HINT:  Create a unique index with no WHERE clause on one or more columns of the materialized view.

此时需要给物化视图添加一个唯一索引,在本例中就给aid添加吧,注意,也是并行添加索引  CONCURRENTLY,:

CREATE UNIQUE INDEX  CONCURRENTLY vvvv ON vvv(aid)

再次查询可以看到物化视图与基表同步了:

 

四,

物化视图的自动刷新

物化视图的自动更新需要安装一些特殊的插件例如Apache iceberg(冰山)或者是自己手动创建触发器函数+触发器这样的形式,本例中是触发器函数+触发器

触发器-函数的创建(触发器 触发后要执行的函数,这里自然是刷新物化视图啦):

CREATE OR REPLACE FUNCTION update_my_view()
RETURNS TRIGGER AS $$
DECLARE
    BEGIN
        -- Update the materialized view here.
        REFRESH MATERIALIZED VIEW  CONCURRENTLY vvv;
        RETURN NULL;
    END;
$$ LANGUAGE plpgsql;

触发器的创建(此触发器是基于基表的哦):

CREATE TRIGGER update_my_view_trigger
AFTER INSERT OR UPDATE OR DELETE ON pgbench_accounts
FOR EACH STATEMENT
EXECUTE PROCEDURE update_my_view();

OK,现在可以验证了,首先,基表更新,aid 48 更新为888888,删除aid 47:

UPDATE pgbench_accounts set abalance='888888' WHERE aid='48' 
DELETE from pgbench_accounts where aid='47'

这个时候查询物化视图,可以看到我们并没有执行刷新命令就可以看到物化视图的改变了:

pgbench=# SELECT * from vvv where aid='47';
 aid | bid | abalance | filler 
-----+-----+----------+--------
(0 rows)
pgbench=# SELECT * from vvv where aid='48';
 aid | bid | abalance |                                        filler                                        
-----+-----+----------+--------------------------------------------------------------------------------------
  48 |   1 |   888888 |                                                                                     
(1 row)

OK,自动刷新物化视图是成功的

五,

物化视图的修改

更改物化视图基本和更改表一样的语法,例如,更改物化视图的名称,这里需要注意,如果有触发器,那么,触发器函数也应该同时更改,否则触发器会报错的哦:

ALTER MATERIALIZED VIEW IF EXISTS  vvv
     RENAME TO vvvvvv
UPDATE pgbench_accounts set abalance='8888882' WHERE aid='48'
> ERROR:  relation "vvv" does not exist
CONTEXT:  SQL statement "REFRESH MATERIALIZED VIEW  CONCURRENTLY vvv"
PL/pgSQL function update_my_view() line 5 at SQL statement

其它的修改就不一一举例了:

ALTER MATERIALIZED VIEW [ IF EXISTS ] name
     action [, ... ]
ALTER MATERIALIZED VIEW name
     DEPENDS ON EXTENSION extension_name
ALTER MATERIALIZED VIEW [ IF EXISTS ] name
     RENAME [ COLUMN ] column_name TO new_column_name
ALTER MATERIALIZED VIEW [ IF EXISTS ] name
     SET SCHEMA new_schema
ALTER MATERIALIZED VIEW ALL IN TABLESPACE name
     [ OWNED BY role_name [, ... ] ]
     SET TABLESPACE new_tablespace [ NOWAIT ]
目录
相关文章
|
6月前
|
存储 缓存 网络协议
阿里云特惠云服务器99元与199元配置与性能和适用场景解析:高性价比之选
2025年,阿里云长效特惠活动继续推出两款极具吸引力的特惠云服务器套餐:99元1年的经济型e实例2核2G云服务器和199元1年的通用算力型u1实例2核4G云服务器。这两款云服务器不仅价格亲民,而且性能稳定可靠,为入门级用户和普通企业级用户提供了理想的选择。本文将对这两款云服务器进行深度剖析,包括配置介绍、实例规格、使用场景、性能表现以及购买策略等方面,帮助用户更好地了解这两款云服务器,以供参考和选择。
|
6月前
|
存储 缓存 负载均衡
阿里云服务器实例选择指南:热门实例性能、适用场景解析对比参考
2025年,在阿里云的活动中,主售的云服务器实例规格除了轻量应用服务器之外,还有经济型e、通用算力型u1、计算型c8i、通用型g8i、计算型c7、计算型c8y、通用型g7、通用型g8y、内存型r7、内存型r8y等,以满足不同用户的需求。然而,面对众多实例规格,用户往往感到困惑,不知道如何选择。本文旨在全面解析阿里云服务器实例的各种类型,包括经济型、通用算力型、计算型、通用型和内存型等,以供参考和选择。
|
3月前
|
SQL 关系型数据库 PostgreSQL
CTE vs 子查询:深入拆解PostgreSQL复杂SQL的隐藏性能差异
本文深入探讨了PostgreSQL中CTE(公共表表达式)与子查询的选择对SQL性能的影响。通过分析两者底层机制,揭示CTE的物化特性及子查询的优化融合优势,并结合多场景案例对比执行效率。最终给出决策指南,帮助开发者根据数据量、引用次数和复杂度选择最优方案,同时提供高级优化技巧和版本演进建议,助力SQL性能调优。
320 1
|
6月前
|
运维 API 开发工具
【阿里云】操作系统控制台操作体验与性能评测全解析
操作系统控制台是现代云计算环境中进行系统管理和运维的重要工具,提供系统概览、诊断、观测、管理等功能,支持API、SDK、CLI等管理方式。通过创建角色、系统配置和组件安装等操作,用户可以高效管理云端资源,提升操作系统的使用效率和稳定性。尤其适合需要高效管理操作系统的用户及学习云计算、网络管理的学生。建议增强自定义功能、优化性能报告和完善文档支持,以进一步提升用户体验。
212 21
【阿里云】操作系统控制台操作体验与性能评测全解析
|
6月前
|
存储 机器学习/深度学习 应用服务中间件
阿里云服务器架构解析:从X86到高性能计算、异构计算等不同架构性能、适用场景及选择参考
当我们准备选购阿里云服务器时,阿里云提供了X86计算、ARM计算、GPU/FPGA/ASIC、弹性裸金属服务器以及高性能计算等多种架构,每种架构都有其独特的特点和适用场景。本文将详细解析这些架构的区别,探讨它们的主要特点和适用场景,并为用户提供选择云服务器架构的全面指南。
785 18
|
6月前
|
存储 弹性计算 安全
阿里云服务器ECS通用型规格族解析:实例规格、性能基准与场景化应用指南
作为ECS产品矩阵中的核心序列,通用型规格族以均衡的计算、内存、网络和存储性能著称,覆盖从基础应用到高性能计算的广泛场景。通用型规格族属于独享型云服务器,实例采用固定CPU调度模式,实例的每个CPU绑定到一个物理CPU超线程,实例间无CPU资源争抢,实例计算性能稳定且有严格的SLA保证,在性能上会更加稳定,高负载情况下也不会出现资源争夺现象。本文将深度解析阿里云ECS通用型规格族的技术架构、实例规格特性、最新价格政策及典型应用场景,为云计算选型提供参考。
|
6月前
|
存储 机器学习/深度学习 人工智能
阿里云服务器第八代通用型g8i实例评测:性能与适用场景解析
阿里云服务器通用型g8i实例怎么样?g8i实例采用CIPU+飞天技术架构,并搭载最新的Intel 第五代至强可扩展处理器(代号EMR),不仅性能得到大幅提升,同时还拥有AMX加持的AI能力增强,以及全球范围内率先支持的TDX机密虚拟机能力。这些特性使得g8i实例在AI增强和全面安全防护两大方面表现出色,尤其适用于在线音视频及AI相关应用。本文将深入探讨g8i实例的产品特性、优势、适用场景及规格族,以帮助您更好地了解这款产品,以供参考和选择。
|
6月前
|
缓存 算法 Oracle
深度干货 | 如何兼顾性能与可靠性?一文解析YashanDB主备高可用技术
数据库高可用(High Availability,HA)是指在系统遇到故障或异常情况时,能够自动快速地恢复并保持服务可用性的能力。如果数据库只有一个实例,该实例所在的服务器一旦发生故障,那就很难在短时间内恢复服务。长时间的服务中断会造成很大的损失,因此数据库高可用一般通过多实例副本冗余实现,如果一个实例发生故障,则可以将业务转移到另一个实例,快速恢复服务。
|
3月前
|
存储 关系型数据库 测试技术
拯救海量数据:PostgreSQL分区表性能优化实战手册(附压测对比)
本文深入解析PostgreSQL分区表的核心原理与优化策略,涵盖性能痛点、实战案例及压测对比。首先阐述分区表作为继承表+路由规则的逻辑封装,分析分区裁剪失效、全局索引膨胀和VACUUM堆积三大性能杀手,并通过电商订单表崩溃事件说明旧分区维护的重要性。接着提出四维设计法优化分区策略,包括时间范围分区黄金法则与自动化维护体系。同时对比局部索引与全局索引性能,展示后者在特定场景下的优势。进一步探讨并行查询优化、冷热数据分层存储及故障复盘,解决分区锁竞争问题。
419 2
|
关系型数据库 分布式数据库 PolarDB
《阿里云产品手册2022-2023 版》——PolarDB for PostgreSQL
《阿里云产品手册2022-2023 版》——PolarDB for PostgreSQL
510 0

推荐镜像

更多