MVCC (多版本并发控制) 与SnapShot Isolation

本文主要是关于进程控制经典论文的内容记录

Concurrency Control in Distributed Database Systems

Centralized Transaction-Processing Model

A transaction T accesses the DBMS by issuing BEGIN, READ, WRITE, and END operations, which are processed as follows:

  • BEGIN: The TM initializes for T a private workspace that functions as a temporary buffer for values read from and written into the database.
  • 进程T建立了一个临时的buffer作为workspace。
  • READ(X): The TM looks for a copy of X in T’s private workspace. If the copy
    exists, its value is returned to T. Otherwise the TM issues din-read(x) to the DM to retrieve a copy of X from the database, gives the retrieved value to T, and puts it into T’s private workspace.
    读的时候,如果workshop里已经有了,就直接读,否则从数据库里获得这个值然后存到自己的workshop里。
  • WRITE(X, new-value): The TM again checks the private workspace for a copy of X. If it finds one, the value is updated to new-value; otherwise a copy of X with the new value is created in the workspace. The new value of X is not stored in the database at this time.
    写的时候,如果workshop有这个变量(可能是以前读过或者写过),那直接更新其在workshop里的值(但不更新其在数据库里的值)。如果workshop里没有这个变量,那么先从数据库里获得这个变量(我的理解应该是获得这个值在数据库中的索引办法,而不是获得这个变量的具体值 因为这个值马上要被覆盖了 没有意义)再把其新值写入workshop中。
  • END: The TM issues dm-write(x) for each logical data item X updated by T.
    Each dm-write(x) requests that the DM update the value of X in the stored database to the value of X in T’s local workspace. When all dm-writes are processed, T is finished executing, and its private workspace is discarded.
    提交的时候,才执行dm-write(x),也就是将变量的新值写入数据库中。

The DBMS may restart T any time before a din-write has been processed. The
effect of restarting T is to obliterate its private workspace and to reexecute T from the beginning. As we will see, many concurrency control algorithms use transaction restarts as a tactic for attaining correct executions(许多并发控制算法将事务重启视为获得正确执行的策略). However, once a single dm-write(x) has been processed, T cannot be restarted; each dm-write permanently installs an update into the database, and we cannot permit the database to reflect partial effects of transactions. (一旦dm-write被执行了,这意味着我们已经对数据库做出了不可挽回的改动!!那么这个进程一定不能被restart了。我们称之为原子性(atomic),就是一个进程里对数据的写操作必须是一个整体,都被执行或者都不被执行。)

The “standard” implementation of atomic commitment is a procedure called
two-phase commit. Suppose T is updating data items X and Y. When T issues its END, the first phase of two-phase commit begins, during which the DM issues prewrite commands for X and Y. These commands instruct the DM to copy the values of X and Y from T’s private workspace onto secure storage. If the DBMS fails during the first phase, no harm is done, since none of T’s updates have yet been applied to the stored database. During the second phase, the TM issues din-write commands for X and Y which instruct the DM to copy the values of X and Y into the stored database. If the DBMS fails during the second phase, the database may contain incorrect information, but since the values of X and Y are stored on secure storage, this inconsistency can be rectified when the system recovers: the recovery procedure reads the values of X and Y from secure storage and resumes the commitment activity.
这里讲的是经典的2PL方法。关于这个在后面的章节有具体的讨论。

一些基本概念 some basics:

Let E denote an execution of transactions T1,……,Tn。 E is a serial execution if no transactions execute concurrently in E. Every serial execution is defined to be correct. An execution is serializable if it is computationally equivalent to a serial execution, that is, if it produces the same output and has the same effect on the database as some serial execution. The goal of database concurrency control is to ensure that all executions are serializable.
Two operations conflict if they operate on the same data item and one of the operations is a dm-write. To illustrate the notion of conflict, consider a data item x and transactions Ti, and Tj. If Ti, issues dm-read (x) and Tj issues dm-write(x), the value read by Ti, will (in general) differ depending on whether the dm-read precedes or follows the dm-write. Similarly, if both transactions issue dm-write(x) operations, the final value of x depends on which dm-write happens last. Those conflict situations are called read-write (rw) conflicts and write-write (ww) conflicts, respectively.
有冲突的两个操作之间的先后顺序很重要。以此为依据 提出了ww和rw两种冲突。

