PostgreSQL中MVCC实现机制

MVCC原理

多版本并发控制（Multi-Version Concurrency Control，MVCC），是数据库中并发访问数据时保证数据一致性的一种方法。

在并发操作中，当正在写时，如果有用户在读，这时写可能只写了一半，如一行的前半部分刚写入，后半部分还没有写入，这时可能读的用户读取到的数据行的前半部分数据是新的，后半部分数据是原来的，这就导致了数据一致性问题。

解决这个问题的最简单的方法是使用读写锁，写的时候不允许读，正在读的时候也不允许写，但这种方法会导致读和写的操作不能并发执行。

于是，有人想到了一种能够让读写并发执行的方法，这种方法就是MVCC。

MVCC方法是写数据时，原数据并不删除，并发的读还能读到原数据，这样就不会有数据一致性问题了。

实现MVCC的方法有以下两种：

  • 第一种：写新数据时，把原数据移到一个单独的位置，如回滚段中，其他用户读数据时，从回滚段中把原数据读出来。

  • 第二种：写新数据时，原数据不删除，而是把新数据插入进来。

PostgreSQL数据库使用的是第二种方法，而Oracle数据库和MySQL数据库中的InnoDB引擎使用的是第一种方法。

PostgreSQL中的多版本并发控制

PostgreSQL中的多版本实现是通过把原数据留在数据文件中，新插入一条数据来实现多版本的功能的。

每张表上都有4个系统字段”xmin””xmax””cmin””cmax”，这4个字段就是为多版本的功能而添加的。

字段 类型 含义
xmin xid 插入该行的事务ID（行的”出生证明”）
xmax xid 删除/更新该行的事务ID（0表示未被删除）
cmin cid 插入该行的命令序号（同一事务内的第几条语句）
cmax cid 删除该行的命令序号（同一事务内）
ctid tid 表示表内的物理位置（第一个数字表示数据行所在的物理块的物理块号，第二个数字表示数据行在物理块中的行号）

xmin、xmax、cmin、cmax这4个字段在多版本实现中用于控制数据行是否对用户可见。

PostgreSQL将修改前后的数据存储在相同的结构中，分为以下几种情况：

  • 新插入一行时，将新插入行的xmin填写为当前的事务ID，xmax填”0”。

  • 修改这一行时，实际上新插入一行，原数据行上的xmin不变，xmax改为当前的事务ID，新数据行上的xmin填为当前的事务ID，xmax填”0”。

如下图所示，lp=2 和 lp=3 的 t_ctid 都是 (0,3)。这说明 UPDATE 操作产生的新旧版本共享同一个 ctid 槽位引用（新版本指向自身，旧版本的 t_ctid 在 UPDATE 时未被修改），但它们是两个独立的物理元组，通过 xmin/xmax 形成版本链。

通过 pageinspect 插件直接读取页面原始内容查看旧行数据：

1
2
3
4
5
6
7
8
9
SELECT
 lp, -- 行指针编号 (Line Pointer)
 t_ctid, -- 元组的 ctid
 t_xmin, -- 插入事务ID
 t_xmax, -- 删除/更新事务ID
 t_infomask2, -- 属性标志位（含 cmin/cmax）
 t_hoff, -- 头部长度
 t_data -- 原始用户数据（bytea 十六进制）
FROM heap_page_items(get_raw_page('t1', 0));

  • 删除一行时，把被删除行上的xmax填写当前的事务ID，xmax不等于0不一定是死元组。

从上面的叙述中就可以知道，xmin就是标记插入数据行的事务ID，而xmax就是标记删除数据行的事务ID。没有修改数据行的操作，因为修改数据行，实际上就是把原数据行上的xmax标记上自己的事务ID（相当于打上删除标记），然后再新插入一条记录。所以最新版本的数据即xmax为0的一条。

当两个事务同时访问记录时，通过参考xmin和xmax的标记判断记录的版本，根据版本号与自己当前的事务标识进行比较，确定自己的数据权限。

当删除数据时，记录并没有从数据块中被删除，空间也没有立即释放。

PostgreSQL的多版本实现中首先要解决的是原数据的空间释放问题。

PostgreSQL通过运行Vaccum进程来回收之前的存储空间，默认PostgreSQL数据库中的AutoVacuum是打开的，也就是说，当一个表的更新量达到一定值时（死元组数>50+(0.2×活行数），AutoVacuum自动回收空间。

当然也可以关闭AutoVacuum进程，然后在业务低峰期手动运行VACUUM命令来回收空间。

在PostgreSQL中，若一个事务执行失败，在数据文件中该事务产生的数据并不会在事务回滚时被清理掉。为什么要这样做呢？为什么不在事务提交时把这些数据标记成有效，而在事务回滚时把这些数据标记成无效呢？

这是出于效率的考虑。

若事务提交或回滚时再次标记数据，那这些数据就有可能会被刷新到磁盘中，再次标记会导致另一次I/O，从而降低性能。

那么如何知道这些数据是有效还是无效呢？

PostgreSQL通过记录事务的状态来实现。

数据行上记录了xmin和xmax，只需了解xmin和xmax对应的事务是成功提交还是回滚了，就可以知道这些数据行是否有效。

PostgreSQL把事务状态记录在pg_xact（旧版本中被称为pg_clog），在数据目录的pg_xact子目录下：

但是pg_xact是一个二进制文件目录不能直接查询，可以通过内置函数 txid_status()确定事务是提交还是回滚：

1
2
3
4
committed: 事务已成功提交
aborted: 事务已回滚（中止）
in progress: 事务仍在运行中
null: 事务 ID 太老，状态信息已被清理（见下文"事务 ID 回卷"）

PostgreSQL多版本的优劣分析

Oracle数据库和MySQL数据库的InnoDB引擎也都实现了多版本的功能，但它们与PostgreSQL的实现方式是不一样的，在这两个数据库中，旧版本的数据并不记录在原先的数据块中，而是被记录在回滚段中，如果要读取旧版本的数据，需要根据回滚段的数据重构旧版本数据。

PostgreSQL的多版本机制与Java虚拟机的垃圾回收机制比较相像。

事务提交前，只需要访问原来的数据即可；提交后，系统更新元组的存储标识，直到Vaccum进程收回为止。

相对于InnoDB和Oracle，PostgreSQL的多版本的优势在于以下几点：

  • 事务回滚可以立即完成，无论事务进行了多少操作。

  • 数据可以进行很多更新，不必像Oracle和InnoDB那样需要经常保证回滚段不会被用完，也不会像Oracle数据库那样，经常遇到”ORA-1555”错误的困扰。

相对于InnoDB和Oracle，PostgreSQL的多版本的劣势在于以下几点：

  • 旧版本数据需要清理。PostgreSQL清理旧版本称为VACUUM，并提供了VACUUM命令进行清理。

  • 旧版本的数据会导致查询更慢一些，因为旧版本的数据存储于数据文件中，查询时需要扫描更多的数据块。