Low overhead concurrency control for partitioned main memory databases

Abstract

Database partitioning is a technique for improving the performance of distributed OLTP databases, since "single partition" transactions that access data on one partition do not need coordination with other partitions. For workloads that are amenable to partitioning, some argue that transactions should be executed serially on each partition without any concurrency at all. This strategy makes sense for a main memory database where there are no disk or user stalls, since the CPU can be fully utilized and the overhead of traditional concurrency control, such as two-phase locking, can be avoided. Unfortunately, many OLTP applications have some transactions which access multiple partitions. This introduces network stalls in order to coordinate distributed transactions, which will limit the performance of a database that does not allow concurrency.In this paper, we compare two low overhead concurrency control schemes that allow partitions to work on other transactions during network stalls, yet have little cost in the common case when concurrency is not needed. The first is a light-weight locking scheme, and the second is an even lighter-weight type of speculative concurrency control that avoids the overhead of tracking reads and writes, but sometimes performs work that eventually must be undone. We quantify the range of workloads over which each technique is beneficial, showing that speculative concurrency control generally outperforms locking as long as there are few aborts or few distributed transactions that involve multiple rounds of communication. On a modified TPC-C benchmark, speculative concurrency control can improve throughput relative to the other schemes by up to a factor of two.

A formal characterization of SI-based ROWA replication protocols

“…Recently, a couple of systems have been developed to support transactions in cloud-based environments. All of them assume a data storage rather than a DBMS in each replica and data partitioning [11,3,32,17]. They take advantage of the fact that transactions only access a small portion of data (i.e., a partition); hence, they define a primary replica for each partition where update transactions are executed, while read-only transactions can be executed on any replica storing a copy of that partition.…”

Scalable Transactions in the Cloud: Partitioning Revisited

“…Replicas are owners of one or several partitions, whose assignment can be changed on the fly by a data repository manager, and are entirely responsible for the execution of transactions over that partition. Actually, if the partition can be stored in main memory and the workload consists of transactions whose content can be known in advance (e.g., stored procedures) then transactions can be executed serially in each partition without wasting resources [11,12]. Nevertheless, if transactions can potentially access several partitions then we have network stalls that have to be reduced to the maximum.…”

“…Another way of overcoming stalls is through the speculative execution of transactions, which is an optimistic approach shown to be useful in [11]. If transactions are decomposed into smaller actions, each one accessing to a different partition, then these actions can be forwarded to the corresponding partitions, where they are serially executed, along with actions coming from other transactions, by a single thread assigned to that partition [12].…”

“…As we have already mentioned, we prefer to rely on a single total-order delivered message rather than a shared object which can be a single point of failure or storing the set of executed speculative actions to undo them. We believe our approach does not block the execution of transactions in the system and can take all the benefits of these approaches [11,12].…”

“…Namely, there have been several attempts to provide transactional support in the cloud [8][9][10][11][12]. These systems aim at providing high scalability and availability and yet still provide data consistency guarantees by supporting some types of transactions.…”