4 comments

[ 2.9 ms ] story [ 18.2 ms ] thread
This is pretty awesome stuff. I’m honestly surprised it hasn’t been done before. It’s always interesting to see how the research world manifests itself in real world systems.
Sorry but... what is this?

I read (very quickly) the paper, then the article.

First of all, all the new names for things that are basically shards are not helping. Then all of this is very domain limited to logs, with only append and truncate.

Yes, you can build dbs on append-only, and well, good for logs, but the title read like more on the lines of playing against raft. The abstract pointed out it's a db.

Is this mainly about consensus? Probably not, I don't see any reference or benchmarks with raft in the middle. Barely any about Zookeper, which is not known to be really cutting edge. It's 10X the speed of... what they had before. which is? Besides, this is about a database build on rocksdb, did we manage to reduce comparison between databases to "10x than something else"?

So you have "conventional shared log api", and each shard can implement things in its own way. Good idea, but apparently the API is too conventional to discuss it, but novel enough to have a paper about it?

So I guess this is one of those frustrating things where you have to learn a whole distributed system to understand some new algorithm or abstraction.

I'm not saying this does not have merit, I'm sure it has, and I'll be happier when I understand it. I'm just pointing out that (at least to me) this is really frustrating to read.

It's a distributed database built on sharded append/truncate logs. They managed to abstract some operations to test new algorithms and implementations. The title makes it looks like all of this is about consensus, which (to me) it looks like only a small part. There is no benchmark except against older versions of itself, with only one "10x" measure. The database is not open source.

As it turns out, you can build most distributed protocols on top of an API which only allows you to append to and read from a shared log -- for example, if you want to do consensus across a number of actors, you can just have each one write their proposed value and the current epoch to the log, and the value that is written into the earliest log slot wins. In general, shared total orderings are equivalent to consensus -- this is clear when you consider that State Machine Replication (Paxos, Raft) is all about ensuring that all actors perform the same set of commands in the same order. If you're looking for a more detailed exposition of the shared log abstraction and its uses, you might benefit from reading the Corfu (https://www.cs.yale.edu/homes/mahesh/papers/corfumain-final....), Tango (http://www.cs.cornell.edu/~taozou/sosp13/tangososp.pdf), and FuzzyLog (https://www.usenix.org/system/files/osdi18-lockerman.pdf) papers from the lead author that precede this one.