PostgreSQL rc,rr,ssi 隔离级别与性能对比 - 高隔离级别损耗性测试

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
简介: 标签 PostgreSQL , rc , rr , ssi , 隔离级别 , 性能 , 乐观锁 背景 https://www.postgresql.org/docs/11/mvcc.html PG支持到了最高级别的隔离级别SSI(serializable snapshot isolate)。 几种隔离级别的目标如下 1、读未提交,可以看到未提交的数据,脏读。 2、读已提交,只能看

标签

PostgreSQL , rc , rr , ssi , 隔离级别 , 性能 , 乐观锁


背景

https://www.postgresql.org/docs/11/mvcc.html

PG支持到了最高级别的隔离级别SSI(serializable snapshot isolate)。

几种隔离级别的目标如下

1、读未提交,可以看到未提交的数据,脏读。

2、读已提交,只能看到其他会话已提交的数据。

3、可重复度,只能看到事务开启前已提交的数据。更新(修改)事务开启后被其他会话修改过并提交的数据时,报错。

postgres=# create table abc(id int primary key, info text);  
CREATE TABLE  
postgres=# insert into abc values (1,'test');  
INSERT 0 1  

a

postgres=# begin transaction isolation level repeatable read ;  
BEGIN  
postgres=# select * from abc;  
 id | info   
----+------  
  1 | test  
(1 row)  

b

postgres=# update abc set info='hello digoal';  
UPDATE 1  
commit;  

a

postgres=# \set VERBOSITY verbose
postgres=# update abc set info ='new';  
ERROR:  40001: could not serialize access due to concurrent update
LOCATION:  ExecUpdate, nodeModifyTable.c:1257

4、严格串行,模拟串行执行,事务结束时,判断是否有会话之间的相互依赖,如果依赖的数据被已提交的事务修改,则报错,确保模拟严格串行的场景。

create table mytab (class int, value int);  
insert into mytab values (1,10),(1,20),(2,100),(2,200);  
  
 class | value  
-------+-------  
     1 |    10  
     1 |    20  
     2 |   100  
     2 |   200  

a

postgres=# begin transaction isolation level serializable ;  
BEGIN  
  
SELECT SUM(value) FROM mytab WHERE class = 1;  

b

postgres=# begin transaction isolation level serializable ;  
BEGIN  
postgres=# SELECT SUM(value) FROM mytab WHERE class = 2;  
 sum   
-----  
 300  
(1 row)  

a

insert into mytab values (2,30);  

b

insert into mytab values (1,30);  

a

postgres=# commit ;  
COMMIT  

b

postgres=# \set VERBOSITY verbose
postgres=# commit;
ERROR:  40001: could not serialize access due to read/write dependencies among transactions
DETAIL:  Reason code: Canceled on identification as a pivot, during commit attempt.
HINT:  The transaction might succeed if retried.
LOCATION:  PreCommit_CheckForSerializationFailure, predicate.c:4685

《PostgreSQL 10.0 preview 功能增强 - 串行隔离级别 预加锁阈值可控》

《PostgreSQL SERIALIZABLE ISOLATION LEVEL introduce》

隔离级别越高,冲突可能性就越大,不同数据库的实现不一样,PG使用了巧妙的乐观锁实现。处理吞吐高。

对比rc, rr, ssi隔离级别的性能

为了方便测试,使用函数封装TPCB,测试rr和ssi

create or replace function tpcb (int,int,int,int) returns void as $$  
declare  
begin  
  UPDATE pgbench_accounts SET abalance = abalance + $4 WHERE aid = $1;  
  perform abalance FROM pgbench_accounts WHERE aid = $1;  
  UPDATE pgbench_tellers SET tbalance = tbalance + $4 WHERE tid = $3;  
  UPDATE pgbench_branches SET bbalance = bbalance + $4 WHERE bid = $2;  
  INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES ($3, $2, $1, $4, CURRENT_TIMESTAMP);  
  exception when SQLSTATE '40001' then   -- skip 冲突 
    return;  
