PostgreSQL的MVCC与数据库ACID
1、数据库事务ACID介绍数据库事务包含如下四个特性原子性(Atomicity)指一个事务要么全部执行,要么不执行。也即一个事务不可能只执行一半就停止(哪怕是因为意外也不行)。比如从取款机取钱,这个事务可以分成两个步骤:1)划卡;2)出钱。不可能划了卡,而钱却没出来。这两步必须同时完成,或者同时不完成。一致性(Consistency)事务的运行不可改变数据库中数据的一致性,事务必须将数据库中的数据
1、数据库事务ACID介绍
数据库事务包含如下四个特性
- 原子性(Atomicity) 指一个事务要么全部执行,要么不执行。也即一个事务不可能只执行一半就停止(哪怕是因为意外也不行)。比如从取款机取钱,这个事务可以分成两个步骤:1)划卡;2)出钱。不可能划了卡,而钱却没出来。这两步必须同时完成,或者同时不完成。
- 一致性(Consistency) 事务的运行不可改变数据库中数据的一致性,事务必须将数据库中的数据从一个正确的状态带到另一个正确的状态。事务在开始时,完全可以假定数据库中的数据是处于正确(一致)状态的,而不必作过多验证(从而提升效率),同时也必须保证事务结束时数据库数据处于正确(一致)状态。例如,完整性约束了a+b=10,一个事务改变了a,那么b也应该随之改变。
- 隔离性(Isolation) 在并发数据操作时,不同的事务拥有各自的数据空间,其操作不会对对方产生干扰。隔离性允许事务行为独立或隔离于其它事务并发运行。
- 持久性(Durability)事务执行成功以后,该事务对数据库所作的更改是持久的保存在数据库之中,不会无缘无故的回滚。
2、ACID在PostgreSQL中如何实现
事务的实现原理可以解读为RDBMS采取何种技术确保事务的ACID特性,PostgreSQL针对ACID的实现技术如下表所示。
ACID | 实现技术 |
---|---|
原子性(Atomicity) | MVCC |
一致性(Consistency) | 约束(主键、外键等) |
隔离性 | MVCC |
持久性 | WAL |
从上表可以看到,PostgreSQL主要使用MVCC和WAL两项技术实现ACID特性。实际上,MVCC和WAL这两项技术都比较成熟,主流关系型数据库中都有相应的实现,但每个数据库中具体的实现方式往往存在较大的差异。本文将介绍PostgreSQL中的MVCC实现原理。
3、PostgreSQL中的MVCC原理介绍
3.1 事务ID
在PostgreSQL中,每个事务都有一个唯一的事务ID,被称为XID。注意:除了被BEGIN - COMMIT/ROLLBACK包裹的一组语句会被当作一个事务对待外,不显示指定BEGIN - COMMIT/ROLLBACK的单条语句也是一个事务。
数据库中的事务ID递增。可通过txid_current()
函数获取当前事务的ID。
3.2 隐藏多版本标记字段
PostgreSQL中,对于每一行数据(称为一个tuple),包含有4个隐藏字段。这四个字段是隐藏的,但可直接访问。
- xmin 在创建(insert)记录(tuple)时,记录此值为插入tuple的事务ID
- xmax 默认值为0.在删除tuple时,记录此值
- cmin和cmax 标识在同一个事务中多个语句命令的序列值,从0开始,用于同一个事务中实现版本可见性判断
PostgreSQL的MVCC更详细介绍参考另外一篇文章:Postgres的多版本并发控制MVCC_abcwywht的博客-CSDN博客
4、MVCC如何保证原子性(Atomicity)
原子性(Atomicity)指得是一个事务是一个不可分割的工作单位,事务中包括的所有操作要么都做,要么都不做。
对于插入操作,PostgreSQL会将当前事务ID存于xmin中。对于删除操作,其事务ID会存于xmax中。对于更新操作,PostgreSQL会将当前事务ID存于旧数据的xmax中,并存于新数据的xin中。换句话说,事务对增、删和改所操作的数据上都留有其事务ID,可以很方便的提交该批操作或者完全撤销操作,从而实现了事务的原子性。
5、MVCC如何保证事物的隔离性
隔离性(Isolation)指一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的,并发执行的各个事务之间不能互相干扰。
标准SQL的事务隔离级别分为如下四个级别
隔离级别 | 脏读 | 不可重复读 | 幻读 |
---|---|---|---|
未提交读(read uncommitted) | 可能 | 可能 | 可能 |
提交读(read committed) | 不可能 | 可能 | 可能 |
可重复读(repeatable read) | 不可能 | 不可能 | 可能 |
串行读(serializable) | 不可能 | 不可能 | 不可能 |
从上表中可以看出,从未提交读到串行读,要求越来越严格。
注意,SQL标准规定,具体数据库实现时,对于标准规定不允许发生的,绝不可发生;对于可能发生的,并不要求一定能发生。换句话说,具体数据库实现时,对应的隔离级别只可更严格,不可更宽松。
事实中,PostgreSQL实现了三种隔离级别——未提交读和提交读实际上都被实现为提交读。
下面将讨论提交读和可重复读的实现方式
5.1 MVCC保证提交读
提交读只可读取其它已提交事务的结果。PostgreSQL中通过pg_clog来记录哪些事务已经被提交,哪些未被提交。具体实现方式将在下一篇文章《SQL优化(七) WAL PostgreSQL实现事务和高并发的重要技术》中讲述。
5.2 MVCC保证可重复读
相对于提交读,重复读要求在同一事务中,前后两次带条件查询所得到的结果集相同。实际中,PostgreSQL的实现更严格,不紧要求可重复读,还不允许出现幻读。它是通过只读取在当前事务开启之前已经提交的数据实现的。结合上文的四个隐藏系统字段来讲,PostgreSQL的可重复读是通过只读取xmin小于当前事务ID且已提交的事务的结果来实现的。
更多推荐
所有评论(0)