18 comments

[ 5.6 ms ] story [ 52.4 ms ] thread
Riak & CAP Thereom

Riak's guiding design principle is Dr. Eric Brewer's CAP Theorem. The CAP theorem defines distributed systems in terms of three desired properties: Consistency, Availability, and Partition (failure) tolerance. The theorem states you can only rely on having two of the three properties at any time.

Riak chooses to focus on the A and P of CAP. The choice puts Riak in the eventually consistent camp. However, the window for "eventually consistent" is in terms of milliseconds which can be good enough for many applications.

It's also in the Dynamo family together with Voldemort and Cassandra, but notably it has Map-Reduce (with link following) that these other two don't have.
So I'd be interesting to hear if anyone is running this in a prod env? I'm currently evaluating NoSQL at the moment (mongo, cassandra, raven etc etc) so would be interested to hear peoples real world experiences with it?
We have quite a few customers in production. Most well-known one is Mochi Media, who have multiple clusters backing their online games APIs.
I like riak, and I think it's the best implement of dynamo.
Wow they developed new backend. They really generate lots of interesting code..
The new backend is called "bitcask". Here is an introduction to it: http://downloads.basho.com/papers/bitcask-intro.pdf

This will be fast indeed. They mention 5000-6000 writes per second which seems very low to me however. Then again, they do not mention the size of the values written.

I too became enamored with log-based storage engines in December of last year. I created one myself to play around and learn. I moved on before adding in compaction, but the performance was "excellent" (200K writes per second, 5K random reads per second). Granted, the data model is literally just key-value however.

http://github.com/fictorial/logstore

http://github.com/fictorial/logstore/commit/9ffa46a249a62a78...

Read a paper by Ousterhout about log-based storage here:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.117....

Maybe of interest is a somewhat wacky project in which data is stored in sparse files. The big limitations here are that your system needs support for sparse files, you use a number of pre-created sparse files, and each item's maximum size is fixed. Pretty big limitations! Then again, for trivial purposes, it is ridiculously fast since an item's file and location is trivially computed and I/O uses mmap.

http://github.com/fictorial/sparsestore

Sorry, I got excited that there was someone else who was interested in wacky data storage engines!