3 ms·

I really loved reading "CAP Twelve Years Later: How the "Rules" Have Changed". This sentence nailed what I thought was wrong with some early decisions in NoSQL

I really loved reading "CAP Twelve Years Later: How the "Rules" Have Changed". This sentence nailed what I thought was wrong with some early decisions in NoSQL systems: "because partitions are rare, there is little reason to forfeit C or A when the system is not partitioned."

michaelt 12y ago
If you duplicate your data in locations a few hundred milliseconds apart (e.g. America, Europe and Asia [1]) you either need to tolerate inconsistency or have every write take a few hundred milliseconds. If your system requires response times faster than that, the data centres you don't have time to contact behave sort of like they are partitioned all the time. Me, I tolerate writes that take a bit longer to keep things simple :) [1] http://www.nsmith.net/articles/2011-08/latency-between-amazon-web-services-regions/ http://www.nsmith.net/articles/2011-08/latency-between-amazo...
- St-Clock 12y ago
  "Me, I tolerate writes that take a bit longer to keep things simple :)" It's not just to keep things simple, it's to keep things consistent :-) Some NoSQL systems (e.g., MongoDB) introduced a new P in the equation (Performance) and used this to justify a lot of questionable decisions that affected consistency (and durability!). They have come a long way since these early decisions though. If a system considers moderate latency as a partition, it would need to perform partition recovery on every write. That's why I'm not sure considering latency as partition is in line with the CAP theorem. Maybe it is more related to availability though (not sure).
- AlisdairO 12y ago
  Caveat here is that you're duplicating data in a multi-master scenario. If you have a single write master and multiple read-only instances then consistency is easy to maintain (and suffering when you write from a distance) - obviously you're giving up strict read consistency, but that's enormously easier to model and understand. edit: I guess this is written from a very web-tech point of view, where the assumption is often made that reads will dominate writes. Obviously that's not always the case, and the tradeoffs get a lot more complicated!
mjb 12y ago
Daniel Abadi's PACELC addresses exactly this: http://cs-www.cs.yale.edu/homes/dna/papers/abadi-pacelc.pdf http://cs-www.cs.yale.edu/homes/dna/papers/abadi-pacelc.pdf By separating the behavior under failure (Consistency or Availability) and the behavior without failures (Consistency or Latency), PACELC clearly communicates that these are different tradeoffs.

michaelt 12y ago

If you duplicate your data in locations a few hundred milliseconds apart (e.g. America, Europe and Asia [1]) you either need to tolerate inconsistency or have every write take a few hundred milliseconds. If your system requires response times faster than that, the data centres you don't have time to contact behave sort of like they are partitioned all the time. Me, I tolerate writes that take a bit longer to keep things simple :) [1] http://www.nsmith.net/articles/2011-08/latency-between-amazon-web-services-regions/ http://www.nsmith.net/articles/2011-08/latency-between-amazo...

St-Clock 12y ago
"Me, I tolerate writes that take a bit longer to keep things simple :)" It's not just to keep things simple, it's to keep things consistent :-) Some NoSQL systems (e.g., MongoDB) introduced a new P in the equation (Performance) and used this to justify a lot of questionable decisions that affected consistency (and durability!). They have come a long way since these early decisions though. If a system considers moderate latency as a partition, it would need to perform partition recovery on every write. That's why I'm not sure considering latency as partition is in line with the CAP theorem. Maybe it is more related to availability though (not sure).
AlisdairO 12y ago
Caveat here is that you're duplicating data in a multi-master scenario. If you have a single write master and multiple read-only instances then consistency is easy to maintain (and suffering when you write from a distance) - obviously you're giving up strict read consistency, but that's enormously easier to model and understand. edit: I guess this is written from a very web-tech point of view, where the assumption is often made that reads will dominate writes. Obviously that's not always the case, and the tradeoffs get a lot more complicated!

mjb 12y ago

Daniel Abadi's PACELC addresses exactly this: http://cs-www.cs.yale.edu/homes/dna/papers/abadi-pacelc.pdf http://cs-www.cs.yale.edu/homes/dna/papers/abadi-pacelc.pdf By separating the behavior under failure (Consistency or Availability) and the behavior without failures (Consistency or Latency), PACELC clearly communicates that these are different tradeoffs.