On Mixing Eventual and Strong Consistency: Bayou Revisited

Kokociński, Maciej; Kobus, Tadeusz; Wojciechowski, Paweł T.

doi:10.1145/3293611.3331583

Cited by 4 publications

(9 citation statements)

References 33 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Various consistency models in distributed system are presented in the survey [55]. In [56], the authors introduce the notion of Fluctuating Eventual Consistency which is the mix of eventual consistency and strong consistency in order to provide stronger guarantee for eventual consistency. However, this correctness property is not suitable for the adaptive behaviour of application since it is not sufficient to prevent violations as sequential consistency does, and it has more extra synchronization effort than eventual consistency.…”

Section: Distributed Data-storesmentioning

confidence: 99%

Using weaker consistency models with monitoring and recovery for improving performance of key-value stores

et al. 2019

View full text Add to dashboard Cite

Consistency properties provided by most key-value stores can be classified into sequential consistency and eventual consistency. The former is easier to program with but suffers from lower performance whereas the latter suffers from potential anomalies while providing higher performance. We focus on the problem of what a designer should do if he/she has an algorithm that works correctly with sequential consistency but is faced with an underlying key-value store that provides a weaker (e.g., eventual or causal) consistency. We propose a detect-rollback based approach: The designer identifies a correctness predicate, say P , and continues to run the protocol, as our system monitors P . If P is violated (because the underlying key-value store provides a weaker consistency), the system rolls back and resumes the computation at a state where P holds.We evaluate this approach with graph-based applications running on the Voldemort key-value store. Our experiments with deployment on Amazon AWS EC2 instances shows that using eventual consistency with monitoring can provide a 50% -80% increase in throughput when compared with sequential consistency. We also observe that the overhead of the monitoring itself was low (typically less than 4%) and the latency of detecting violations was small. In particular, in a scenario designed to intentionally cause a large number of violations, more than 99.9% of violations were detected in less than 50 milliseconds in regional networks (all clients and servers in the same Amazon AWS region), and in less than 3 seconds in global networks.We find that for some applications, frequent rollback can cause the program using eventual consistency to effectively stall. We propose alternate mechanisms for dealing with re-occurring rollbacks. Overall, for applications considered in this paper, we find that even with rollback, eventual consistency provides better performance than using sequential consistency.

show abstract

Section: Distributed Data-storesmentioning

confidence: 99%

Using weaker consistency models with monitoring and recovery for improving performance of key-value stores

et al. 2019

View full text Add to dashboard Cite

show abstract

“…The definition is, however, limited to systems that, unlike Creek, only feature read-only operations and updating operations that do not have a return value. To formalize Creek's correctness we use the framework and a property called fluctuating eventual consistency that we introduced in [24] (see Section V-B).…”

Section: Related Workmentioning

confidence: 99%

“…Our specification of Creek, shown in Algorithm 1, is rooted in the specification of the Bayou protocol [16] presented in [24]. We assume that clients submit requests to the system in the form of operations with encoded arguments (line 15), and await responses.…”

Section: A Basic Schemementioning

confidence: 99%

“…The most faithful description of the characteristics of Creek can be made using the framework from [24], where we analyze the behaviour and then formalize the guarantees of the seminal Bayou protocol [16]. Creek's principle of operation is very similar to Bayou's, and so Creek also exhibits some of Bayou's quirky behaviour.…”

Section: B Correctnessmentioning

confidence: 99%

“…When network partitions occur, replicas within each partition are still capable of executing weak operations and obtaining tentative responses to strong operations, and converging to the same state (when the stream of client request ceases). Formally Creek guarantees linearizability [23] for strong operations, and fluctuating eventual consistency [24] for weak operations.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Creek: Low-latency, Mixed-Consistency Transactional Replication Scheme

Kobus¹,

Kokociński²,

Wojciechowski³

2019

Preprint

Self Cite

View full text Add to dashboard Cite

In this paper we introduce Creek, a low-latency, eventually consistent replication scheme that also enables execution of strongly consistent requests. Creek disseminates the messages among the replicas using only a gossip protocol. Similarly to state machine replication (SMR), Creek totallyorders all requests, but does so using two different mechanisms: a timestamp-based one and one built on top of our novel broadcast primitive, conditional atomic broadcast (CAB). The former is used to establish a tentative order of all requests for speculative execution and works also within each partition, when partitioning of network occurs. On the other hand, CAB is used only for the strongly consistent requests to ensure their linearizable execution, and is available whenever distributed consensus can be solved. The execution of a strongly consistent request also stabilizes the execution order of the causally related weakly consistent requests. Creek uses multiversion concurrency control to efficiently handle requests' rollbacks and reexecutions resulting from the mismatch between the tentative and the final execution orders. In the tests conducted using the TPC-C benchmark, Creek offers up to 3 times lower latency in returning client responses compared to the state-of-the-art speculative SMR scheme, while maintaining high accuracy of the speculative execution (92-100%).

show abstract