[jph]

The key insight: "... existing transactional storage systems waste work and performance by incorporating a distributed transaction protocol and a replication protocol that both enforce strong consistency. Instead, we show that it is possible to provide distributed transactions with better performance and the same transaction and consistency model using replication with no consistency."

The full paper is here: http://delivery.acm.org/10.1145/2820000/2815404/p263-zhang.p...

[kluck]

Interesting. Can you elaborate on this? I am not sure what "inconsistent replication" means.

[dsp1234]

An analogy that immediately comes to mind is the difference between running a vpn in 'tcp over tcp' mode vs 'tcp over udp' mode.

tcp itself is a reliable transport over unreliable media. So running tcp on top of tcp means running two sets of algorithms for reliability, ultimately doing more work than is needed. Running tcp over udp (where udp is unreliable) means you still get the reliability over the tcp overlay, but don't need to be worried about the udp layer since it can fail and the tcp overlay algorithms will fix up the data stream.

[ComNik]

It means that operations don't get executed in the same order on every replica. If the systems state depends on the ordering of operations, then each replica might be in a different state for the same set of operations.

"Consistent replication" would be using a protocol like Paxos to have the replicas decide on a single order of operations.

[amelius]

> If the systems state depends on the ordering of operations, then each replica might be in a different state for the same set of operations.

Which is almost always the case. Except of course, if you build your data as a growing "collection of knowledge", where the order of facts doesn't matter. But this is cheating, since you're implicitly bolting an ordering-mechanism on top of the system in this case.

[TallGuyShort]

Huh... isn't that required for being "transactional"? I should probably read the paper...

[iyzhang]

No, that was our key insight. Basically, you can think of it as, using something like Paxos requires all replicas to run the same code. So every replica checks for transaction conflicts. However, you actually only need one replica to detect a conflict, so there is no reason for every replica to run the same checks -- this is wasted work. Instead, we just make sure that each conflict is checked by at least one replica.

The other interesting conclusion is that there are other workloads like this. For example, it is possible to build a reliable and better performing lock server in this way as well (and there is an implementation in the github repo). So, you'd get something similar to Chubby, but where the latency to the server is only a single round-trip in the common case.

[pjc50]

"An error occurred while processing your request"