Coordination avoidance in database systems

Bailis, Peter; Fekete, Alan; Franklin, Michael J.; Ghodsi, Ali; Hellerstein, Joseph M.; Stoica, Ion

doi:10.14778/2735508.2735509

Cited by 154 publications

(138 citation statements)

References 51 publications

Supporting

Mentioning

136

Contrasting

Order By: Relevance

“…This concept is related to the I-confluence of Bailis et al [5]. I-confluence defines the conditions under which operations may execute concurrently, while still ensuring that the system converges to an I-valid state.…”

Section: Definition 22 (Explicit Consistency) a System Provides Expmentioning

confidence: 99%

Putting consistency back into eventual consistency

Balegas

Duarte

Ferreira

et al. 2015

Proceedings of the Tenth European Conference on Computer Systems

102

125

View full text Add to dashboard Cite

Geo-replicated storage systems are at the core of current Internet services. The designers of the replication protocols used by these systems must choose between either supporting low-latency, eventually-consistent operations, or ensuring strong consistency to ease application correctness. We propose an alternative consistency model, Explicit Consistency, that strengthens eventual consistency with a guarantee to preserve specific invariants defined by the applications. Given these application-specific invariants, a system that supports Explicit Consistency identifies which operations would be unsafe under concurrent execution, and allows programmers to select either violation-avoidance or invariant-repair techniques. We show how to achieve the former, while allowing operations to complete locally in the common case, by relying on a reservation system that moves coordination off the critical path of operation execution. The latter, in turn, allows operations to execute without restriction, and restore invariants by applying a repair operation to the database state. We present the design and evaluation of Indigo, a middleware that provides Explicit Consistency on top of a causally-consistent data store. Indigo guarantees strong application invariants while providing similar latency to an eventually-consistent system in the common case.

show abstract

Section: Definition 22 (Explicit Consistency) a System Provides Expmentioning

confidence: 99%

Putting consistency back into eventual consistency

Balegas

Duarte

Ferreira

et al. 2015

Proceedings of the Tenth European Conference on Computer Systems

102

125

View full text Add to dashboard Cite

show abstract

“…While pre-execution tries to identify records read and written by transactions without any application semantics, recent work has also shown the benefit of using application semantics explicitly to modify transaction run time with the goal of minimizing, or even avoiding, conflicting operations [3,30,38,44,46]. Given that all CC protocols suffer under highconflict workloads, such techniques, if applicable, will definitely assist in improving the scalability of all architectures.…”

Section: Implications Of Our Analysismentioning

confidence: 99%

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

“…Eventual consistency eliminates the need for synchronous distributed transactions, but it makes programming transactional applications harder, with consistency checks left to the application layer. A promising approach for improving efficiency of distributed transactions is using semantic information about the workload to avoid unnecessary coordination [5].…”

Section: Shared-nothing Database Deploymentsmentioning

confidence: 99%

Characterization of the Impact of Hardware Islands on OLTP

Porobic

Pandis

Branco³

et al. 2015

The VLDB Journal

View full text Add to dashboard Cite

Modern hardware is abundantly parallel and increasingly heterogeneous. The numerous processing cores have non-uniform access latencies to the main memory and processor caches, which causes variability in the communication costs. Unfortunately, database systems mostly assume that all processing cores are the same and that microarchitecture differences are not significant enough to appear in critical database execution paths. As we demonstrate in this paper, however, non-uniform core topology does appear in the critical path and conventional database architectures achieve suboptimal and even worse, unpredictable performance. We perform a detailed performance analysis of OLTP deployments in servers with multiple cores per CPU (multicore) and multiple CPUs per server (multisocket). We compare different database deployment strategies where we vary the number and size of independent database instances running on a single server, from a single shared-everything instance to fine-grained shared-nothing configurations. We quantify the impact of non-uniform hardware on various deployments by (a) examining how efficiently each deployment uses the available hardware resources and (b) measuring the impact of distributed transactions and skewed requests on different workloads. We show that no strategy is optimal for all cases and that the best choice depends on the combination of hardware topology and workload characteristics. Finally, we argue that transaction processing systems must be aware of the hardware topology in order to achieve predictably high performance.

show abstract

Coordination avoidance in database systems

Cited by 154 publications

References 51 publications

Putting consistency back into eventual consistency

Putting consistency back into eventual consistency

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

Characterization of the Impact of Hardware Islands on OLTP

Contact Info

Product

Resources

About