PostgreSQL技术大讲堂 - 第21讲:行可见性规则

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
简介: 从小白到专家,PostgreSQL技术大讲堂 - 第21讲:行可见性规则

PostgreSQL从小白到专家,是从入门逐渐能力提升的一个系列教程,内容包括对PG基础的认知、包括安装使用、包括角色权限、包括维护管理、、等内容,希望对热爱PG、学习PG的同学们有帮助,欢迎持续关注CUUG PG技术大讲堂。

第21讲:行可见性规则

内容1:PostgreSQL事务id介绍

内容2:PostgreSQL DML操作原理

内容3:事务快照在可见性规则中的作用

内容4:T_xmin状态对于可见性规则判断的重要度

内容5:常见的行可见性规则的介绍

内容6:实现闪回功能


TXID介绍

· 事务id(txid)

当一个事务开始时,PostgreSQL中的事务管理系统会为该事务分配一个唯一标识符,即事务ID(txid).PostgreSQL中的txid被定义为一个32位的无符号整数,也就是说,它能记录大约42亿个事务。通常txid对我们是透明的,但是我们可以利用PostgreSQL内部的函数来获取当前事务的txid。

事务ID用来标识一个事务的先后顺序,该顺序决定了锁申请的优先权,已经访问一张表时对行的可见性规则判断。

testdb=# SELECT txid_current();

txid_current

--------------

100

(1 row)


Tuples Structure

· 元组(行)结构

t_xmin保存插入此元组的事务的txid,它的状态是行可见性判断关键的依据。

t_xmax保存删除或更新此元组的事务的txid。如果此元组未被删除或更新,则t_xmax设置为0,这意味着无效,它的状态也是行可见性判断关键的依据。


DML操作原理

· Insertion

· Deletion

· Update

执行第一个更新命令时,通过将txid 100设置为t_xmax,逻辑上删除Tuple_1,然后插入Tuple_2。然后,将元组1的t_ctid重写为指向元组2。

当执行第二个UPDATE命令时,与第一个UPDATE命令一样,Tuple_2在逻辑上被删除,Tuple_3被插入。


事务状态

· 四种事务状态

IN_PROGRESS

COMMITTED

ABORTED

SUB_COMMITTED


Commit Log

· 事务状态记录方式

事务快照

· 事务快照概述

事务快照是一个数据集,用于存储有关单个事务在某个时间点上是否所有事务都处于活动状态的信息。在这里,活动事务表示它正在进行或尚未启动。txid_current_snapshot的文本表示为“xmin:xmax:xip_list”,组件描述如下:

Xmin:最早仍在活动的txid。所有以前的事务要么提交并可见,要么回滚并停止。

Xmax:第一个尚未分配的txid。截至快照时,所有大于或等于此值的txid尚未启动,此不可见。

xip_list:快照时的活动txid。该列表仅包含xmin和xmax之间的活动txid。

testdb=# SELECT txid_current_snapshot();

txid_current_snapshot

-----------------------

100:104:100,102

(1 row)

例如,在快照'100:104:100,102'中,xmin是'100',xmax是'104',xip_list是'100,102'。


可见性规则世界观

· 事务快照在可见性规则中的意义

富有哲理性的判断规则:过去发生过的为可见,将来未发生的为不可见。


行可见性判断重要因素

· 可见性判断的重要因素

可见性检查规则是一组规则,关键的判断因素有:t_xmin、t_xmax、clog和获取的事务快照确定每个元组是否可见。

T_xmin的三种状态ABORTED、IN_PROGRESS、COMMITTED是判断的第一前提条件。


ABORTED状态

· t_xmin =ABORTED

t_xmin =ABORTED,则判断此行不可见

/* t_xmin status = ABORTED */

Rule 1: IF t_xmin status is 'ABORTED' THEN

RETURN 'Invisible'

END IF


IN_PROGRESS状态

· t_xmin=IN_PROGRESS

t_xmin=IN_PROGRESS,当前事务可见,其它事务不可见