To distinguish the two types of conflict:
在这里插入图片描述
在这里插入图片描述

SYNCHRONIZATION TECHNIQUES BASED ON TIMESTAMP ORDERING

Each transaction is assigned a unique timestamp by its TM. The TM attaches the timestamp to all dm-reads and dm-writes issued on behalf of the transaction, and DMs are required to process conflicting operations in timestamp order. The timestamp of operation O is denoted ts(O).
每个进程、进程内的读写操作都有其自己的timestamp.

如果不考虑2PL,T/O scheduler还是很简单的:对于DM和存储于其中的x,用R-ts(x)和W-ts(x)记录最新的 dm-read(x) dm-write(x) 的timestamp。

  • 对于read-write的情况:
    • 如果进程需要进行dm-read(x),其timestamp为TS,如果TS<W-tx(x),则读操作会被拒绝且当前进程被abort(因为这个值已经被写过了!);如果TS>=W-tx(x),则读取成功,并且 SET R-ts(x) = max(R-ts(x), TS)。(将R-ts(x)更新为最新值!)
    • 如果进程需要进行dm-write(x),其timestamp为TS,如果TS<R-tx(x), 则写操作会被拒绝(这个值被读过了!已经成为历史值,历史不可被改变!);否则写成功,并且SET W-ts(x) = max(W-ts(x),TS)。(记录最后一次写的时间)
  • 对于write-write的情况:
    • S rejects a dm-write(x) with timestamp TS if TS < W-ts(x); otherwise it outputs the dm-write and sets W-ts(x) to TS. (写只能先来后到。所以只需要判断一下自己是不是最后一个写进程就好了。如果自己的时间之后已经有人写了,自己就不能写了。)

然后文章给出了几种具体的基于2PL和T/O的MVCC算法。但是这个和relational database的关系不是特别大,这里只是一个高层次的概念抽象,而不涉及具体的表、外键等操作。

A Critique of ANSI SQL Isolation Levels

These discussions naturally suggest an isolation level, called Snapshot Isolation, in which each transaction reads reads data from a snapshot of the (committed) data as of the time the transaction started, called its Start-Timestamp. This time may be any time before the transaction’s first Read. A transaction running in Snapshot Isolation is never blocked attempting a read as long as the snapshot data from its Start-Timestamp can be maintained. The transaction’s writes (updates, inserts, and deletes) will also be reflected in this snapshot, to be read again if the transaction accesses (i.e., reads or updates) the data a second time. Updates by other transactions active after the transaction Start-Timestamp are invisible to the transaction.
就是Transaction被赋予了时间标签(TimeStamp),记载其开始、结束的时间。只有在本进程A的start time晚于其他进程B的commit time时,B更新的数据才对A可见。

When the transaction T1 is ready to commit, it gets a Commit-Timestamp, which is larger than any existing Start-Timestamp or Commit-Timestamp. The transaction
successfully commits only if no other transaction T2 with a Commit-Timestamp in T1’s execution interval [Start- Timestamp, Commit-Timestamp] wrote data that T1 also wrote. Otherwise, T1 will abort. This feature, called Firstcommitter-wins prevents lost updates (phenomenon P4). When T1 commits, its changes become visible to all transactions whose Start-Timestamps are larger than T1‘s Commit-Timestamp.
进程提交采取Firstcommitter-wins。如果本进程A执行期间修改了数据x,但另一个进程在A提交之前也修改了x并成功提交,那么A就会提交失败。

At any time, each data item might have multiple versions, created by active and committed transactions. Reads by a transaction must choose the appropriate version.
同一时间内数据会有多个版本,进程必须知道应该读那个版本才是正确的。

文章后面又进行了讨论,证明了snapshot的隔离性是在read-committed之上的。但是与repeatable read相比,各有各的优势。不能界定谁的隔离性更高(因为竞态条件的情况是多变的。这里给出了很多竞态条件的情况并依次讨论在不同隔离方法下其是否可以被杜绝。)

现在需要找一下与图数据库相关的MVCC算法。准备在另一篇博文中写

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值