end;  
$$ language plpgsql strict;  

测试脚本

vi tpcb.sql  
\set aid random(1, 100000 * :scale)  
\set bid random(1, 1 * :scale)  
\set tid random(1, 10 * :scale)  
\set delta random(-5000, 5000)  
select tpcb(:aid, :bid, :tid, :delta);  

初始化数据,5亿条

pgbench -i -s 5000  

rc模式

alter role all set default_transaction_isolation ='read committed';  
pgbench -M prepared -v -r -P 1 -c 64 -j 64 -T 120  
  
transaction type: <builtin: TPC-B (sort of)>  
scaling factor: 5000  
query mode: prepared  
number of clients: 64  
number of threads: 64  
duration: 120 s  
number of transactions actually processed: 11343739  
latency average = 0.677 ms  
latency stddev = 0.747 ms  
tps = 94519.862919 (including connections establishing)  
tps = 94528.706372 (excluding connections establishing)  
statement latencies in milliseconds:  
         0.002  \set aid random(1, 100000 * :scale)  
         0.001  \set bid random(1, 1 * :scale)  
         0.001  \set tid random(1, 10 * :scale)  
         0.001  \set delta random(-5000, 5000)  
         0.046  BEGIN;  
         0.137  UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;  
         0.073  SELECT abalance FROM pgbench_accounts WHERE aid = :aid;  
         0.082  UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;  
         0.079  UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;  
         0.067  INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);  
         0.188  END;  
postgres=# select count(*) from pgbench_history ;  
  count     
----------  
 11343739  
(1 row)  

rr模式

alter role all set default_transaction_isolation ='repeatable read';  
pgbench -M prepared -v -r -P 1 -f ./tpcb.sql -c 64 -j 64 -T 120  
  
transaction type: ./tpcb.sql  
scaling factor: 1  
query mode: prepared  
number of clients: 64  
number of threads: 64  
duration: 120 s  
number of transactions actually processed: 10555148  
latency average = 0.728 ms  
latency stddev = 0.732 ms  
tps = 87949.593197 (including connections establishing)  
tps = 87957.185597 (excluding connections establishing)  
statement latencies in milliseconds:  
         0.001  \set aid random(1, 100000 * :scale)  
         0.000  \set bid random(1, 1 * :scale)  
         0.000  \set tid random(1, 10 * :scale)  
         0.000  \set delta random(-5000, 5000)  
         0.725  select tpcb(:aid, :bid, :tid, :delta);  

等待事件

select wait_event_type,wait_event,count(*) from pg_stat_activity  group by 1,2 order by 1,2;  
  
 wait_event_type |      wait_event      | count   
-----------------+----------------------+-------  
 Activity        | AutoVacuumMain       |     1  
 Activity        | BgWriterMain         |     1  
 Activity        | CheckpointerMain     |     1  
 Activity        | LogicalLauncherMain  |     1  
 Client          | ClientRead           |     4  
 IPC             | ProcArrayGroupUpdate |     1  
 LWLock          | buffer_content       |     5  
 Lock            | transactionid        |     6  
 Lock            | tuple                |    34  
                 |                      |    17  
(10 rows)  

正常事务:

postgres=# select count(*) from pgbench_history ;  
 count    
--------  
 638001  
(1 row)  

在冲突率这么高的情况下,可以保持87957的TPS,非常厉害。

ssi模式

alter role all set default_transaction_isolation ='serializable';  
pgbench -M prepared -v -r -P 1 -f ./tpcb.sql -c 64 -j 64 -T 120  
  
