内存中多版本并发控制的实证评价 PDF 下载
ion that each of them is executing alone on a dedicated system .
It ensures the atomicity and isolation guarantees of the DBMS.
There are several advantages of a multi-version system that are
relevant to modern database applications. Foremost is that it can
potentially allow for greater concurrency than a single-version sys-
tem. For example, a MVCC DBMS allows a transaction to read an
older version of an object at the same time that another transaction
updates that same object. This is important in that execute read-only
queries on the database at the same time that read-write transactions
continue to update it. If the DBMS never removes old versions,
then the system can also support “time-travel” operations that allow
an application to query a consistent snapshot of the database as it
existed at some point of time in the past .
The above benefits have made MVCC the most popular choice
for new DBMS implemented in recent years. Table 1 provides a
summary of the MVCC implementations from the last three decades.
But there are different ways to implement multi-versioning in a
DBMS that each creates additional computation and storage over-
head. These design decisions are also highly dependent on each
other. Thus, it is non-trivial to discern which ones are better than
others and why. This is especially true for in-memory DBMSs
where disk is no longer the main bottleneck.
In the following sections, we discuss the implementation issues
and performance trade-offs of these design decisions. We then
perform a comprehensive evaluation of them in Sect. 7. We note
that we only consider serializable transaction execution in this paper.
Although logging and recovery is another important aspect of a
DBMS’s architecture, we exclude it from our study because there is
nothing about it that is different from a single-version system and
in-memory DBMS logging is already covered elsewhere [33, 49].
2.2 DBMS Meta-Data
Regardless of its implementation, there is common meta-data that
a MVCC DBMS maintains for transactions and database tuples.
Transactions: The DBMS assigns a transaction T a unique,
monotonically increasing timestamp as its identifier (T id ) when
they first enter the system. The concurrency control protocols use
this identifier to mark the tuple versions that a transaction accesses.
Some protocols also use it for the serialization order of transactions.
Tuples: As shown in Fig. 1, each physical version contains four
meta-data fields in its header that the DBMS uses to coordinate
the execution of concurrent transactions (some of the concurrency
control protocols discussed in the next section include additional
fields). The txn-id field serves as the version’s write lock. Every
tuple has this field set to zero when the tuple is not write-locked.
MostDBMSsusea64-bit txn-id sothatitcanuseasinglecompare-
and-swap (CaS) instruction to atomically update the value. If a
transaction T with identifier T id wants to update a tuple A , then the
DBMS checks whether A ’s txn-id field is zero. If it is, then DBMS
will set the value of txn-id to T id using a CaS instruction [27, 44].
txn-id end-ts … pointer
Figure 1: Tuple Format – The basic layout of a physical version of a tuple.
Any transaction that attempts to update A is aborted if this txn-id
field is neither zero or not equal to its T id . The next two meta-data
fields are the begin-ts and end-ts timestamps that represent the
lifetime of the tuple version. Both fields are initially set to zero. The
DBMS sets a tuple’s begin-ts to INF when the transaction deletes
it. The last meta-data field is the pointer that stores the address of
the neighboring (previous or next) version (if any).
Every DBMS includes a concurrency control protocol that coor-
dinates the execution of concurrent transactions . This protocol
determines (1) whether to allow a transaction to access or modify a
particular tuple version in the database at runtime, and (2) whether to
allow a transaction to commit its modifications. Although the funda-
mentals of these protocols remain unchanged since the 1980s, their
performance characteristics have changed drastically in a multi-core
and main-memory setting due to the absence of disk operations .
As such, there are newer high-performance variants that remove
locks/latches and centralized data structures, and are optimized for
In this section, we describe the four core concurrency control
protocols for MVCC DBMSs. We only consider protocols that use
tuple-level locking as this is sufficient to ensure serializable exe-
cution. We omit range queries because multi-versioning does not
bring any benefits to phantom prevention . Existing approaches
to provide serializable transaction processing use either (1) addi-
tional latches in the index [35, 44] or (2) extra validation steps when
transactions commit .
3.1 Timestamp Ordering ( MVTO )
The MVTO algorithm from 1979 is considered to be the original
multi-version concurrency control protocol [38, 39]. The crux of
this approach is to use the transactions’ identifiers (T id ) to pre-
compute their serialization order. In addition to the fields described
in Sect. 2.2, the version headers also contain the identifier of the last
transaction that read it ( read-ts ). The DBMS aborts a transaction
that attempts to read or update a version whose write lock is held by
When transaction T invokes a read operation on logical tuple A ,
the DBMS searches for a physical version where T id is in between
the range of the begin-ts and end-ts fields. As shown in Fig. 2a,
T is allowed to read version A x if its write lock is not held by another
active transaction (i.e., value of txn-id is zero or equal to T id )
because MVTO never allows a transaction to read uncommitted
versions. Upon reading A x , the DBMS sets A x ’s read-ts field to T id
if its current value is less than T id . Otherwise, the transaction reads
an older version without updating this field.
*** 次数：10600 已用完，请联系开发者***
IO 源码网 » 内存中多版本并发控制的实证评价 PDF 下载
IO 源码网 » 内存中多版本并发控制的实证评价 PDF 下载
- 本站所有资源版权均属于原作者所有，这里所提供资源均只能用于参考学习用，请勿直接商用。若由于商用引起版权纠纷，一切责任均由使用者承担。更多说明请参考 VIP介绍。
- 最常见的情况是下载不完整: 可对比下载完压缩包的与网盘上的容量，若小于网盘提示的容量则是这个原因。这是浏览器下载的bug，建议用百度网盘软件或迅雷下载。若排除这种情况，可在对应资源底部留言，或 联络我们.。
- 对于PPT，KEY，Mockups，APP，网页模版等类型的素材，文章内用于介绍的图片通常并不包含在对应可供下载素材包内。这些相关商业图片需另外购买，且本站不负责(也没有办法)找到出处。 同样地一些字体文件也是这种情况，但部分素材会在素材包内有一份字体下载链接清单。