An empirical evaluation of in-memory multi-version concurrency control

Wu, Yingjun; Arulraj, Joy; Lin, Jiexi; Xian, Ran; Pavlo, Andrew

doi:10.14778/3067421.3067427

Cited by 127 publications

(77 citation statements)

References 35 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Each transaction accesses two records from the hot set and the remaining eight from the cold set. We use this microbenchmark as it has also been used in several studies for evaluating the scalability of OLTP engines under high contention [36,43,45,47].…”

Section: Benchmarks and Methodologymentioning

confidence: 99%

“…While we do not consider CC protocols based on multi-versioned storage as they add additional dimensions, like garbage collection, we do consider the two-version variant of the NO WAIT protocol (2V NO WAIT [4]) that exploits undo logging performed by single-version storage to improve concurrency between readers and writers. A recent study has explored other dimensions in implementing MVCC protocols [45]. In the rest of this section, we provide a high-level overview of the CC protocols supported by Trireme.…”

Section: Protocolsmentioning

confidence: 99%

“…As our work focuses on studying the interaction between process models and concurrency control protocols in the main-memory OLTP context, similarly to recent studies [36,45,47], we restrict our focus to the concurrency control module to avoid confounding effects.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Analyzing the impact of system architecture on the scalability of OLTP engines for high-contention workloads

et al. 2017

View full text Add to dashboard Cite

Main-memory OLTP engines are being increasingly deployed on multicore servers that provide abundant thread-level parallelism. However, recent research has shown that even the state-of-the-art OLTP engines are unable to exploit available parallelism for high contention workloads. While previous studies have shown the lack of scalability of all popular concurrency control protocols, they consider only one system architecture-a non-partitioned, shared everything one where transactions can be scheduled to run on any core and can access any data or metadata stored in shared memory.In this paper, we perform a thorough analysis of the impact of other architectural alternatives (Data-oriented transaction execution, Partitioned Serial Execution, and Delegation) on scalability under high contention scenarios. In doing so, we present Trireme, a main-memory OLTP engine testbed that implements four system architectures and several popular concurrency control protocols in a single code base. Using Trireme, we present an extensive experimental study to understand i) the impact of each system architecture on overall scalability, ii) the interaction between system architecture and concurrency control protocols, and iii) the pros and cons of new architectures that have been proposed recently to explicitly deal with high-contention workloads.

show abstract

Section: Benchmarks and Methodologymentioning

confidence: 99%

Section: Protocolsmentioning

confidence: 99%

See 1 more Smart Citation

Analyzing the impact of system architecture on the scalability of OLTP engines for high-contention workloads

et al. 2017

View full text Add to dashboard Cite

show abstract

“…Apart from this, these version chains must be garbage collected from time to time to remove versions that are not visible to any transaction in the system. Garbage collection is typically done by a separate thread, which frequently traverses these chains to locate and delete outdated versions [12,25,26]. This thread has to be managed and synchronized with the transaction processing, utilizing precious system resources.…”

Section: Limitations Of Mvccmentioning

confidence: 99%

Accelerating Analytical Processing in MVCC using Fine-Granular High-Frequency Virtual Snapshotting

Sharma

Schuhknecht

Dittrich

2018

Proceedings of the 2018 International Conference on Management of Data

View full text Add to dashboard Cite

Efficient transaction management is a delicate task. As systems face transactions of inherently different types, ranging from point updates to long-running analytical queries, it is hard to satisfy their requirements with a single execution engine. Unfortunately, most systems rely on such a design that implements its parallelism using multi-version concurrency control. While MVCC parallelizes shortrunning OLTP transactions well, it struggles in the presence of mixed workloads containing long-running OLAP queries, as scans have to work their way through vast amounts of versioned data. To overcome this problem, we reintroduce the concept of hybrid processing and combine it with state-of-the-art MVCC: OLAP queries are outsourced to run on separate virtual snapshots while OLTP transactions run on the most recent version of the database. Inside both execution engines, we still apply MVCC.The most significant challenge of a hybrid approach is to generate the snapshots at a high frequency. Previous approaches heavily suffered from the high cost of snapshot creation. In our approach termed AnKer, we follow the current trend of co-designing underlying system components and the DBMS, to overcome the restrictions of the OS by introducing a custom system call vm_snapshot. It allows fine-granular snapshot creation that is orders of magnitudes faster than state-of-the-art approaches. Our experimental evaluation on an HTAP workload based on TPC-C transactions and OLAP queries show that our snapshotting mechanism is more than a factor of 100x faster than fork-based snapshotting and that the latency of OLAP queries is up to a factor of 4x lower than MVCC in a single execution engine. Besides, our approach enables a higher OLTP throughput than all state-of-the-art methods.

show abstract

“…Transaction throughput is related to response time, higher transaction throughput means lower response time. For this concurrency control, most DBMSs use locks and two-phase locking (2PL) protocol [5], [6]. In 2PL, locks prevent other requests from accessing a database item in use (Table 1).…”

Section: Figure 1 Architecture Of Sensor Network (Fire Monitoring)mentioning

confidence: 99%

Untitled

2017

IJDCASD

View full text Add to dashboard Cite

show abstract

An empirical evaluation of in-memory multi-version concurrency control

Cited by 127 publications

References 35 publications

Analyzing the impact of system architecture on the scalability of OLTP engines for high-contention workloads

Analyzing the impact of system architecture on the scalability of OLTP engines for high-contention workloads

Accelerating Analytical Processing in MVCC using Fine-Granular High-Frequency Virtual Snapshotting

Untitled

Contact Info

Product

Resources

About