软件世界网 购物 网址 三丰软件 | 小说 美女秀 图库大全 游戏 笑话 | 下载 开发知识库 新闻 开发 图片素材
多播视频美女直播
↓电视,电影,美女直播,迅雷资源↓
TxT小说阅读器
↓语音阅读,小说下载,古典文学↓
一键清除垃圾
↓轻轻一点,清除系统垃圾↓
图片批量下载器
↓批量下载图片,美女图库↓
移动开发 架构设计 编程语言 Web前端 互联网
开发杂谈 系统运维 研发管理 数据库 云计算 Android开发资料
  软件世界网 -> 数据库 -> Howdoesarelationaldatabasework -> 正文阅读

[数据库]Howdoesarelationaldatabasework


原文链接:http://coding-geek.com/how-databases-work/#Buffer-Replacement_strategies
紧接上一篇文章,本文翻译了如下章节:
[img]http://img.blog.csdn.net/20160403084245005
Transaction manager(事务管理器)

一、关于ACID


一个满足ACID标准的事务,符合以下四个条件:
  • Atomicity(原子性):
    一个事务要么完整的执行所有对数据库的操作,要么不对数据库做任何操作,即使要持续运行10个小时。如果事务中止了,数据库将返回到事务执行前的状态(事务回滚)。
  • Isolation(隔离性): A和B两个事务同时运行,无论哪个事务先执行完都不影响最终的执行结果。
  • Durability(持久化):一旦事务成功提交;数据将持久化、保存到数据库,无论后续发生何种异常。

  • Consistency(一致性): 只有满足数据库约束的有效数据能写到数据库。一致性与原子性和隔离性强相关。
    [img]http://img.blog.csdn.net/20160403084427350

在同一个事务中,你可以执行多条SQL语句去查询、修改、新增、删除数据库中的数据。当多个事务同时访问一份数据时,混乱出现了。最经典的例子就是转账汇款,从A账号转账到B账户。想象一下,有这样两个事务:
  • 事务1:从A账户转账100美元到B账户。
  • 事务2:从A账户账户50美元到B账户。

对应到事务的ACID原则上来说:
  • Atomicity(原子性):
    确保发生任何故障(服务器崩溃、网络中断等)都不会出现100美元从A账户扣除了,却没有存入B账户的情况(数据不一致)。
  • Isolation(隔离性):
    事务1和2同时执行,最终结果始终是A账户减少150美元,B账号增加了150美元。不会出现A账号减少了150美元,B账户只增加了50美元的情况(事务2的执行结果覆盖的事务1,出现了数据不一致)。
  • Durability(持久化):如果事务1成功提交,事务的执行结果将被保存到数据库。数据不会凭空丢失,即使数据库发生故障。
  • Consistency(一致性): 确保在转账的过程中,总金额是一致的,A账户减少多少钱,B账户就对应的增加多少钱。

现代数据库不会使用纯粹、完全的事务隔离,因为它会带来极大的性能损耗。SQL规范定义了四种隔离模式。
  • Serializable(串行化执行,
    SQLite默认级别):最高隔离性级别。同时执行的两个事务完全隔离,每个事务有独立的运行空间。

  • Repeatable Read(可重读,
    MySQL默认级别):每个事务独立执行。不过,如果一个事务添加了新数据,并已提交完毕;另外一个正在执行的事务能看到新加的数据。但,如果一个事务是修改数据后提交完毕,另一个正在执行的事务是看不到这种修改的。,在新增加数据的情况下,破环的事务了的隔离性。
    例如:事务A正在执行“SELECT COUNT(*) FROM
    TABLE_X”,这时事务B往TABLE_X添加了数据。如果事务A再次执行COUNT(*)操作,前后两次的查询结果不同。这种情况被称之为”幻读”。

  • Read Committed(Oracle、PostgreSQL、SQL
    Server默认支持的级别):这种隔离度是在Repeatable
    Read的基础上,增加了一条打破事务隔离性的规则。如果事务A读取了数据D,同时事务B对数据做了修改(包括删除)后提交。事务A再次读取数据D,能感知事物B对数据D的修改。
    也就是说,Read Committed模式下,一个事务既可以感知另一个事务添加新数据,也能感知这个事务对数据的修改。这个模式也叫
    non-repeatable read。

  • Read uncommitted:隔离性最差的一种方式,它是在 Read
    committed的基础上又增加了一条破坏事务隔离性的规则。事务A读取了数据D,同时数据D被事务B做了修改(事务B还未提交,还在执行过程中);如果事务A再次读取数据D,它将感知数据D被修改了,然后事务B回滚,A持有的数据还是被事务B修改后的。实际数据D未被修改(因为事务B回滚了)。
    这种模式叫”脏读”。

