Kev Burns kevburnsjr at gmail.com
Tue Jul 26 23:11:55 EDT 2011

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

Take PodCrazy

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

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

- Kev
c: +001 (650) 521-7791
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20110726/180561f6/attachment.html>

More information about the riak-users mailing list