State machine replication, and why you should care
signalsandthreads.com
State machine replication, and why you should care
1–10 of 21 posts
Re: State machine replication, and why you should care
#2No post body was provided.
Re: State machine replication, and why you should care
#3There's a whole database, Datomic, that works roughly this way -- not the UDP multicast but the idea of having a slightly more nuanced consistency/availability/partition tolerance tradeoff by having a thin transaction organizer which is not partition tolerant and officially states which one came first and second, upstream of the replicas that grant normal availability.
I would have liked the discussion about Raft/Paxos that they said they'd leave out of this episode though :(
Re: State machine replication, and why you should care
#4There's a whole database, Datomic, that works roughly this way -- not the UDP multicast but the idea of having a slightly more nuanced consistency/availability/partition tolerance tradeoff by having a thin transaction organizer which is not partition tolerant and officially states which one came first and second, upstream of the replicas that grant normal availability. I would have liked the discussion about Raft/Pax…
Sounds similar to xtdb
Re: State machine replication, and why you should care
#5There's a whole database, Datomic, that works roughly this way -- not the UDP multicast but the idea of having a slightly more nuanced consistency/availability/partition tolerance tradeoff by having a thin transaction organizer which is not partition tolerant and officially states which one came first and second, upstream of the replicas that grant normal availability. I would have liked the discussion about Raft/Pax…
CORFU and Tango are interesting research implementations in this general area, with emphasis on a dedicated "sequencer" - see https://rebeccabilbro.github.io/the-shared-log-abstraction/
Facebook's LogDevice had a similar sequencer component too https://engineering.fb.com/2017/08/31/core-data/logdevice-a-...
Re: State machine replication, and why you should care
#6There's a whole database, Datomic, that works roughly this way -- not the UDP multicast but the idea of having a slightly more nuanced consistency/availability/partition tolerance tradeoff by having a thin transaction organizer which is not partition tolerant and officially states which one came first and second, upstream of the replicas that grant normal availability. I would have liked the discussion about Raft/Pax…
Sounds similar to xtdb https://github.com/xtdb/xtdb
Yeah as I understand it XTDB was built by Juxt after using Datomic for a long while, to make a different set of trade-off choices.
Whenever one comes up, the other is likely to be mentioned close at hand:
Re: State machine replication, and why you should care
#7This was an interesting episode. However, I thought this pattern was called actors. Did anyone else get that sense? I have never heard that called a state machine.
Re: State machine replication, and why you should care
#8There's a whole database, Datomic, that works roughly this way -- not the UDP multicast but the idea of having a slightly more nuanced consistency/availability/partition tolerance tradeoff by having a thin transaction organizer which is not partition tolerant and officially states which one came first and second, upstream of the replicas that grant normal availability. I would have liked the discussion about Raft/Pax…
CORFU and Tango are interesting research implementations in this general area, with emphasis on a dedicated "sequencer" - see https://rebeccabilbro.github.io/the-shared-log-abstraction/ Facebook's LogDevice had a similar sequencer component too https://engineering.fb.com/2017/08/31/core-data/logdevice-a-...
Yeah, and the key idea here is that the sequencer is soft state that can be recovered from the log at any time. It acts to improve throughput while it's up, but if it's down the system can still make progress. The key to this is that the log is the ultimate ground source of truth, and individual entries in the log are write once. This means racing writers can detect and work around each other in the absence of a sequencer, via the hole filling protocol.
Re: State machine replication, and why you should care
#9There's a whole database, Datomic, that works roughly this way -- not the UDP multicast but the idea of having a slightly more nuanced consistency/availability/partition tolerance tradeoff by having a thin transaction organizer which is not partition tolerant and officially states which one came first and second, upstream of the replicas that grant normal availability. I would have liked the discussion about Raft/Pax…
What's the state of Datomic these days? I stopped keeping up with it a while back when I stopped really paying attention to the Clojure space in general. Last I remember hearing it was still a purely pay to use their instances sort of deal.
Re: State machine replication, and why you should care
#10There's a whole database, Datomic, that works roughly this way -- not the UDP multicast but the idea of having a slightly more nuanced consistency/availability/partition tolerance tradeoff by having a thin transaction organizer which is not partition tolerant and officially states which one came first and second, upstream of the replicas that grant normal availability. I would have liked the discussion about Raft/Pax…
CORFU and Tango are interesting research implementations in this general area, with emphasis on a dedicated "sequencer" - see https://rebeccabilbro.github.io/the-shared-log-abstraction/ Facebook's LogDevice had a similar sequencer component too https://engineering.fb.com/2017/08/31/core-data/logdevice-a-...
FaunaDB (fauna.com) is a commercial system based on Calvin.
Disclosure: I work on FaunaDB.