关系型数据库ACID

关系型数据库ACID

一.事务

定义:所谓事务,它是一个操作序列,这些操作要么都执行,要么都不执行,它是一个不可分割的工作单位。

准备工作:为了说明事务的ACID原理,我们使用银行账户及资金管理的案例(ATM)进行分析。

  1. // 创建数据库
  2. create table account(
  3. idint primary key not null,
  4. namevarchar(40),
  5. moneydouble
  6. );
  7. // 有两个人开户并存钱
  8. insert into account values(1,‘A‘,1000);
  9. insert into account values(2,‘B‘,1000);

二.ACID

ACID,是指在可靠数据库管理系统(DBMS)中,事务(transaction)所应该具有的四个特性:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability).这是可靠数据库所应具备的几个特性.下面针对这几个特性进行逐个讲解.

三.原子性

原子性是指事务是一个不可再分割的工作单位,事务中的操作要么都发生,要么都不发生。

       1.案例

A给B转帐100元钱

[sql] view plain copy

print?

  1. begin transaction
  2. update account set money= money - 100where name=‘A‘;
  3. update account set money= money +100where name=‘B‘;
  4. if Error then
  5. rollback
  6. else
  7. commit

       2.分析 

在事务中的扣款和加款两条语句,要么都执行,要么就都不执行。否则如果只执行了扣款语句,就提交了,此时如果突然断电,A账号已经发生了扣款,B账号却没收到加款,在生活中就会引起纠纷。

       3.解决方法

在数据库管理系统(DBMS)中,默认情况下一条SQL就是一个单独事务,事务是自动提交的。只有显式的使用start transaction开启一个事务,才能将一个代码块放在事务中执行。保障事务的原子性是数据库管理系统的责任,为此许多数据源采用日志机制。例如,SQL Server使用一个预写事务日志,在将数据提交到实际数据页面前,先写在事务日志上。

四.一致性

一致性是指在事务开始之前和事务结束以后,数据库的完整性约束没有被破坏。这是说数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。

       1.案例

对银行转帐事务,不管事务成功还是失败,应该保证事务结束后ACCOUNT表中aaa和bbb的存款总额为2000元。

       2.解决方法

保障事务的一致性,可以从以下两个层面入手

2.1数据库机制层面

数据库层面的一致性是,在一个事务执行之前和之后,数据会符合你设置的约束(唯一约束,外键约束,Check约束等)和触发器设置。这一点是由SQL SERVER进行保证的。比如转账,则可以使用CHECK约束两个账户之和等于2000来达到一致性目的

2.2业务层面

对于业务层面来说,一致性是保持业务的一致性。这个业务一致性需要由开发人员进行保证。当然,很多业务方面的一致性,也可以通过转移到数据库机制层面进行保证。

五.隔离性

多个事务并发访问时,事务之间是隔离的,一个事务不应该影响其它事务运行效果。

这指的是在并发环境中,当不同的事务同时操纵相同的数据时,每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时,数据所处的状态要么是另一事务修改它之前的状态,要么是另一事务修改它之后的状态,事务不会查看到中间状态的数据。

在Windows中,如果多个进程对同一个文件进行修改是不允许的,Windows通过这种方式来保证不同进程的隔离性:

企业开发中,事务最复杂问题都是由事务隔离性引起的。当多个事务并发时,SQL Server利用加锁和阻塞来保证事务之间不同等级的隔离性。一般情况下,完全的隔离性是不现实的,完全的隔离性要求数据库同一时间只执行一条事务,这样会严重影响性能。想要理解SQL Server中对于隔离性的保障,首先要了解并发事务之间是如何干扰的.

       1.事务之间的相互影响

事务之间的相互影响分为几种,分别为:脏读,不可重复读,幻读,丢失更新

       1.1脏读

脏读意味着一个事务读取了另一个事务未提交的数据,而这个数据是有可能回滚的;如下案例,此时如果事务1回滚,则B账户必将有损失。

       1.2不可重复读

不可重复读意味着,在数据库访问中,一个事务范围内两个相同的查询却返回了不同数据。这是由于查询时系统中其他事务修改的提交而引起的。如下案例,事务1必然会变得糊涂,不知道发生了什么。

       1.3幻读(虚读)

幻读,是指当事务不是独立执行时发生的一种现象,例如第一个事务对一个表中的数据进行了修改,这种修改涉及到表中的全部数据行。同时,第二个事务也修改这个表中的数据,这种修改是向表中插入一行新数据。那么,以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行,就好象发生了幻觉一样.

       1.4丢失更新

