
CASPaxos: Linearizable Databases Without Logs - GordonS
https://reubenbond.github.io/posts/caspaxos
======
hardwaresofton
Shameless plug for my writeup of all the different paxos varieties:

[https://vadosware.io/post/paxosmon-gotta-concensus-them-
all](https://vadosware.io/post/paxosmon-gotta-concensus-them-all)

(lots of links to papers inside)

It's a fascinating field and there are a _LOT_ of variations of Paxos worth
investigating.

I recently added a ToC so that it's a little easier to navigate/jump around

------
siliconc0w
Anyone have a link to the actual whitepaper? The one in the OP 404s.

Edit: it's
[https://arxiv.org/pdf/1802.07000.pdf](https://arxiv.org/pdf/1802.07000.pdf)

~~~
reubenbond
Fixed, thanks for pointing that out. I didn't realize this was posted here.

------
jamespitts
Relevant Tweet by Denis Rystsov, author of "CASPaxos: Replicated State
Machines without logs":
[https://twitter.com/rystsov/status/1118201415577419776](https://twitter.com/rystsov/status/1118201415577419776)

------
rdtsc
CASPaxos has nice latency and recovery times on node failures and partition
re-joins. The author of the algorithm has a comparison with other popular
consistent distributed databases
[https://github.com/rystsov/perseus](https://github.com/rystsov/perseus)

I particularly like novelty of using a function closures which makes it
elegant and approachable.

I also found the idea of the hierarchical ballots from the article pretty
interesting. ([config ballot, range ballot, file ballot, register ballot]).
And I suppose in the spirit of the original paper, it would be a nested set of
closures :-)

One thing that might not be obvious though, compared to other databases, is
that reads essentially follow the same path as the writes and cost about the
same, and even might result in spreading the update to other nodes that don't
have the latest value.

------
jupp0r
> It is a slight modification of the original Paxos algorithm, which is very
> simple and typically used as a minimal building block for more complicated
> algorithms such as Multi-Paxos

Wasn't Raft invented as a teaching tool because Paxos was too hard to
understand and implement correctly?

~~~
uluyol
Personally, and I have heard many other people say this as well, I don't think
Raft is any simpler than Paxos.

The problem with Paxos is that there is no one way to do things. There are a
thousand different variants and techniques that are not all compatible with
each other. So to actually implement Paxos essentially requires that you
become an expert. The advantage of Paxos is that there are many potential
optimizations at your fingertips, depending on your workload.

Unlike Paxos, Raft is much more _prescriptive_ : do x, y, and z, and
everything will be fine. And really, to a large extend, Raft can be viewed as
a description of what many production Paxos implementations would look like.

