Riak Adoption - What can we do better?

Elias Levy fearsome.lucidity at gmail.com
Fri Apr 20 15:44:52 EDT 2012

On Fri, Apr 20, 2012 at 12:09 PM, <riak-users-request at lists.basho.com>wrote:

> From: Paul Gross <pgross at gmail.com>
> 1. Add other data types like lists and sets. With lists, features like
> blocking pop would be great. MongoDB also has capped collections which
> keep a fixed number of documents.

+1.  I'd love to see something along the lines of Redis data types but with
the solid architecture of Riak.  And while I think Mongo's architecture is
terrible, we have a use case that fits perfectly capped collections.  Thus,
we use it for that purpose.

> 2. Improve secondary indexes. Add indexes to existing documents without
> writing them all one by one. Allow querying by multiple indexes. Maybe
> even allow secondary index lookups to return the documents, rather than
> requiring separate GETs for each key.

> 3. Add an easy way to delete a bucket.
> 4. Add the concept of ordering (without having to fall back to
> map/reduce). It's difficult to do paging without ordering, and most
> webapps require it. In general, paging in RIak is hard, since there's no
> concept of a range of results from a secondary index.

All +1.

I'd add to that, allow some mechanism generate streaming inputs to a MR job
and to short circuit them when the job is satisfied some way.

E.g. you want to search for some data, say the most recent X by time.  If
you got an indexed time field, either using search or secondary indexes,
right now you can only specify the whole time range in the input phase of
the job, but that is inefficient, since Riak will fetch all values in
parallel (there may be some optimization around key ordering, but you can't
always control the key).  So you may fetch thousands of values
to retrieve 10.  The alternative is to perform an iterative search until
you obtain the number of values you want.

It would be best if I could specify multiple input phases to a MR job that
would be processed in order, then have some way for a downstream phase to
indicate no more input is needed and terminate input processing.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20120420/2b9f46e8/attachment.html>

More information about the riak-users mailing list