pbailis

7 ms·

31.
by pbailis 15y ago
If you can bound partition durations, you can definitely make stronger guarantees. If you can model your network delays, you can use some modeling like our work on PBS (Probabilistically Bounded Staleness) to predict staleness: http://pbs.
32.
by pbailis 15y ago
Eventual consistency is definitely weak, but it's useful: if we couple eventual convergence with safety properties, then we can describe non-trivial properties. The problem, which I alluded to in my first footnote, is that it's hard to guar
33.
by pbailis 15y ago
I'm not sure I entirely follow your argument. I agree that you can use some sort of heartbeat protocol or negative acknowledgments to determine whether writes occurred within a given time window (e.g., I haven't heard from the cluster, so
34.
by pbailis 15y ago
You're right--I definitely simplified the discussion of handling concurrent writes. Keeping around concurrent versions and using user-specified merge functions are two ways of deciding which versions to store. Riak indeed supports keeping
35.
Safety and liveness: Eventual consistency is not safe(bailis.org)
44 points by pbailis 15y ago|13 comments
36.
by pbailis 15y ago
If the network latency is negligible, this sounds reasonable. However, the mapping of 2x IOPs to 2x cost seems tenuous to me. >Someone who wanted an interesting research project might be able to pull back the covers on DynamoDB a bit by
37.
by pbailis 15y ago
For a fixed amount of throughput, if I want consistent reads, I pay x dollars. If I'm okay with eventual consistency, I can pay x/2 dollars and get the same throughput. Conflating resource usage, pricing, and consistency using a single metr
38.
What's Wrong with Amazon's DynamoDB Pricing?(bailis.org)
13 points by pbailis 15y ago|8 comments
39.
by pbailis 15y ago
Right; you need some notion of a total order or commutativity in your update functions. f(A,B) = f(B,A). "Last writer wins" is one example of commutativity, but that isn't often what you want. What you want is something like a "Commutative
40.
by pbailis 15y ago
You make a good point. Without additional safeguards/depending on implementation, W=1 can indeed mean "durability of one". This also depends on your failure model. If your node crashed (RAM cleared) and your durable storage broke, you're i
41.
by pbailis 15y ago
Shameless plug: Interactive Demo: http://bailis.org/projects/pbs/#demo PBS for Cassandra: https://github.com/pbailis/cassandra-pbs
42.
by pbailis 15y ago
This depends. Even with W=R=1, you still send each read/write to every replica. If the replica that acknowledged the write fails, the other two replicas should eventually receive the write. But--what happens if the write messages to the oth
43.
by pbailis 15y ago
Eventual consistency isn't about "losing writes". It's about how long it will take for all of your replicas to agree on/observe the last written versions and, in the meantime, you'll read potentially stale data. Certain data structures inhe
44.
by pbailis 15y ago
The Berkeley EECS NFS mount is chugging, so I've mirrored the site at: http://cs.harvard.edu/~pbailis/pbs-mirror/#demo
45.
Show HN: How eventual is eventual consistency?(cs.berkeley.edu)
29 points by pbailis 15y ago|2 comments