transaction type: ./tpcb.sql  
scaling factor: 1  
query mode: prepared  
number of clients: 64  
number of threads: 64  
duration: 120 s  
number of transactions actually processed: 5166549  
latency average = 1.486 ms  
latency stddev = 1.098 ms  
tps = 43050.086666 (including connections establishing)  
tps = 43058.594768 (excluding connections establishing)  
statement latencies in milliseconds:  
         0.002  \set aid random(1, 100000 * :scale)  
         0.000  \set bid random(1, 1 * :scale)  
         0.000  \set tid random(1, 10 * :scale)  
         0.000  \set delta random(-5000, 5000)  
         1.484  select tpcb(:aid, :bid, :tid, :delta);  

锁等待

select wait_event_type,wait_event,count(*) from pg_stat_activity  group by 1,2 order by 1,2;  
  
  
 wait_event_type |          wait_event          | count   
-----------------+------------------------------+-------  
 Activity        | AutoVacuumMain               |     1  
 Activity        | BgWriterHibernate            |     1  
 Activity        | CheckpointerMain             |     1  
 Activity        | LogicalLauncherMain          |     1  
 Activity        | WalWriterMain                |     1  
 Client          | ClientRead                   |     1  
 LWLock          | SerializableFinishedListLock |    58  
 LWLock          | SerializableXactHashLock     |     2  
 Lock            | transactionid                |     1  
 Lock            | tuple                        |     1  
                 |                              |     3  
(11 rows)  

正常事务:

postgres=# select count(*) from pgbench_history ;  
 count    
--------  
 411820  
(1 row)  

在冲突率这么高的情况下,可以保持43058的TPS,非常厉害。

性能对比

数据量 隔离级别 TPS(吞吐能力) QPS 正常事务 冲突比例
5亿 rc 94528 472640 11343739 0%
5亿 rr 87957 439785 638001 93.95%
5亿 ssi 43058 215290 411820 92.03%

小结

在冲突率高达90%以上的情况下,PG的RR模式可以保持87957的TPS,SSI模式可以保持43058的TPS,非常厉害,使用乐观锁带来的好处多多。

测试环境:32核虚拟机。(文章主要表明的是PG在高隔离级别下面的锁管理能力强悍,相对于RC这种低隔离级别,损耗做到了非常小。)

参考

https://www.postgresql.org/docs/11/mvcc.html

https://www.postgresql.org/docs/11/errcodes-appendix.html

《PostgreSQL 10.0 preview 功能增强 - 串行隔离级别 预加锁阈值可控》

《PostgreSQL SERIALIZABLE ISOLATION LEVEL introduce》

https://www.jianshu.com/p/c348f68fecde

https://zhuanlan.zhihu.com/p/37087894

src/backend/storage/lmgr/README-SSI

https://www.postgresql.org/docs/11/runtime-config-locks.html

postgres=# show max_pred_locks_per_page ;
 max_pred_locks_per_page 
-------------------------
 2
(1 row)

postgres=# show max_pred_locks_per_relation ;
 max_pred_locks_per_relation 
-----------------------------
 -2
(1 row)

postgres=# show max_pred_locks_per_transaction ;
 max_pred_locks_per_transaction 
--------------------------------
 64
(1 row)
References
----------

[1] http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
Search for serial execution to find the relevant section.

[2] A. Fekete et al. Making Snapshot Isolation Serializable. In ACM
Transactions on Database Systems 30:2, Jun. 2005.
http://dx.doi.org/10.1145/1071610.1071615

[3] Joseph M. Hellerstein, Michael Stonebraker and James Hamilton. 2007.
Architecture of a Database System. Foundations and Trends(R) in
Databases Vol. 1, No. 2 (2007) 141-259.
http://db.cs.berkeley.edu/papers/fntdb07-architecture.pdf
  Of particular interest:
    * 6.1 A Note on ACID
    * 6.2 A Brief Review of Serializability
    * 6.3 Locking and Latching
    * 6.3.1 Transaction Isolation Levels
    * 6.5.3 Next-Key Locking: Physical Surrogates for Logical Properties

 

