Live data from Hacker News

Scalable but Wasteful, or why fast replication protocols are slow

charap.co

1–10 of 26 posts

Re: Scalable but Wasteful, or why fast replication protocols are slow

#4

So, why?

A leaderless protocol is more complex and requires greater IO and CPU resources per unit of work. This is the hidden cost. The question is if the cost is reasonably offset by higher performance (throughput) offered by leaderless consensus. OP is arguing that the benefit is not deemed worth the cost outside of academia and this is why e.g EPaxos is not adopted.

Re: Scalable but Wasteful, or why fast replication protocols are slow

#5
Another thing which makes the Raft/Paxos vs new-consensus-algorithm comparisons complicated is caching.

If your raft state machines are doing IO via some write through cache (which they often are) then having specific machines do specific jobs can increase the cache quality. I.e. your leader node can have a better cache for your write workload, whilst your follower nodes can have better caches for your read workload.

This may lead to higher throughput (yay) but then also leave you vulnerable to significant slow-downs after leader elections (boo).

What makes sense will depend on your use case, but I personally agree with the author that multiple simple raft/paxos groups scheduled across nodes by some workload aware component might be the best of both worlds.

Re: Scalable but Wasteful, or why fast replication protocols are slow

#6

So, why?

A leaderless protocol is more complex and requires greater IO and CPU resources per unit of work. This is the hidden cost. The question is if the cost is reasonably offset by higher performance (throughput) offered by leaderless consensus. OP is arguing that the benefit is not deemed worth the cost outside of academia and this is why e.g EPaxos is not adopted.

But doesn't a leaderless protocol also give you more resilience against failures? Or, in other words, can it be that the higher cost buys you not better throughput but faster reconciliation when connectivity is poor? Not in a data center but on a mobile network?

Re: Scalable but Wasteful, or why fast replication protocols are slow

#7
> The protocol presents a leader-less solution, where any node can become an opportunistic coordinator for an operation.

Does leader = master here? My first reaction is that this is a multi-master system but I can't quite unpack "opportunistic coordinator".

Re: Scalable but Wasteful, or why fast replication protocols are slow

#8
The hypothesis in the article could be correct (that industry is not adopting new academic innovations because they fail in the real world). Based on my experience in this industry, though, it could just be that there isn't a super strong connection between academia and the people implementing these kinds of systems. I've had many conversations with my academically-minded friends where they're astonished that we haven't jumped on some latest innovation, and I have to let them down by saying that the problem that paper was addressing is super far down our list of fires to put out. Maybe there are places where teams of top-tier engineers are free to spend 6 months every year rewriting critical core systems use un-battle-scarred new algorithms that might have 20% performance improvements, but most places I've worked would achieve the same result for far less money by spending 20% more on hardware.

Re: Scalable but Wasteful, or why fast replication protocols are slow

#9
post #8

The hypothesis in the article could be correct (that industry is not adopting new academic innovations because they fail in the real world). Based on my experience in this industry, though, it could just be that there isn't a super strong connection between academia and the people implementing these kinds of systems. I've had many conversations with my academically-minded friends where they're astonished that we have…

Yes for that kind of improvement I think academia would be better served trying to see if the techniques can be incorporated into an existing well tested implementation.

Re: Scalable but Wasteful, or why fast replication protocols are slow

#10
None of this actually matters. Consensus algorithms allow you to achieve consensus. Period. There's no requirement whatsoever on what you're getting consensus on. A consensus value could be _one_ database update, but it doesn't need to be. It can also consist of 666 database transactions across 42 different namespaces.
Post reply on HN