Is Riak suitable for s small-record write-intensive billion-records application?

Alexander Sicular siculars at
Thu Oct 18 09:53:18 EDT 2012

I've read the other replies and I'm gonna be the downer at this party. Imho, Riak is not well suited to small value applications due to on disk overhead. Last time this came up on the list, I recall there being a ~450 byte overhead per key. If that still holds, and I believe it does, you need to factor it into your disk space calculations.

Otherwise, your criteria are well within the capabilities of Riak. Use the leveldb backend and in your client code run a get before a put and you'll be fine. Of course, if you're writing a single key in rapid succession you need to consider the eventual consistency nature of Riak and factor that into your design. 

Keep us posted,


Sent from my iRotaryPhone

On Oct 18, 2012, at 7:42, Yassen Damyanov <yassen.tis at> wrote:

> Hi everyone,
> Absolutely new (and ignorant) to NoSQL solutions and to Riak (my
> apologies; but extensive experience with SQL RDBMS).
> We consider a NoSQL DB deployment for a mission-critical application
> where we need to store several hundreds of MILLIONS of data records,
> each record consisting of about 6 string fields, record total length
> is 160 bytes. There is a unique key in each record that seems suitable
> for hashing (20+ bytes string, e.g. "cle01_tpls01_2105328884").
> The application should be able to write several hundreds of new
> records per second, but first check if the unique key already exists.
> Writing is to be done only if it is not there. If it is, the app needs
> to retrieve the whole record and return it to the client and no
> writing is done in this case.
> I need to know if Riak would be suitable for such application. Please,
> advice, thanks!
> (Again, apologies for my ignorance. If we choose Riak, I promise to
> get educated ;)
> Yassen
> _______________________________________________
> riak-users mailing list
> riak-users at

More information about the riak-users mailing list