/* t_xmin status = IN_PROGRESS */

IF t_xmin status is 'IN_PROGRESS' THEN

IF t_xmin = current_txid THEN

Rule 2: IF t_xmax = INVALID THEN

RETURN 'Visible'

Rule 3: ELSE /* this tuple has been deleted or updated by the current transaction itself. */

RETURN 'Invisible'

END IF

Rule 4: ELSE /* t_xmin ≠ current_txid */

RETURN 'Invisible'

END IF

END IF


COMMITTED状态

· t_xmin=COMMITTED

t_xmin=COMMITTED,此状态判断时还得看t_xmax的值,如果t_xmax的值为0,则此行可见;如果不为0,那么判断时还得看t_xmax的状态是当前事务还是非当前事务,判断规则就比较复杂。

/* t_xmin status = COMMITTED */

IF t_xmin status is 'COMMITTED' THEN

Rule 5: IF t_xmin is active in the obtained transaction snapshot THEN

RETURN 'Invisible'

Rule 6: ELSE IF t_xmax = INVALID OR status of t_xmax is 'ABORTED' THEN

RETURN 'Visible'

ELSE IF t_xmax status is 'IN_PROGRESS' THEN

Rule 7: IF t_xmax = current_txid THEN

RETURN 'Invisible'

Rule 8: ELSE /* t_xmax ≠ current_txid */

RETURN 'Visible'

END IF

ELSE IF t_xmax status is 'COMMITTED' THEN

Rule 9: IF t_xmax is active in the obtained transaction snapshot THEN

RETURN 'Visible'

Rule 10: ELSE

RETURN 'Invisible'

END IF

END IF

END IF


可见性判断概述

· 可见性判断示例


R6判断规则

· T3 时根据规则6进行判断

Rule6(Tuple_1)Status(t_xmin:199) = COMMITTED ∧ t_xmax = INVALIDVisible

T_xmin=commit,并且t_xman=0,该行对于所有的事务均可见


R7与R2判断规则

· T5时事务ID为200的根据规则7、2进行判断

Rule7(Tuple_1): Status(t_xmin:199) = COMMITTED ∧ Status(t_xmax:200) = IN_PROGRESS ∧ t_xmax:200 = current_txid:200 Invisible

Rule2(Tuple_2): Status(t_xmin:200) = IN_PROGRESS ∧ t_xmin:200 = current_txid:200 ∧ t_xmax = INVAILD Visible

此时块中包含两行数据,对于事务id=200来说,它的判断规则是:

第一行数据根据规则7判断,t_xmin=commit,同时(t_xmax=200)= IN_PROGRESS,并且t_xmax:200为当前事务id,则第一行判断为不可见。

第二行根据规则2判断, t_xmin=commit,同时(t_xmax=200)为当前事务id,并且t_xmax为无效,则该行可见。

testdb=# -- txid 200

testdb=# SELECT * FROM tbl;

name

------

Hyde


R8与R4判断规则

· T5时事务ID为201的根据规则8、4进行判断

Rule8(Tuple_1): Status(t_xmin:199) = COMMITTED ∧ Status(t_xmax:200) = IN_PROGRESS ∧ t_xmax:200 ≠ current_txid:201 Visible

Rule4(Tuple_2): Status(t_xmin:200) = IN_PROGRESS ∧ t_xmin:200 ≠ current_txid:201 Invisible

此时块中包含两行数据,对于事务id=201来说,它的判断规则是:

第一行数据根据规则8判断,t_xmin=commit,同时(t_xmax=200)= IN_PROGRESS,并且t_xmax:200不是当前事务id,则第一行判断为可见。

第二行根据规则2判断, (t_xmax=200)状态为IN_PROGRESS,同时t_xmin不是当前事务id,则该行不可见。

testdb=# -- txid 201

testdb=# SELECT * FROM tbl;

name

--------

Jekyll


R10与R6判断规则

· T7时事务ID为201的根据规则10、6进行判断(READ COMMITED)

