GreenPlum架构之MVCC

Greenplum数据库三大特性:Shared-nothing、Mpp、MVCC。

本文介绍GrrenPlum的MVCC架构。GreenPlum作为分布式数据库,与传统事务型数据库系统通过锁机制来控制并发访问的机制不同, GPDB使用多版本控制(Multiversion Concurrency Control/MVCC)来保证数据一致性。MVCC意味着在查询数据库时,看到的只是数据的快照,可以确保当前的事务不会看到其他事务在相同记录上的修改。据此为数据库的每个事务提供事务隔离。

MVCC以避免给数据库事务显式锁定的方式,最大化减少锁争用以确保多用户环境下的性能。在并发控制方面,使用MVCC而不是使用锁机制的最大优势是, MVCC对查询(读)的锁与写的锁不存在冲突,并且读与写之间从不互相阻塞。

数据库中常见的并发技术有:

  • MVCC- Multi version COncurrency Control 多版本并发控制
  • S2PL-Strict two-phase Locking 严格的两阶段锁
  • OCC-optimistic Concurrency Control 乐观锁

MVCC特点:

  • 每个写操作会创建数据项目的新版本,同时保留旧版本
  • 允许GP在读写的同时仍然提升并发特性
  • 读操作不会阻塞写操作,写操作也不会阻塞读操作

MVCC中快照的概念:

用来跟踪数据库中某个时间点所有事务运行的状态。Greenplum中快照的实现方式是通过在每个数据对象(如行、页、表)上维护多个版本的数据,并每个版本都有一个时间戳。快照只是一个逻辑概念,实际上并没有真正的数据副本。每个事务只是通过时间戳来确定自己所能看到的数据版本,而不是真正地复制一份数据。这样可以节省存储空间,并提高性能。

比如在Read Committed隔离级别下,当前查询可以读取到已提交的事务,但是不能读取到未提交的事务,此时查询开始时生成的快照,使用快照判断事务状态,只读取已提交事务。

Greenplum中表的布局--隐藏字段

创建测试表插入测试数据

--创建测试表
create table test_mvcc(
id int,
name varchar(100)
);
--插入测试数据
insert into test_mvcc 
select gs,'name-'||gs from generate_series(1, 10000) gs;
--
select * from test_mvcc;

隐藏字段解读:

select xmin,xmax,ctid,tm.* from test_mvcc tm where id=1;

--结果为:
xmin	   xmax	   ctid	    id	  name
1823425	   0	   (0,1)	1	  name-1

 字段解释:

  • Xmin:创建Tuple元组的事务ID
  • Xmax:删除Tuple元组的事务ID,有时用于行锁
  • Ctid:指向下一个版本Tuple元组的指针,由两个成员(blockerbumber:offset)组成【 blockerbumber-配置id。offset-item下标,可以唯一标识一个tuple 即唯一一行】

结果解读:

表明该行数据是由1823425事务创建,xmax=0说明没有被删除,不存在的事务。

 快照+可见性-实现MVCC

实验一:删除操作:

在session-1窗口下开启事务,执行删除操作:

begin;
delete from test_mvcc tm where id=1;

在session-1窗口下查询对应数据:

select xmin,xmax,ctid,tm.* from test_mvcc tm where id=1;

--结果为
xmin	xmax	ctid	id	name
1823425	1823755	(0,1)	1	name-1

因为Read Committed隔离级别,未提交事务可见,该行数据仍然存在。但是可以发现xmax字段值更新,表明1823755事务正在删除改行数据,但是未提交或者已经回滚。

实验二:更新操作:

查看初始状况:

select xmin,xmax,ctid,tm.* from test_mvcc tm where id=2;

--结果
xmin	xmax	ctid	id	name
1823066	0	    (0,1)	2	name-2

在session-1窗口下开启事务,执行更新操作:

begin;
update test_mvcc set name = 'test-2' where id=2;
select xmin,xmax,ctid,tm.* from test_mvcc tm where id=2;
--执行结果
xmin	xmax	ctid	 id	 name
1823460	0	    (3,212)	 2	 test-2

同一事务中,可以看数据的xmin变化,并且name已经发生变化。虽然当前事务未提交,但是该事务中可以看到数据变化。

在session-2窗口下执行查询:

select xmin,xmax,ctid,tm.* from test_mvcc tm where id=2;
--查询结果
xmin	xmax	  ctid	 id	 name
1823066	1823460	  (0,1)	 2	 name-2

该行数据的name未发生变化,但是xmax变为1823460事务id,表明1823460事务在修改数据但是未提交或者已回滚。

Greenplum中的并发

并发读一定不会冲突,但是在MVCC架构中如何处理并发写/更新呢?

GreenPlum架构之MVCC_第1张图片

事务并发写时,如果发现事务快照中存在未提交事务,则等待事务完成时在写入。

 MVCC导致的清理需求

由于MVCC使用快照的方式实现了多版本的高并发,在实验二中可以看到更新操作时实际上创建了一个新的元组,所以在大量写操作过后,需要清理旧的元组。可以通过VACUUM执行操作,避免表膨胀的问题。

清理数据的内容:

  • 旧的元组
  • 元组的指针,即指向旧元组的指针
  • 索引项

MVCC引出的其他两个问题:

  • 如何清理表中重复数据?--参考Ctid
  • 如何进行VACUUM表空间的清理

你可能感兴趣的:(架构,数据库,数据库架构,postgresql)