两个事务同时读取同一条记录,A先修改记录,B也修改记录(B是不知道A修改过),B提交数据后B的修改结果覆盖了A的修改结果。

       2.理解SQL SERVER中的隔离级别

数据库的事务隔离级别(TRANSACTION ISOLATION LEVEL)是一个数据库上很基本的一个概念。为什么会有事务隔离级别,SQL Server上实现了哪些事务隔离级别?事务隔离级别的前提是一个多用户、多进程、多线程的并发系统,在这个系统中为了保证数据的一致性和完整性,我们引入了事务隔离级别这个概念,对一个单用户、单线程的应用来说则不存在这个问题。

为了避免上述几种事务之间的影响,SQL Server通过设置不同的隔离级别来进行不同程度的避免。因为高的隔离等级意味着更多的锁,从而牺牲性能。所以这个选项开放给了用户根据具体的需求进行设置。不过默认的隔离级别Read Commited符合了多数的实际需求.


隔离级别


脏读


丢失更新


不可重复读


幻读


并发模型


更新冲突检测


未提交读:Read Uncommited






悲观



已提交读:Read commited






悲观



可重复读:Repeatable Read






悲观



可串行读:Serializable






悲观


SQL Server隔离事务之间的影响是通过锁来实现的,通过阻塞来阻止上述影响。不同的隔离级别是通过加不同的锁,造成阻塞来实现的,所以会以付出性能作为代价;安全级别越高,处理效率越低;安全级别越低,效率高。

使用方法:SET TRANSACTIONISOLATION LEVEL REPEATABLE READ

 

未提交读: 在读数据时不会检查或使用任何锁。因此,在这种隔离级别中可能读取到没有提交的数据。

       已提交读:只读取提交的数据并等待其他事务释放排他锁。读数据的共享锁在读操作完成后立即释放。已提交读是SQL Server的默认隔离级别。

可重复读: 像已提交读级别那样读数据,但会保持共享锁直到事务结束。

可串行读:工作方式类似于可重复读。但它不仅会锁定受影响的数据,还会锁定这个范围。这就阻止了新数据插入查询所涉及的范围。

六.持久性

持久性,意味着在事务完成以后,该事务所对数据库所作的更改便持久的保存在数据库之中,并不会被回滚。

即使出现了任何事故比如断电等,事务一旦提交,则持久化保存在数据库中。

SQL SERVER通过write-ahead transaction log来保证持久性。write-ahead transaction log的意思是,事务中对数据库的改变在写入到数据库之前,首先写入到事务日志中。而事务日志是按照顺序排号的(LSN)。当数据库崩溃或者服务器断点时,重启动SQL SERVER,SQLSERVER首先会检查日志顺序号,将本应对数据库做更改而未做的部分持久化到数据库,从而保证了持久性。

七.总结

事务的(ACID)特性是由关系数据库管理系统(RDBMS,数据库系统)来实现的。数据库管理系统采用日志来保证事务的原子性、一致性和持久性。日志记录了事务对数据库所做的更新,如果某个事务在执行过程中发生错误,就可以根据日志,撤销事务对数据库已做的更新,使数据库退回到执行事务前的初始状态。

  数据库管理系统采用锁机制来实现事务的隔离性。当多个事务同时更新数据库中相同的数据时,只允许持有锁的事务能更新该数据,其他事务必须等待,直到前一个事务释放了锁,其他事务才有机会更新该数据。

转载自:http://blog.csdn.net/shuaihj/article/details/14163713

时间: 2024-10-10 16:38:49

关系型数据库ACID的相关文章

选型宝访谈:当业务炸裂式增长 ,如何让关系型数据库平滑扩展?

当业务炸裂式增长,如何让关系型数据库平滑扩展? 爱奇艺.饿了么.摩拜单车.....这些国民级应用的疯狂增长背后,是怎样一款国产的分布式NewSQL数据库,在做平滑支撑? 对话内容 选型宝:您怎么理解数据库技术的发展历程,分几个阶段?黄东旭:其实整个大的背景大概是这样,上世纪六七十年代就有关系数据库概念了,一直发展到90年代,基本都是以IBM DB2. Oracle,微软的SQL Server等单机关系型数据库为主的行业现状.但是在2000年以后,随着互联网行业数据量爆发性的增长,同时最近这5-1

NoSQL数据库技术实战-第1章 NoSQL的数据一致性 传统关系型数据库的ACID

