Riak Recap for 7/28 - 7/29

Mark Phillips mark at basho.com
Fri Jul 30 15:14:51 EDT 2010

Afternoon, Evening, Morning to all,

Here is a great recap to lead you into the weekend.



Community Manager
Basho Technologies


Riak Recap for 7/28 - 7/29

1) For anyone hacking Riak with Ruby, linked associations hit the
master branch of Ripple. Go check it out.

Link here ---> http://twitter.com/seancribbs/statuses/19831310112

2) @jebui shared some more info on how he is using Riak at ingist.

Info here ---> http://twitter.com/jebui/statuses/19805331075

3) Sean posted this to the list yesterday, but it's worth another
mention. The next free webinar Basho is doing will be on Riak and

Details and registration info here --->


4) We posted a very scientific video to the Basho Blog. It's called
"Consistent Smashing." If you've not seen it, check it out. We hope
you'll like it.


Also, it looks like Todd Hoff over at "High Scalability" liked it
enough to put it on their site --->


5) Q --- I have a question regarding locking/transactions. I know this
has been covered in the past, but just wondering if it would it be
possible to add a pre-commit hook that takes in the vclock from the
store request and compares it against the currently stored object at a
key. The vclock sent with the store request should be the same (by
convention I think?) and if the vclocks are different, a failure
message could be generated to the client letting the client know a
change has occured and to reload the object at the key. I think the
only problem is the pre-commit hooks do not have access to the objects
stored versus the ones coming in. (from bluehavana via #riak)

    A --- Excellent question. Here are some things to consider. First,
pre-commit hooks are executed after the submitted object is  merged
with the existing object. Second, attempting to use Riak with
locking/strict constistency in any sense is going make your problems
harder to reason about. Third, if you want the ability to prevent
blind overwrites, use allow_mult=true and then resolve the conflict in
your application.

6)  Q --- Could you use a redis server as the k/v store for riak? one
redis server per node? (from erlanginside via #riak)

     A --- @cstar released this a while back.
http://github.com/cstar/riak_redis_backend .   It's a bit out of date
but might be worth a look.

7)  Q --- Whats the fastest backend? (from erlanginside via #riak)

     A --- ets is the fastest, but obviously doesn't persist.  Bitcask
is the fastest on-disk backend.

More information about the riak-users mailing list