大多数数据库会添加自定义的隔离性级别, 例如在Oracle、PostgreSQL、SQL Server使用的snapshot Isolation(快照隔离)。很多时间,数据库不会支持SQL规范中定义的所有隔离模式(特别是 Read uncommitted模式)。
用户在连接到数据库时,可以修改默认隔离模式。

二、 Concurrency contro(并发控制)


支撑数据库实现事务隔离性、一致性、原子性的关键是解决好数据库同写的问题(含添加、删除和修改)。
1) 如果所有的事务仅仅是读取数据,他们能并行工作,相互无影响。
2) 如果有一个事务(哪怕只有一个)在修改其他事务读取的数据,数据库需要考虑如何屏蔽数据修改对其它事务的影响。并且,需要要确保修后的数据不会被其它事务覆盖。
这种技术称为“并发控制”。
解决这个问题最简单的方法是让多个事务按时间先后依次执行(串行化)。但是,这是一种非常低效的做法(在多核处理器上仅跑一个任务)。
理想的解决方式是随时允许创建事务、运行事务、删除事务。要达到这个目标,需要做到以下几点:
  1. 实时监控所有事务的所有操作。
  2. 检查是否存在多个事务同时读/写相同数据的情况,是否造成冲突。
  3. 重排引起冲突的事务执行顺序,将冲突区域范围缩小。
  4. 按重排好的顺序执行引起数据冲突的操作(不会引起冲突的事务操作仍然并行)。
  5. 考虑把一些引起冲突的事务取消掉。

本质上来讲,这是一个冲突事务的调度问题。冲突事务调度的算法是非常复杂的,也非常耗时。企业级的数据库不可能花费几个小时去寻找最优调度策略,处理冲突事务。
因此,它们仅使用简易的调度策略,使得算法耗费的时间在可接受的范围内。当然这种调度策略会导致突事务更多的时间等待。

三、 Lock manager(锁管理)


为解决事务冲突的问题,大多数数据库使用加锁和数据版本管理两种策略。这是一个大的命题,我将聚焦在锁管理部分,适当介绍一下数据版本管理。
Pessimistic lock(悲观锁)。它背后的原理是:
  1. 如果一个事务需要获取数据。
  2. 它先将数据加锁。
  3. 如果另一个事务也需要获取这块数据。
  4. 它需要等待第一个事务释放锁。

这种锁也叫独享锁-exclusive lock。
但是,使用独享锁将导致访问数据库代价高昂。因为,它要求其它也需要读取同一批数据的事务等待。这也是为什么存在另外一种锁—(shared lock)共享锁。
Shared lock(共享锁)。其原理是:
  1. 如果事务1仅是需要读取数据A。
  2. 事务1对数据A加shared lock,然后读取数据A。
  3. 如果事务2也是只需要读取数据A。
  4. 事务2对数据A加shared lock,然后读取数据A。
  5. 如果事务3需要修改数据A。
  6. 事务3对是数据A加Pessimistic lock,它需要等待另外两个事务释放shared lock。

如果一块数据已经添加了Pessimistic lock。另外一个事务即使只是读数据(需要对数据加shared lock),也需要等待Pessimistic lock释放;否则读取的是脏数据。
[img]http://img.blog.csdn.net/20160403084721382
Lock manager的职责就是管理锁的申请和释放。Lock manager通过哈希表管理锁资源,也管理着锁与数据的关联关系。包括:
  • 哪些事务对特定数据加了锁。
  • 哪些事务在等待对特定数据加锁。

四、 Dead lock(死锁)


使用锁有可能导致一个问题,即两个事务同时等待对方释放锁。
[img]http://img.blog.csdn.net/20160403084830117
在这张图中,可以看到:
  • Transaction A拥有data1的exclusive lock,同时申请data2权限。
  • Transaction B拥有data2的exclusive lock,同时申请data1权限。

这就出现了死锁。
出现死锁时,Lock manger将选择其中一个事务回滚以解除死锁状态。选择哪一个事务回滚,这是个很复杂的问题,要考虑以下方面:
  • 回滚涉及数据量最小的事务(造成混滚的代价最小),是否就是最好的决策?
  • 回滚最新提交的事务(因为其它事务等待的时间更长),是否就是最好的决策?
  • 回滚耗时更短的事务(避免长时间等待,线程饿死),是否就是最好的决策?
  • 即使回滚,又有多少其它事务会受此回滚的影响?

当然,在做出回滚的决策之前,先要明确是否已经出现了事务死锁。
依据lock manager的哈希表,能画出一个依赖关系图(类似上面的截图)。如果在图中出现了环路,即意味着出现了死锁。检查是否出现环路是非常耗时的,因为依赖关系图的数据量通常很庞大;所以,一般采用更简单的方法:判断是否超时。如果事务申请的锁未在指定的超时时间内分配,则认为事务进入了死锁。
Lock manager能够判断新申请的锁是否会导致死锁。同样的,要做出准确的判断,算法也是非常耗时间的。取而代之,它采用一些检查条件来判断。

