-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
fe6f2cc
commit 798ec8c
Showing
1 changed file
with
60 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,60 @@ | ||
# Don’t Settle for Eventual: Scalable Causal Consistency for Wide-Area Storage with COPS | ||
|
||
Wyatt Lloyd, Michael J. Freedman, Michael Kaminsky, and David G. Andersen | ||
|
||
## Summary | ||
|
||
The authors introduce Causal+ consistency, or causal consistency with | ||
convergent conflict resolution. For the conflic resolution, they use the | ||
principle of "last writer wins". They present COPS, a rather lazily | ||
acronymed Key-Value store built on this idea, and support transactions in | ||
COPS-GT an even more lazily named modification of the key value store. | ||
|
||
The authors state that the earlier implementations were Causal+ too, but did | ||
not have great scalability. The system they have in mind is an ALPS system | ||
Availability, Low Latency, Partition-tolerance and Scalability being the | ||
important required properties. | ||
|
||
Since linearizability is impossible to achieve in this scenario, the best | ||
level of consistency you can guarantee is Causal. However Causality places | ||
no restrictions on partitions diverging permanently with different data. | ||
This is however a desirable property, and that's where the convergent | ||
conflict resolution is required. | ||
|
||
The conflict detection adds a dependency on the previous version for key | ||
update, causing a dependency check to happen, in order to detect conflicts | ||
which then are resolved using the last write wins rule. | ||
|
||
## Interesting Points | ||
|
||
The chief contribution of this paper is the scalable convergent conflict | ||
handling the COPS system offers. However the paper seems to be split upon | ||
what to talk about. It talks about ALPS, and a significant chunk of the | ||
paper is dedicated to the key value store and its evaluation, but from my | ||
understanding of it, COPS is a proof of concept rather than a key-value | ||
store they plan to release or design. | ||
|
||
It just seemed to me that more space could have been given the the conflict | ||
handline (relegated to 1 paragraph) as opposed to the client libraries and | ||
consistency models. | ||
|
||
The results look good, however the comparison with other systems seems to | ||
bee limited and focused on only LOG exchange. The dependency vs throughput | ||
graphs are useful, but most of the evaluation is limited to COPS and COPS-GT | ||
|
||
|
||
## Research level question | ||
|
||
The authors claim that Causal+ consistency (done their way) is the best | ||
possible consistency condition you can get for a system that focuses on | ||
ALPS. Is this true? Can you do better? | ||
|
||
## Closing thoughts | ||
|
||
I do not think the paper was well written. It is extremely self indulgent | ||
(we are the first/ this is the best possible multiple times) and makes some | ||
bold claims for what seems to be a fairly straightforward idea. | ||
|
||
The paper isn't well organized or written, it is repetitive, it focuses on | ||
minute details where unnecessary and glosses over where it would have been | ||
helpful, it is repetitive. |