3 ms·
I appreciate the distinction that Daniel is trying to make between what he calls "partitioned consensus" databases and "unified consensus" databases, but I don'
by matthelb 8y ago
I appreciate the distinction that Daniel is trying to make between what he calls "partitioned consensus" databases and "unified consensus" databases, but I don't know if the points that he makes about partitioned consensus truly generalize to all such systems.
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.
- deepsun 8y agoMy 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.
- matthelb 8y agoI 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.