五、 Two-phase locking(二阶段锁)


为确保一个事务完全隔离,最简单方法是在事务开始时申请锁,在事务结束时释放锁。这意味着,事务必须等待申请完所有需要的锁才开始运行,在执行过程中完全占用锁,结束时才统一释放。这种方案逻辑上没问题,但是会耗费很多时间在等待锁资源上。
一种更快一些的方案是Two-Phase Locking Protocol(在DB2和SQL Server中使用)。在这种方案中,一个事务被分解为两个阶段。
  1. 在growing phase(发展阶段),事务可以申请锁,不能释放锁。

  2. 在shrinking phase(收缩阶段),事务可以释放锁(已经加锁处理过的数据,且不会再处理),不能申请锁。
    [img]http://img.blog.csdn.net/20160403084942055

其背后的原理有这样两条:
  1. 尽快释放不再使用的锁,以减少其它事务的等待时间。
  2. 避免出现这种情况:某个事务获取数据后,数据又被其它事务修改,以至于数据与获取时不一致。

这种策略能完美运行,除非一个事务修改了数据,释放了锁,然后又回滚事务。另一个事务在前一个事务释放锁后,读取了数据;它不清楚修改后的数据后面又发生了回滚。
为了避免出现这种情况,规定所有的exclusive lock必须在事务结束时才释放。
再多说几句:
当然,一个真实的企业级数据库会使用更复杂的方案,更丰富的锁(如:意向锁),更细的锁控制粒度(基于行、分页、分区、表空间等)。但,其核心思想是一样的。
这里,我只描述了最基础的锁的原理。Data versioning(数据版本管理)是另一种解决事务冲突的方案。
数据版本管理的基本原理是:
  1. 所有的事务都可以同时修改相同的数据。
  2. 每个事务都持有所需数据的一个拷贝(一个版本)。

如果多个事务修改相同的数据,只有一个事务的修改会被持久化,其它事务的修改会丢弃(事务回滚,后面也可能re-run)。
这种方式带来性能上的提升,因为:
  1. 读数据的事务不会阻塞写数据的事务。
  2. 写数据的事务也不会阻塞读数据的事务。
  3. 不存在又笨又慢(fat and slow)的锁管理开销。

如果没有出现两个事务同时写同一片数据,这种方式更好。但是,这种方式需要巨大的磁盘空间开销。
数据版本管理和锁管理是两种不同的思想: 乐观锁(optimistic locking)与悲观锁(pessimistic locking)。它们都同时存在支持方和反对方,使用哪种方式依赖于具体的引用场景(more reads VS more writes)。说到数据库对Data versioning的支持情况,我觉得PostgreSQL的多版本数据管理并发控制做得非常强大。
一些数据库,如DB2(9.7之前版本)和SQL Server(除了所谓的视图快照隔离)仅支持加锁的机制。其它一些数据库,如PostgreSQL、MySQL和Oracle同时支持加锁和数据版本管理两种方式。我不知道有什么数据库是仅支持Data versioning的(如果你知道,请告诉我)。
如果你已经读过了介绍隔离性不同级别的章节,就应该清楚。提升隔离性将增加锁的数量,增加事务申请锁的等待时间。这也是为什么大多数据库不将隔离性最强的串行化(Serializable),设置为默认级别的原因。
你也可以在主流的数据库(如MySQL、PostgreSQL、Oracle)指导文档中检查它的设置情况。
......显示全文...
    点击查看全文


上一篇文章      下一篇文章      查看所有文章
2016-04-03 20:45:40  
数据库 最新文章
Python&MySQL&PyQt
最新用python来操作mysql完全解析
mongodb的安装详解
1.PDO简介
《MySQL必知必会学习笔记》:高级联结
【翻译自mos文章】怎么对Microsoft(Office)
MyCAT全局表描述及示例
ocp
关于SQL数据表存储过程表名前缀换成dbo代码
数据库调优教程(二)慢查询数据准备
360图书馆 论文大全 母婴/育儿 软件开发资料 网页快照 文字转语音 购物精选 软件 美食菜谱 新闻中心 电影下载 小游戏 Chinese Culture
生肖星座解梦 人民的名义 人民的名义在线看 三沣玩客 拍拍 视频 开发 Android开发 站长 古典小说 网文精选 搜图网 天下美图
中国文化英文 多播视频 装修知识库
2017-7-20 20:34:12
多播视频美女直播
↓电视,电影,美女直播,迅雷资源↓
TxT小说阅读器
↓语音阅读,小说下载,古典文学↓
一键清除垃圾
↓轻轻一点,清除系统垃圾↓
图片批量下载器
↓批量下载图片,美女图库↓
  网站联系: qq:121756557 email:121756557@qq.com  软件世界网 --