Rule10(Tuple_1): Status(t_xmin:199) = COMMITTED ∧ Status(t_xmax:200) = COMMITTED ∧ Snapshot(t_xmax:200) ≠ active Invisible

Rule6(Tuple_2): Status(t_xmin:200) = COMMITTED ∧ t_xmax = INVALID Visible

T7时事务id为200的提交了事务,对于事务id=201来说,它的判断规则是:

第一行根据规则10判断,t_xmin=commit,同时(t_xmax=200)= COMMITTED ,并且Snapshot(t_xmax:200) 状态为非活动,则第一行判断为不可见。

第二行根据规则6判断, (t_xmax=200)状态为COMMITTED ,同时t_xmax为无效,则该行可见。

testdb=# -- txid 201 (READ COMMITTED)

testdb=# SELECT * FROM tbl;

name

------

Hyde


R9与R5判断规则

· T7时事务ID为201的根据规则9、5进行判断(REPEATABLE READ)

Rule9(Tuple_1): Status(t_xmin:199) = COMMITTED ∧ Status(t_xmax:200) = COMMITTED ∧ Snapshot(t_xmax:200) = active Visible

Rule5(Tuple_2): Status(t_xmin:200) = COMMITTED ∧ Snapshot(t_xmin:200) = active Invisible

如果事务的隔离级别是可重复读,那么其判断规则就会发生变化,T7时事务id为200的提交了事务,对于事务id=201来说,它的判断规则是:

第一行根据规则9判断,t_xmin=commit,同时(t_xmax=200)= COMMITTED ,并且Snapshot(t_xmax:200) 状态为活动,则第一行判断为可见。

第二行根据规则5判断, t_xmax=200状态为COMMITTED , Snapshot(t_xmin:200) 为活动,则该行不可见,通过该规则,不会导致幻读发生。

testdb=# -- txid 201 (REPEATABLE READ)

testdb=# SELECT * FROM tbl;

name

--------

Jekyll


提高判断效率

· Hint Bits

由于进行行可见性判断时都要查看存储在clog中t_xmin和t_xmax的状态,为了解决对clog频繁访问这个问题,PostgreSQL使用了提示位,如下所示:

#define HEAP_XMIN_COMMITTED 0x0100 /* t_xmin committed */

#define HEAP_XMIN_INVALID 0x0200 /* t_xmin invalid/aborted */

#define HEAP_XMAX_COMMITTED 0x0400 /* t_xmax committed */

#define HEAP_XMAX_INVALID 0x0800 /* t_xmax invalid/aborted */


实现闪回功能

PostgreSQL由于数据的更新时新旧数据都保留在数据块中,那么如果要实现像Oracle一样的闪回查询功能应该是可以实现的,只要在判断时先判断该查询是否是闪回查询,然后再根据一个针对闪回查询的可见性规则判断就可以实现。

如果实现闪回查询,那么涉及到Vacuum操作时需要考虑更多的因素,需要有一个参数来设置块中被删除的行保留的时间长度。

