从MVCC机制看POSTGRESQL的应用场景.pdf

盖国强

781

16页

13次

2021-02-23

5墨值下载

从 MVCC 机制看 POSTGRESQL 的应用场景

PostgreSQL 和 MYSQL 是目前应用最为广泛的两个开源数据库，PostgreSQL 因为其伯

克利授权方式而更受到一些想利用开源数据库系统开发自主可控的企业数据库平台的企业

和用户所青睐。关于 PostgreSQL 和 MYSQL 到底哪个数据库性能好，以及 PostgreSQL 能否

替代 Oracle 数据库，在企业级应用中使用，是大家所关心的问题。本文从 PostgreSQL 的多

版本并发访问（MVCC）机制角度，分析 PostgreSQL 较为适合的应用场景。

MVCC 是 Multi-Version Concurrency Control 的英文缩写，翻译成中文就是多版本并

发控制。多版本并发控制的主要目的是为了提高在线事务处理系统(OLTP 系统）中的读操

作的性能问题。

事务与事务隔离是现代关系型数据库的重要基础，通过所需要的事务隔离级别，来确保

应用系统读取到的数据是符合业务逻辑的。事务隔离级别包含 read uncommitted(level 0，

脏读)、read committed(level 1，提交读)、repeatable read(level 2，可重复读)、

serializable(level 3，串行化)。其中脏读可以读取任何脏数据，因此不需要任何锁或者

其他并发控制机制支持，并发性最好，串行化强制事务串行执行，并发能力最弱。提交读-Read

committed 也叫一致性读，是目前在线联机事务（OLTP）系统中最为常见的事务隔离级别。

传统的事务理论采用锁机制来实现并发控制，简单的说，写操作使用排它锁，排斥其他

操作；读操作使用共享锁，排斥写操作，但是可以支持其他读操作。随着信息化系统的发展，

并发访问量越来越大，这种读写互斥锁的机制对并发访问的性能造成了极大的影响。1981

年位于马萨诸塞州剑桥的美国计算机公司（Computer Corporation of America）的两位技

术人员 PHILIP A. BERNSTEIN AND NATHAN GOODMAN 发表了一篇具有历史意义的论文

“Concurrency Control in Distributed Database Systems”，这篇以分布式数据库中并

发控制为主要议题的论文中，提出了一种全新的并发控制算法，基于时间戳顺序的多版本并

发控制机制（SYNCHRONIZATION TECHNIQUES BASED ON TIMESTAMP ORDERING）。这个全新的

并发控制算法为数据库厂商提高并发能力提供了一条心的途径。DEC 公司的 VAX/RDB 是第一

个采用多版本并发控制机制的商用关系型数据库，随后 Oracle 4.0 也开始支持 MVCC，IBM DB2

一直采用其独有的并发控制机制 Generalized Search Tme (GiST)，直到 DB2 9.7 才全面支

持 MVCC。到目前为止，绝大多数商用和开源数据库都已经全面支持多版本并发控制机制，

多版本并发控制机制也已经成为交易型关系型数据库的标准配置。

Bernstein 和 Goodman 创造性的提出了基于 Timestamp Ordering（T/O）的多版本并发

控制理论，对每个写操作记录 Timestamp，如下图：

如果读操作 dm-read(95)需要读取 Timestamp 95 的数据，那么当前的最新写操作的

Timestamp 是 100，而小于 95 的最大 Timestamp 是 94，那么直接读取 dm-write(94)的值就可

以了，也就是 Vn-1。

不同数据库实现多版本并发控制的方式是不同的，比如 Oracle 数据库的 T/O 使用的是

一种类时间戳的机制 SCN（System Change Number），SCN 是每个事物提交的序号，是严

格按照时间顺序增长的。PostgreSQL 和 Mysql 则采用了事物 ID（XID），事物 ID 也是严格

按照时间顺序产生的，因此也满足 T/O 的基本要求。在 MVCC 的实现粒度方面，Oracle 采

用的是页级并发控制，通过一致读数据页（Consistent Read Block，CR BLOCK）的机制实

现多版本，而 PostgreSQL 和 Mysql 则采用行级多版本控制机制。

Oracle 的多版本并发控制机制一致是业界公认的较为优秀的，多版本并发控制机制，其

特点是对读写操作的支持较为均衡，在高并发环境下有较好的性能。下面我们将通过分析

Oracle、PostGreSQL 和 Mysql 的多并发控制算法，分析这三种数据库在不同应用场景下的

并发性能。

Oracle 的多版本并发控制是基于 Oracle UNDO/回滚段机制的，在回滚段中保存了某个

数据被修改之前的前映像的数据。在每条记录的记录头（kdrh）中，kdrhlock 指向前一次修

改该数据的事务槽（ITL）的位置，在 ITL 中记录了该次修改的 SCN 信息，以及回滚段的地

址信息。其结构如下图：

当某个事务开始的时候，会在回滚段的段头 TRN TBL 中分配一个事务表记录，同时分

配第一个 UNDO 记录，记下事务的一些信息。当事务修改某个数据的时候，在该数据的 DATA

BLOCK 的 ITL 表中分配一个 ITL 记录，并锁定这个 ITL 记录，然后将数据行头中的 kdrhlock

指向这个 ITL 槽，然后再对数据进行修改。并把修改前的数据存储在回滚段的 UNDO

RECORD 中。

如果有事务要读取相关的数据，首先对数据库的 DB CACHE 缓冲区进行搜索。在 Oracle

的 DB CACHE 中，同一个数据块可能存在多个版本，这些版本被称为 CR BLOCKS。如果

在 DB CACHE 中已经找到了符合条件的 CR BLOCK（根据 SCN 来判断 CR BLOCK 是否

符合查询条件），就可以直接使用，如果没有找到可用的 CR BLOCK，那么就需要通过该

数据块的当前版本（CURRENTBLOCK）来生成所需要的 CR BLOCK。

在生成 CR BLOCK 的时候，可以根据该行数据的 kdrhlock 找到相关的 ITL 槽，通过比

对 SCN 来判断要读取的数据是数据块中的数据还是修改前的数据。如果发现当前 ITL 槽中

的 SCN 高于本事务所需要读取的 SCN，那么就会通过 ITL 槽找到该数据在 UNDO 中的前

映像数据（PRE-IMAGE），通过前映像数据和当前数据生成一个一致性读块（CR BLOCK），

然后通过访问这个 CR BLOCK 来找到所需要读的数据。实际环境中可能更为复杂，因为 ITL

槽可能会被覆盖，在这种情况下，Oracle 会把 ITL 信息写入 UNDO RECORD 中，形成一

个链状结构，可以一层层的找到所需要的 UNDO RECORD，从而完成这种操作。

Oracle 的多版本并发控制机制使用了一个独立的 UNDO 表空间来存储 UNDO 数据，

数据的前映像通过在 DB BUFFER 中的 CR BLOCK 来实现，因此数据无论修改多少次，都

不会对存储数据的数据段产生负面的影响。而且一个 CR BLOCK 生成后，可以在缓冲区中

较长时间内存在，供相关的事务使用。这个功能对于大并发的读操作来说，是十分有用的，

可以大大提高相关操作的性能。

由于 Oracle UNDO 的空间容量有限，因此不可能永久保存回滚段的数据，Oracle 采用

了 UNDO RETENTION 的机制来保护 UNDO 数据，可以设定一定的 UNDO 数据保存周期，

当 UNDO 数据在保护期内，可以保证 UNDO 记录不被覆盖。这种机制很好的解决了 UNDO

数据生命周期管理的问题，同时确保了在一个大型查询中确保所需的 PRE-IMAGE 不会被

覆盖失效。

PostgreSQL 早期的版本中是不支持多版本并发控制的，因此 PostgreSQL 的多版本并

发控制不是通过类似 Oracle 的回滚段方式实现的，其实现手段是在数据表中保存某条数据

的多个版本。比如说要对某条记录进行修改，并不是直接修改该数据，而是通过插入一条全

新的数据，同时对老数据加以标识。而删除数据也不是直接删除该数据，而是在相应的数据

of 16

5墨值下载

mvcc

相关文档

评论