A Critique of Snapshot Isolation论文阅读

A Critique of Snapshot Isolation

摘要

对事物的支持是DBMS的一个重要部分。没有这个支持的话，开发人员会受到尽管同时访问数据库会出现失败也要确保事务的原子执行的困扰。最理想的是，一个事务系统提供串行化，也就是意味着同时发生的事务的输出对于他们的串行执行是公平的。然而，基于锁实现的经验来说，串行化会带来高开销和低并行。 因此商业系统通过串行化这种来实现像隔离快照这样更弱的保证。但是开发人员仍然受到由于缺少串行化而出现的异常的困扰。
近期已经尝试通过事务支持里丰富大规模数据存储，例如HBase和BigTable。不足为奇的是，受传统数据库管理系统的启发，为了提高效率，串行化通常会受到影响。我们在这篇论文中展示了这种折中在无锁实现的事务支持中是没有必要的。我们介绍了写隔离级别(write-sanpshot isolation)，一个独一无二的隔离级别，并且提供了串行化。不同于快照隔离(snapshot isolation)中禁止谢谢冲突，写快照隔离是禁止读写冲突。

引言

一个事务是一个原子执行操作的集合，也许会包含对数据库的多个读写操作。一个可靠的事务系统提供ACID保证：原子性、一致性、隔离性和持久性。隔离性定义了存在同时发生的事务时系统的行为。 最理想化的隔离级别是提供串行化。但是串行化会带来一些缺点：

（1）较高的实现开销。
（2）较低的并发性。

• 写写冲突(write-write conflict)：
  两个同时发生的事务修改相同的数据项。

• 快照隔离（snapshot isolation）的优点:

1. 只检测写写冲突。
   基于锁的实现非常直接：事务在修改数据项前先上锁，如果该数据项已经被锁了，那么久等待或者回滚。
2. 对于只读事务，不需要锁开销。
3. 缺点是实现串行化需要检测快照隔离没有提供的读写冲突。在基于锁的情况下，开销比较大。

这篇论文分析了写写冲突和读写冲突。解释了系统在允许写写冲突的情况下也能实现串行化。证明了读写冲突检测对于实现串行化是足够的。提出了写快照隔离（write-snapshot isolation），一个用读写冲突检测代替写写冲突检测的新的隔离级别。

• 主要贡献：

1. 我们分析了快照隔离和串行化的核心思想。
2. 我们提出了写快照隔离。
3. 我们证明了写快照隔离能提供串行化。
4. 我们提出了一个在HBase上写快照隔离无锁的实现。展示了虽然写快照隔离能够提供串行化，但是在实现开销和并发性级别上和快照隔离是可比较的。

2. 快照隔离

这部分主要是快照隔离基于锁和无锁实现的概述。
快照隔离能够保证事务的读不被同时发生的事务所影响。为了实现快照隔离，数据库需要在数据服务端维持数据的多个版本，客户端的事务通过它们的起始时间戳来查找不同版本的数据。隔离快照实现的优点是一个事务的写操作不会阻塞其他事务的读操作。

• 两个事务会在下面的情况下产生冲突：

1. 空间重叠（Spatial overlap）：同时修改行r。
2. 时间重叠（Temporal overlap）：T_s(txn_i) < T_c(txn_j) and T_s(txn_j) < T_c(txn_i).

2.1 基于锁的快照隔离实现

Percolator增加了两列：lock和write。write用来维持提交时间戳。通过2PC算法在所有被修改的数据项上更新这个列。虽然使用锁简化了写写冲突检测，但是失败或缓慢事务持有的锁会阻止其他事务在恢复过程中取得进展。

2.2 无锁的快照隔离实现