免费领取阿里云RDS PostgreSQL实例、ECS虚拟机

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
4天前
|
设计模式 测试技术 持续交付
深入白盒测试:提升软件质量与性能的关键策略
【4月更文挑战第20天】 在软件开发的复杂世界中,确保产品的质量和性能始终是至关重要的任务。白盒测试,作为软件测试领域的重要分支,提供了对程序内部结构和逻辑的深入分析手段。本文将探讨如何通过有效的白盒测试策略来优化软件性能,减少缺陷,并最终提高用户满意度。通过剖析代码检查、单元测试、集成测试等白盒测试技术,我们将了解这些方法如何揭示潜在的问题点,并为改进提供方向。
|
1月前
|
安全 测试技术
BOSHIDA DC电源模块的安全性能评估与测试方法
BOSHIDA DC电源模块的安全性能评估与测试方法
 BOSHIDA DC电源模块的安全性能评估与测试方法
|
1月前
|
安全
DC电源模块的安全性能评估与测试方法
DC电源模块的安全性能评估与测试方法 DC电源模块的安全性能评估与测试方法应包括以下几个方面: 1. 输入安全性测试:包括输入电压范围、输入电压稳定性、输入电流范围、输入电流保护等方面的测试。测试方法可以是逐步增加输入电压或输入电流,观察模块的工作状态和保护功能。
DC电源模块的安全性能评估与测试方法
|
4月前
|
存储 测试技术 Linux
添加E1000网卡进行测试,只有VMXNET3性能的四分之一
添加E1000网卡进行测试,只有VMXNET3性能的四分之一
68 0
|
4月前
|
存储 测试技术 区块链
阿里云、百度云及移动云对象存储横向性能对比测试
在企业的数字化转型进程中,我们观察到越来越多的公司将其IT基础设施迁移到云端。随着企业业务的持续运营,无论是储存、处理、分享还是删除,都会产生大量的数据,这就要求有一个既可靠又高效的系统来管理和存储这些信息。对象存储产品在这个场景中扮演了至关重要的角色。它们以一种可扩展、安全、持久的方式,有效地满足了对大规模非结构化数据存储的需求。 尽管市场上云计算提供商众多,各自都有自己独特的对象存储产品,面对这样的丰富选择,如何寻找最符合企业需求的产品呢?这正是企业今天寻求解答的问题。 在本篇文章中,我们将深入进行一项横向对比测试,专门对阿里云OSS、百度云BOS和移动云EOS这三大云服务提供商的对象
1365 0
|
18天前
|
测试技术
深入白盒测试:提升软件质量与性能的关键策略
【4月更文挑战第6天】 在软件开发的生命周期中,确保代码质量和性能始终是至关重要的环节。白盒测试作为一种深入代码内部的测试方法,提供了对程序结构、逻辑路径和内部功能的全面评估。本文将探讨白盒测试的核心概念、技术及其在提升软件质量与性能方面的应用。通过分析控制流测试、数据流测试和静态代码分析等关键技术,我们揭示了白盒测试如何有效发现潜在缺陷,优化代码效率,并增强系统稳定性。
|
1月前
|
SQL 关系型数据库 OLAP
PostgreSQL从小白到高手教程 - 第46讲:poc-tpch测试
PostgreSQL从小白到高手教程 - 第46讲:poc-tpch测试
83 3
|
1月前
|
算法 Java 测试技术
性能工具之代码级性能测试工具ContiPerf
【2月更文挑战第23天】性能工具之代码级性能测试工具ContiPerf
267 1
性能工具之代码级性能测试工具ContiPerf
|
2月前
|
关系型数据库 OLAP OLTP
PostgreSQL从小白到高手教程 - 第45讲:poc-tpcc测试
CUUG PostgreSQL技术大讲堂系列公开课第45讲-POC-TPCC测试的内容,往期视频及文档,请联系CUUG。
45 1
|
2月前
|
测试技术 BI
性能基准测试基本流程
性能基准测试基本流程