【CMU15-445 Part-18】Timestamp Ordering Concurrency Control

本文详细讨论了TimestampOrdering并发控制机制,特别是BasicT/O和OCC(乐观并发控制)的概念,包括时间戳分配、事务执行规则以及OCC的phases。文章还探讨了可恢复调度和OCC如何确保串行化,以及性能挑战和解决方案。
摘要由CSDN通过智能技术生成

Part18-Timestamp Ordering Concurrency Control

OCC and T/O都是Optimistic的。

Basic T/O

通过分配时间戳来预先定义这些事务的提交顺序。DBMS保证如果TS(Ti) < TS(Tj) 那么在serial schedule中,Ti会在Tj之前执行。

Timestamp Allocation

Timestamp是唯一且固定长度是数字,有如下特性

  1. 时间戳是单调递增的
  2. 值唯一

可以在事务执行期内任意时间点给事务分配时间戳,不一定刚拿到事务或者事务提交的时候分配。

分配方法

  • CPU System Clock,可能存在回调那么时间戳就会混乱。(夏令时冬令时)
  • Logical Counter,CPU里面一个专门保存时间的寄存器,单调递增,32/64位,如果用完计时器会往回走就不能用了
  • Hybird 混合方案:让时间戳和物理计数器以及逻辑计数器匹配来确定正常工作。

Basic T/O

Txns 读写 without lock,需要添加额外的元数据来进行控制,每个Tuple要加两个TS:

  • W-TS(X):最近写X的时间戳
  • R-TS(X):最近读取X的时间戳
  • 每次操作check timestamps,如果事务想要access未来的值 要aborts 或者 restarts

在事务开始的时候分配时间戳

  • Reads

    如果TS(Ti) < W-TS(X),违反了Ti相对于X的时间戳顺序,abort Ti或者重启 with a newer TS。

    TS(Ti) ≥ W-TS(x):允许Ti读X,更新R-TS(X) = max(R-TS(X),TS(Ti)) 。做一个X的local copy来保证Ti的可重复读

  • Writes

    TS(Ti) < R-TS(X) 或者 TS(Ti) < W-TS(x) , txn abort 或者 restart

    如果≥ ,允许Ti对X进行写,然后更新W-TS(X),同样要x local copy 保证可重复读。

  • Thomas Write Rules

    读一样,写的话如果TS(Ti) < W-TS(x) 那么忽略这个write 允许事务继续。 但是会本事务内维护这个写后的临时值?

(不使用Thomas Write Rules的话)可以生产conflict serializable schedule。不会产生死锁因为没有事务在等待;假设有长事务,可能会因为有许多短事务更新不断地引起冲突,导致这些连环中止的老事务无效化。问题是T/O协议规定了schedule是不可以恢复的。

Untitled

Recoverable Schedules

可恢复的调度是一个事务只有当它所依赖数据的对应事务已经都提交的情况下它才提交,才是可恢复的调度。(cascading aborts)

下面的例子,T2读T1的未提交的值,但是T1abort了,T2也没法回滚。对于Basic Timestamp Ordering来说允许这种情况发生。

Untitled

Basic T/O性能问题:复制数据到txn 自己的workspace的overhead太高了;长事务饿死问题。

OCC

如果假设系统中没有很多锁争用情况,这些事务存活周期短,彼此无冲突,那么对要进行操作的数据副本到自己workspace之后,更新,完成之后验证所做的修改与数据库系统中并发执行的其他事务是一致的,验证阶段之后才进行提交,the write set is installed into the “global” database。

OCC Phases

  • 1-Read(work) Phase:跟踪事务读写集,存到自己workspace
  • 2-Validation Phase:txn commits,检查是否和其他事务冲突
  • 3-Write Phase:验证成功,apply,将私有空间所做的修改落地到主数据库否则abort+restart

Untitled

OCC在事务初始的时候并不分配时间戳,进入验证阶段才分配时间戳给事务,没分配前时间戳认为是无穷大。需要保证只有serializable才被允许,Ti检查和其他事务之间的RW和WW冲突,all conflicts go one way from older txns to younger txns。

OCC-SERIAL VALIDATION

保证串行化,需要全局视野,能看到系统中所有正在运行的活跃事务,记录运行事务的读写集,记录在事务的private workspace。

整个系统在validation阶段有一个大latch,确保一次只有一个事务执行验证操作

维护global view of all active txns,复制tuple保证了可重复读。

验证阶段拿到时间戳之后,查看系统其他并发事务,确保读写集不会交叉,有一个正确是序列化顺序.

如果说TS(Ti) < TS(Tj),那么下面三个条件之一必须成立???

commit → validation phase,两种验证方式

  • Backward Validation:找到所有比T2时间戳小(老)的不同事务,对他们执行验证操作,validation scope 验证作用域。检查提交txn的读/写集是否与任何已经提交的txn的读/写集相交,可能T1更新某个数据,该数据应该能被T2读到,但是没有,因为T1对私有副本做的修改,所以就需要abort T1?应该是T2

Untitled

  • Forward Validation:向未来看,看新事务,找到所有并发执行还没提交的事务,如果有一个T3要用,T2改了的,那么T2验证失败

Untitled

以forward validation为例:

  1. Ti 完成了所有的三个阶段,然后Tj才开始

    1. 很简单可串行化的
  2. Ti在Tj开始写阶段之前完成所有阶段,Ti的写集和Tj的读集不相交,则验证通过,否则验证失败。

    1. 下面的例子,Ti 写A 和 Tj 读A有交集,需要中止Ti,T2其实是读了一个过时的值。

      Untitled

    2. 如果说,T2先验证,那么在serial order里面T2 就是在T1之前执行的,T2读完A进入验证阶段,T2没有写集,没有相交,所以就验证通过。

    Untitled

  3. Ti在Tj完成Read phase之前完成了Ti的Read Phase,需要确保Ti的写集和Tj读集没有冲突,Ti写集和Tj写集没有冲突。

    1. Ti先进入验证阶段,可以提交,因为T2是read阶段是在T1 read阶段完成之后才开始的,或者说因为在T1验证阶段的时刻,T1写集和T2读集不冲突,因为T2只读到了B,还没读A

      Untitled

    2. 然后T2 R(A),进入验证阶段,验证成功因为没有并发事务了已经。 10.

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Tototototorres

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值