CMU Database Systems - Timestamp Ordering Concurrency Control

2PL是悲观锁，Pessimistic，这章讲乐观锁，Optimistic，单机的，非分布式的

Timestamp Ordering，以时间为序，这个是非常自然的想法，按每个transaction的时间来排谁先执行

这里会有几个问题，Timestamp是什么，由谁来打，什么时候打上Timestamp

首先每个T需要有一个unique的timestamp，这个在单机很容易实现；

其次，Timestamp必须是单调递增的

最后，不同的schema会选择在不同的时间给txn打上timestamp，可能是txn刚到的时候，也可能是txn执行完的时候

Timestamp可以有多种形式，系统时间，逻辑counter，或者hybrid

Basic Timestamp Ordering Protocol

设计比较直觉，

首先，给每个object加上，读时间戳，写时间戳，表示最后一次读写该对象的时间

读的时候，拿当前事务ts和写ts比较，如果写ts比较新，那么读需要abort，因为，你不能读一个未来的值；

写的时候，要同时比较该对象的读，写ts，比较写是因为你不能用过去的值覆盖未来的值，比较读，是因为如果有未来的txn读过这个值，你就不能再更新

同时，这里无论读写，都会把当前的value，copy到local进行缓存，这是避免txn频繁冲突，因为对于一个txn数据应该可以重复读的，所以如果不缓存，那么如果这个值被别的txn改了，会很容易导致txn abort

例子，

T1在更新A的时候，ts已经小于W-TS，所以不能更新，需要abort

Thomas write rule，一种降低abort概率的方法

思路如果txn在write的时候发现，W-TS大，即未来的时间，那么直接跳过这个write，因为这个write反正都是被覆盖的，所以不关键；

用Basic T/O产生的shedule是不可recoverable的

什么叫recoverable，当你commit的时候，你所依赖的所有txn已经完成commit；

这样才是可恢复的，不然你commit完后，数据库crash了，那么你之前看到的或依赖的txn还没有commit就丢失了，但你的结果已经完成commit，就产生不一致

Basic T/O的问题，

1. 不可recoverable

2. overhead比较重，需要每次读写都更新ts，而且还需要把数据copy到local

3. 长txn会starve，比较难成功，因为很容易被冲突，abort

乐观锁，基于的假设，冲突极少发生，否则乐观锁的成本反而更加高

所以基于这样的假设，那么算法可以进一步优化，OCC算法

分3个阶段，

1. 每个txn都创建一个独立的workspace，无论读写，都把数据copy到自己的workspace里面进行操作

2. validate，这个txn是否和其他txn冲突

3. 如果不冲突，把变更合并到global数据库

可以看到，其中比较难的是第二步，validation

validation就是判断当前txn和所有其他的txn是否有WR或WW冲突

首先假设同时只有一个txn进行validation，即serial validation

然后txn的ts是在validation阶段的开始被assign的，这个很关键

如何check当前txn和其他所有的txn之间是否有冲突？

如果Ti 先于 Tj，那么我们要满足以下3个条件中的一个

1. Ti在Tj开始之前，完成所有3个阶段，就是串行执行，这个肯定没有冲突

2. Ti在Tj开始Write phase前完成，并且Ti没有写任何会被Tj读到的对象

例子，

T1写了A，而在T2中会读到A，这样就不满足上面的条件2

这种情况是安全的，因为这个时候T2也已经结束了，并且T2只是读了A当并没有写任何数据

3. Ti的Read phase比Tj的Read phase早结束，并且Ti没有写任何会被Tj读或写到的对象

例子，

这个例子T1在validation的时候，T2没有读或写A，所以安全的，把T1的结果提交到Database

然后这个时候T2读A，是不会有问题的

OCC算法的性能问题，

也要把数据copy到本地，比较高的overhead

Validation和Write会成为瓶颈，因为这里需要串行

Abort的代价更高，因为这里txn已经做完了，才会validation判断是否要abort

OCC算法，还有明显的性能问题，当txn很多的时候，每个txn提交，都需要去判断是否和其他的txn冲突，就算没有冲突，但是每次比较的代价也是非常高的

所以提出Partition-based T/O，如果数据水平划分成很多partition，那么在每个partition上的txn就会变少，比较txn之间的冲突的效率就会提升

Partitioned T/O的性能问题是，

如果每个txn都只访问一个partition，那么性能会比较好

幻读

之前的txn都是读写，但是没有insert或delete

所以对于下面的情况，2PL是不管用的，因为锁机制只能锁已经存在的tuple，所以这个问题是Phantom，幻读

解决这个问题的方法，

predict locking，满足这个predict的records都lock，这个很难实现

对于predict locking一种可能的实现方式是，index locking，锁包含这个predict的index page

如果没有合适的index，只能锁表上的每一页或直接锁table

通过重复查询来判断是否有幻读，很低效的方式，一般数据库都不会采用

这里最后再讲一个概念，隔离级别

最强的就是之前一直在讲的，serializable，虽然有最强的一致性，但也大大牺牲了数据库的并发性

但是有的应用和场景，其实不需要那么强的一致性，所以可以牺牲一些一致性来换取一定的并发性

不同的隔离级别会产生哪些不一致情况在右图可以看出

那么如何实现这些隔离级别？

列出在 SQL 标准中，如果设置隔离级别

这里列存各个数据库引擎，默认的和支持的隔离级别