以上就是【PostgreSQL从小白到专家】第21讲 - 行可见性规则 的内容,欢迎一起探讨交流,往期视频及文档,联系CUUG

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
1月前
|
Cloud Native 关系型数据库 分布式数据库
开发者视角看云原生数据库一体化技术趋势
随着云原生数据库技术的不断发展,一体化数据库解决方案成为技术圈的热点,云原生数据库一体化技术是当前数据库领域的重要趋势,对于开发者而言,学习理解和应对这一趋势,对于业务开发的成功实施非常重要。比如,阿里云瑶池数据库和PolarDB-X等产品通过离在线一体化、处理分析一体化和集中分布一体化等创新理念,引领了数据库领域的新变革。那么本文就来从开发者的角度探讨云原生数据库一体化技术趋势,并分析在业务处理分析一体化、集中式与分布式数据库边界模糊和云原生一体化数据库的选择等方面的影响。
194 4
|
1月前
|
SQL 关系型数据库 分布式数据库
在PolarDB中,行数评估是通过对表的统计数据、基数估计以及算子代价模型来进行估算的。
【2月更文挑战第14天】在PolarDB中,行数评估是通过对表的统计数据、基数估计以及算子代价模型来进行估算的。
86 1
|
2月前
|
关系型数据库 分布式数据库 数据库
阿里云PolarDB登顶2024中国数据库流行榜:技术实力与开发者影响力
近日,阿里云旗下的自研云原生数据库PolarDB在2024年中国数据库流行度排行榜中夺冠,并刷新了榜单总分纪录,这一成就引起了技术圈的广泛关注。这一成就源于PolarDB在数据库技术上的突破与创新,以及对开发者和用户的实际需求的深入了解体会。那么本文就来分享一下关于数据库流行度排行榜的影响力以及对数据库选型的影响,讨论PolarDB登顶的关键因素,以及PolarDB“三层分离”新版本对开发者使用数据库的影响。
82 3
阿里云PolarDB登顶2024中国数据库流行榜:技术实力与开发者影响力
|
1月前
|
SQL 关系型数据库 MySQL
【MySQL技术专题】「问题实战系列」深入探索和分析MySQL数据库的数据备份和恢复实战开发指南(8.0版本升级篇)
【MySQL技术专题】「问题实战系列」深入探索和分析MySQL数据库的数据备份和恢复实战开发指南(8.0版本升级篇)
98 0
|
12天前
|
Java 关系型数据库 MySQL
一套java+ spring boot与vue+ mysql技术开发的UWB高精度工厂人员定位全套系统源码有应用案例
UWB (ULTRA WIDE BAND, UWB) 技术是一种无线载波通讯技术,它不采用正弦载波,而是利用纳秒级的非正弦波窄脉冲传输数据,因此其所占的频谱范围很宽。一套UWB精确定位系统,最高定位精度可达10cm,具有高精度,高动态,高容量,低功耗的应用。
一套java+ spring boot与vue+ mysql技术开发的UWB高精度工厂人员定位全套系统源码有应用案例
|
1月前
|
canal 消息中间件 关系型数据库
【分布式技术专题】「分布式技术架构」MySQL数据同步到Elasticsearch之N种方案解析,实现高效数据同步
【分布式技术专题】「分布式技术架构」MySQL数据同步到Elasticsearch之N种方案解析,实现高效数据同步
90 0
|
1月前
|
SQL 关系型数据库 MySQL
【MySQL技术专题】「问题实战系列」深入探索和分析MySQL数据库的数据备份和恢复实战开发指南(数据恢复补充篇)(一)
【MySQL技术专题】「问题实战系列」深入探索和分析MySQL数据库的数据备份和恢复实战开发指南(数据恢复补充篇)
31 0
|
1月前
|
SQL 关系型数据库 MySQL
【MySQL技术之旅】(7)总结和盘点优化方案系列之常用SQL的优化
【MySQL技术之旅】(7)总结和盘点优化方案系列之常用SQL的优化
71 1
|
1月前
|
Cloud Native OLAP OLTP
如何看待云原生数据库一体化的技术趋势?
面对业务处理分析一体化,开发者需平衡OLTP和OLAP数据库需求。关键在于理解业务目标,选择适合的数据库:OLTP注重高并发、低延迟,如MySQL、PostgreSQL;OLAP侧重复杂查询和数据聚合,如Greenplum、ClickHouse。云原生数据库提供弹性扩展和容灾能力。数据同步、一致性、安全性和合规性也是重要考量因素。开发者应持续关注新技术,以适应不断变化的业务需求。
|
1月前
|
SQL 关系型数据库 分布式数据库
PolarDB常见问题之tbl_order_link_imei的扫描行不是1如何解决
PolarDB是阿里云推出的下一代关系型数据库,具有高性能、高可用性和弹性伸缩能力,适用于大规模数据处理场景。本汇总囊括了PolarDB使用中用户可能遭遇的一系列常见问题及解答,旨在为数据库管理员和开发者提供全面的问题指导,确保数据库平稳运行和优化使用体验。