HyperDex provides scalable and high-performance transactions. While it is strongly (not eventually) consistent, the underlying technique we use to achieve atomicity of transactions is reminiscent of this approach.
On a related note, our experience is that a tightly implemented database can be much faster than a typical eventually consistent database. It would be great to see performance comparisons from TreodeDB.
That's cool. Indeed, it does look like one could use HypderDex's transactions and cond_put to make something close the batch write described in this post.
However, I don't see the part about Lamport clocks in HyperDex's API. Maybe one could implement that in a layer on top. The technique in the post allows a client to know if the values in its cache satisfy application invariants, even invariants that relate multiple rows. The Lamport clocks are key to making that part work.
I would very much like to provide performance numbers, and Jepsen results, and more for TreodeDB. Along that line though, I'm looking for contributors (or even a co-founder). I've gotten it this far on my own, but I really need help.
TreodeDB a bit like Spanner, in as much as both offer transactions across datacenters. The implementations are very different. The way Treode uses Lamport clocks lets you use a simple rule to determine if your local cache satisfies application invariants. I'm not sure if Spanner's use of atomic clocks gets you a similar capability.
6 comments
[ 2.7 ms ] story [ 22.6 ms ] threadCockroachDB and FoundationDB provide scalable and reliable transactions. But they don't offer this interface.
Couchbase has conditional writes, but not batch writes.
I think TreodeDB is the first to bring these things together this way.
On a related note, our experience is that a tightly implemented database can be much faster than a typical eventually consistent database. It would be great to see performance comparisons from TreodeDB.
However, I don't see the part about Lamport clocks in HyperDex's API. Maybe one could implement that in a layer on top. The technique in the post allows a client to know if the values in its cache satisfy application invariants, even invariants that relate multiple rows. The Lamport clocks are key to making that part work.
I would very much like to provide performance numbers, and Jepsen results, and more for TreodeDB. Along that line though, I'm looking for contributors (or even a co-founder). I've gotten it this far on my own, but I really need help.
http://static.googleusercontent.com/media/research.google.co...