Francisco - How's performance on riak-ql? The problem I see with riak-ql and Antonio's thing is that they're invariably going to be slow. Javascript Map/Reduce over an entire bucket is just not suitable for inline requests.
Take PodCrazy http://podcrazy.net/ It's backed entirely by RiakSearch and memcached. That episode listing on the homepage is a map/reduce that calculates popularity based on votes over time. But right now this simple javascript map/reduce over less than a thousand items takes about 2 seconds to run. It totally makes sense as a map/reduce because it's calculating popularity based on several decaying attributes. But it has to happen in a background process. The site is powered by this port of Ripple to PHP http://ripple-php.hackyhack.net/test/?test=document Right now ripple-php has remained pretty basic and for good reason. I've put off creating something more full-featured until secondary indexes makes it into master. The shape of the native secondary index mechanism will heavily influence the design of any Riak ODM. Lastly, in my experience Riak Search is not very memory efficient as a non-fulltext index mechanism. Also sort of useless without support for ranges on anything other than keys. You wind up selecting limit 0,999 and doing the slice yourself. I suppose I see the value of a tool like riak-ql for reporting. And I imagine this sort of tool will continue to be useful to add the sort of features that Secondary Indexes will not support. And I also imagine a tool like this would be faster if implemented in Erlang. - Kev c: +001 (650) 521-7791
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
