Re:Partitioned consensus and its impact on Spanner’s latency
by deepsun on Saturday December 15, 2018 @03:34PM
(#18690207)
My take away is that it depends on your requirements. If most of your transactions are multi-entity, then Calvin-like is better. If most of your transactions are single-entity, then Spanner-like is better.
I implemented projects in GAE Datastore, though it's classic Paxos inside, it's clearly multi-partition database. For my workflow almost all of the frequqnt transactions were single-entity, so multi-partition Datastore worked fine with it.
Re:Partitioned consensus and its impact on Spanner’s latency
by matthelb on Saturday December 15, 2018 @06:02PM
(#18690832)
I think that's a fair takeaway specifically because you are careful to limit the scope of your comparison to Calvin and Spanner. If you were to replace "Spanner-like" with "partitioned", I'd push back that it's not as clear Calvin is better than non-Spanner partitioned systems, even when you have mostly multi-entity transactions.
EDIT: To be clear, when I say better I mean higher throughput and lower latency.
In the context of this blog post, he specifically calls out partitioned consensus databases for requiring two wide-area round trips in order to run 2PC. However, we've seen multiple examples of partitioned databases (i.e. MDCC, TAPIR, Janus, and others) since the Spanner paper that can commit multi-partition transactions in a single wide-area round trip . Just as in the "unified consensus" approach, failures or concurrency may cause these systems to infrequently take multiple wide-area round trips to commit.
The blog post does a great job explaining the differences between "Calvin-like" systems and "Spanner-like" systems, but it falls short in convincing me that the "Calvin-like" architecture is fundamentally better, or makes better tradeoffs, than any partitioned architecture.