3 ms·
Yeah, this paper gets dredged up every now and then. Seems a bit like a cheap trick to say “just say no to Paxos overhead” and then sequence network requests. I
by klodolph 6y ago
Yeah, this paper gets dredged up every now and then. Seems a bit like a cheap trick to say “just say no to Paxos overhead” and then sequence network requests. I’m all for exploring alternatives to Paxos, but if you’re doing something so novel, my response is that I’ll believe it when I see it operate at scale.
I’m just not sure how you would sequence requests in a typical setup, with Clos fabrics everywhere, possibly when your redundancy group is spread across different geographical locations. Wouldn’t you need some kind of queue to reorder messages? That queue could get large, and quickly.
Paxos and Raft have the advantage of being simple and easy to understand. (Not necessarily easy to incorporate into system designs, sure, and the resulting systems can be fairly complicated, but Paxos and Raft themselves are simple enough to fit on notecards.)
- gfv 6y ago>in a typical setup, with Clos fabrics everywhere You choose a single spine switch to carry the multicast messages destined to the process group. The paper also explicitly notes that different process groups need not to share the sequencer. >when your redundancy group is spread across different geographical locations The paper applicability is limited to data center networks with programmable network switching hardware.
- throwawaaarrgh 6y agoFrom what I understand, the concept is as simple as "No packets out of order cross the border", and "Retransmit if your packets ain't legit". Will there be lag? Sure. But will it be faster 98% of the time than Paxos? Probably. (But I also could be reading it wrong) > when your redundancy group is spread across different geographical locations I think 99% of the time this is just a bad idea, unless the thing you're accessing is already strongly consistent somehow. If a service has to be accessible across regions, there's potentially a million reasons for the service to be loosely coupled across those regions besides the availability issues.
- hinkley 6y agoI don't get to apply this enough, but I'm a big fan of distributed read, centralized write solutions. So many problems we have are read-mostly, but we mask them by doing a bunch of feature factory work that turns what should be a cheap, rather simple solution into something that takes a huge amount of resources to implement. Having read replicas in several locations makes it easier to stand up a new master if your main data center catches fire (OVH)