在看着章节的时候,我简单的回顾了一下关系型数据库的事务处理的ACID原则,其中原子性和持久性比较好理解.由于以前没有深入去研究.关于一致性和隔离性上我产生了疑问,在整理后分析如下: 一致性:书中所说的一致性是指数据库要保证事务处理前后,数据从一种一致的状态转移到另外一种一致的状态.书中举的例子是银行转账前后总账是不应该变化的.但是我困惑的是,转账前后总账的一致性应该是在应用程序中控制的,数据库怎么能保证呢?最后我的理解是,数据库本身不保证你的数据的一致性,但是它有一些处理,只要你的应用程序写法没

关系型数据库遵循ACID规则

关系型数据库遵循ACID规则 事务在英文中是transaction,和现实世界中的交易很类似,它有如下四个特性: 1.A (Atomicity) 原子性 原子性很容易理解,也就是说事务里的所有操作要么全部做完,要么都不做,事务成功的条件是事务里的所有操作都成功,只要有一个操作失败,整个事务就失败,需要回滚. 比如银行转账,从A账户转100元至B账户,分为两个步骤:1)从A账户取100元:2)存入100元至B账户.这两步要么一起完成,要么一起不完成,如果只完成第一步,第二步失败,钱会莫名其妙少了1

mysql关系型数据库遵循ACID规则

关系型数据库遵循ACID规则 事务在英文中是transaction,和现实世界中的交易很类似,它有如下四个特性: 1.A (Atomicity) 原子性 原子性很容易理解,也就是说事务里的所有操作要么全部做完,要么都不做,事务成功的条件是事务里的所有操作都成功,只要有一个操作失败,整个事务就失败,需要回滚. 比如银行转账,从A账户转100元至B账户,分为两个步骤:1)从A账户取100元:2)存入100元至B账户.这两步要么一起完成,要么一起不完成,如果只完成第一步,第二步失败,钱会莫名其妙少了1

关系型数据库与非关系型数据库的区别

在关系型数据库中,导致性能欠佳的最主要因素是多表的关联查询,以及复杂的数据分析类型的复杂SQL报表查询.     为了保证数据库的ACID特性(ACID:● 安全存储合适的数据  ●快速检索合适的数据  ●支持多个并行的用户会话 ), 我们必须尽量按照其要求的范式进行设计,关系型数据库中的表都是存储一些格式化的数据结构,每个元组字段的组成都一样,即使不是每个元组都需要所有的字段,但数据库会为每个元组分配所有的字段,这样的结构可以便于表与表之间进行连接等操作,但从另一个角度来说它也是关系型数据库性

​NOSQL与关系型数据库的区别

关系型数据库存在的瓶颈 1.高并发读写需求网站的用户并发性非常高,往往达到每秒上万次读写请求,对于传统关系型数据库来说,硬盘I/O是一个很大的瓶颈 2.海量数据的高效率读写网站每天产生的数据量是巨大的,对于关系型数据库来说,在一张包含海量数据的表中查询,效率是非常低的 3.高扩展性和可用性在基于web的结构当中,数据库是最难进行横向扩展的,当一个应用系统的用户量和访问量与日俱增的时候,数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负

关系型数据库知识小结

一.基础术语 DML(data manipulation language): 如SELECT.UPDATE.INSERT.DELETE,主要用来对数据库里的数据进行操作的语言 DDL(data definition language): 主要的命令有CREATE.ALTER.DROP等,DDL主要是用在定义或改变表(TABLE)的结构,数据类型,表之间的链接和约束等初始化工作上,大多在建立表时使用. DCL(Data Control Language):数据库控制功能.是用来设置或更改数据库用

从关系型数据库到非关系型数据库

来源:http://blog.csdn.net/robinjwong/article/details/18502195 1. 关系型数据库 关系型数据库,是指采用了关系模型来组织数据的数据库. 关系模型是在1970年由IBM的研究员E.F.Codd博士首先提出的,在之后的几十年中,关系模型的概念得到了充分的发展并逐渐成为主流数据库结构的主流模型. 简单来说,关系模型指的就是二维表格模型,而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织. 关系模型中常用的概念: 关系:可以理解为一

关系型数据库 V.S. 非关系型数据库

关系型数据库的最大特点就是事务的一致性:传统的关系型数据库读写操作都是事务的,具有ACID的特点,这个特性使得关系型数据库可以用于几乎所有对一致性有要求的系统中,如典型的银行系统. 但是,在网页应用中,尤其是SNS应用中,一致性却不是显得那么重要,用户A看到的内容和用户B看到同一用户C内容更新不一致是可以容忍的,或者说,两个人看到同一好友的数据更新的时间差那么几秒是可以容忍的,因此,关系型数据库的最大特点在这里已经无用武之地,起码不是那么重要了. 相反地,关系型数据库为了维护一致性所付出的巨大代