Afternoon, Evening, Morning to all, Here is a great recap to lead you into the weekend.
Enjoy! Mark Community Manager Basho Technologies wiki.basho.com twitter.com/pharkmillups ----- 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 Ruby. Details and registration info here ---> http://blog.basho.com/2010/07/29/free-webinar---riak-with-rails---august...@-2pm-eastern/ 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. http://blog.basho.com/2010/07/28/consistent-smashing/ Also, it looks like Todd Hoff over at "High Scalability" liked it enough to put it on their site ---> http://highscalability.com/blog/2010/7/30/basho-lives-up-to-their-name-with-consistent-smashing.html 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. _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
