
Consus: Fast Geo-Replicated Transactions - deepanchor
http://hack.systems/2016/12/13/hello-consus
======
deepanchor
For those that are not familiar with Hyperdex[1], it is an open-source,
performant, ACID compliant key-value store with commercial support[2] for
fully distributed transactions.

It seems that Robert Escriva (creator of Hyperdex) is now working on a new
database called Consus with the following key differences[3]:

“Consus has two (three) differences from HyperDex that I believe will make it
more appealing in the long run:

1\. Consus doesn't separate the implementations of transactions and the
regular code. Once we have a paper public on the topic and I have clearance to
release the code, all of the code will be available under the same license,
with no commercial fork.

2\. Consus provides wide-area, geo-replicated transactions with much lower
latency than is possible in any other system I know with the same consistency
that Consus provides.

3\. I’m still actively working on Consus; I'm not actively working on
HyperDex."

[1] [http://hyperdex.org/](http://hyperdex.org/) [2]
[http://hyperdex.org/warp/](http://hyperdex.org/warp/) [3]
[https://github.com/rescrv/HyperDex/issues/233](https://github.com/rescrv/HyperDex/issues/233)

*edit: should have linked to the project's homepage ([http://consus.io/](http://consus.io/)) which contains more details, if mods could change the link that would be great ;)

~~~
lobster_johnson
HyperDex is pretty interesting.

I evaluated it for a project last year, but decided not to use it. One reason
was that at the time, the project seemed to have been abandoned; the author
did not respond to issues or pull requests. Another was that based on Google
searches, there seemed to be no one else actually using it in production; so
even considering getting the commercial ACID support seemed like a big gamble,
never mind that I couldn't find any info on how it performed in large
clusters, and so on.

That said, it seemed technically brilliant, and fast.

If Escriva can accomplish the same thing with Consus, in a fully open source
way, and gain traction enough to keep the project alive, I could see this as
something I would consider using. That said, I'm wary of anyone who just
abandons projects like that, without telling anyone about it.

~~~
deepanchor
> If Escriva can accomplish the same thing with Consus, in a fully open source
> way, and gain traction enough to keep the project alive, I could see this as
> something I would consider using.

Totally agree. I feel like there's a big void in the open-source world for
this type of technology that has yet to be filled. There used to be
FoundationDB and, well, we all know what happened there. CockroachDB is
probably the only other active, open-source project right now that claims to
have strong ACID guarantees for multi-database transactions. However, the team
is not wholly focused on performance at this stage of development (which some
of their early benchmarks demonstrate).

If Consus can retain some of the performance characteristics of Hyperdex while
providing completely open source distributed transactions, it will be an
absolute game changer.

~~~
lobster_johnson
It's promising, at least. I think a system like this would be the most useful
if you're able to layer a query language on top of it, and apparently even
FoundationDB (which had an SQL layer on top of a K/V store) didn't perform all
that well. The Cockroach guys claim to have found a performant way of doing
SQL on top of K/V, if I remember correctly, but we'll see. But having
transactions in a distributed K/V store is certainly useful.

~~~
spullara
If you are willing to optimize for a KV store with distributed transactions
you can do a lot better than putting a SQL layer on top of it.

~~~
lobster_johnson
Not sure what you mean by that. Consus seems to be directly inspired by
Google's Spanner, which famously has an SQL layer, F1, on top.

~~~
spullara
It does, but unless you know it is on top of a distributed KV store and design
your schema and queries around that you will suffer horrible performance
issues. Also, F1, similar to FDBs implementation, forces you to model your
databases differently than you would in a "normal" oltp relational database.

~~~
rescrv
Almost every single host SQL solution I know of is built on a B-Tree for at
least some of its properties. A B-Tree is nothing more than a
lexicographically sorted key-value store.

Consus is a lexicographically sorted key-value store.

Where you will hit performance bottlenecks is when your query planner/executer
makes traditional assumptions about performance that do not hold across
machines.

A good SQL implementation on top of a kvs should not force you to accommodate
it any more than your current "normal" databases subconsciously train you to
accommodate your disks (hint: they do).

~~~
spullara
I would be very surprised if anyone is still running their primary data store
on "disks" that cares about performance. BTW, look at the design of F1 and you
will see that they do object like hierarchical storage of related tables to
ensure that they don't have to go cross partition for queries.

------
dantiberian
There's also a blog post announcement here:
[http://hack.systems/2016/12/13/hello-
consus/](http://hack.systems/2016/12/13/hello-consus/)

Reading through the post about active development on the predecessor HyperDex:
[https://github.com/rescrv/HyperDex/issues/233](https://github.com/rescrv/HyperDex/issues/233)

> I've stopped developing the project for non-public reasons that aren't
> technically related to the project.

Along with this line in the blog post:

> not one in which a company with profit motives releases a half-open product,
> but one in which those interested in Consus can come together to build
> something better.

It seems like there was some friction around the commercial nature of
Hyperdex.

~~~
sctb
Thanks, we've updated the link from the GitHub project:
[https://github.com/rescrv/Consus](https://github.com/rescrv/Consus).

------
espeed
Consus technical report...

Consus: Taming the Paxi
[https://arxiv.org/abs/1612.03457](https://arxiv.org/abs/1612.03457)

------
quinthar
Cool! Also, you might take a look at
[http://bedrockdb.com](http://bedrockdb.com) for a geo-replicated, ACID, SQL
database (basically a replication layer atop SQLite).

------
lobo_tuerto
Let's call Aphyr ;)

[https://aphyr.com/about](https://aphyr.com/about)

~~~
Royalaid
Jepsen or it isn't ACID?

~~~
rescrv
I'd ask you to please read the discussion section of the paper on Consus
before calling Aphyr.

------
buremba
so what happened to hyperdex? it looks like the project is no longer
maintained. could you please share why the project is dead?

------
webmaven
No README?

------
slantedview
All I see is consensus, misspelled. Too much time in the trenches.

~~~
shawn-butler
In Roman times, grain was essential to life and Consus served as the protector
of grain; through its similarity to the word consilium, Consus became
associated with secret conferences.

So there you go.

~~~
rescrv
"... In Modern times, Consus is very similar to the word consensus; not
coincidentally the former uses the latter to serve as the protector of data."

