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 show 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 ms in regional networks (all clients and servers in the same Amazon AWS region) and in less than 3 s 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.

中文翻译：

---

使用具有监控和恢复功能的较弱一致性模型来提高键值存储的性能

大多数键值存储提供的一致性属性可以分为顺序一致性和最终一致性。前者更容易编程，但性能较低，而后者在提供更高性能的同时存在潜在的异常情况。我们关注的问题是，如果设计者的算法在顺序一致性下正常工作，但面临提供较弱（例如，最终或因果）一致性的底层键值存储，他/她应该怎么做。我们提出了一种基于检测回滚的方法：设计者确定一个正确性谓词，比如 P，并继续运行协议，因为我们的系统监控 P。如果 P 被违反（因为底层键值存储提供了较弱的一致性），系统回滚并在 P 保持的状态恢复计算。我们使用在 Voldemort 键值存储上运行的基于图的应用程序来评估这种方法。我们在 Amazon AWS EC2 实例上的部署实验表明，与顺序一致性相比，使用最终一致性和监控可以将吞吐量提高 50-80%。我们还观察到监控本身的开销很低（通常小于 4%），并且检测违规的延迟很小。尤其是在故意造成大量违规的场景中，在区域网络（所有客户端和服务器在同一亚马逊AWS区域内）不到50毫秒和不到3秒的时间内检测到超过99.9%的违规在全局网络中，我们发现对于一些应用程序来说，频繁的回滚会导致使用最终一致性的程序有效地停顿。我们提出了处理重复发生回滚的替代机制。总的来说，对于本文中考虑的应用程序，我们发现即使有回滚，最终一致性也比使用顺序一致性提供更好的性能。