Basho Blog: Secondary Indexes In Riak

blog.basho.com

54 points·RKlophaus··5 comments

Why return the primary key when performing a secondary index query instead of the whole record? This seems like it would add an extra round-trip. Would it be possible add a flag to return the whole record?

Excellent suggestion, and something we're already considering for a future release.

Our current reasoning is that if you are only pulling back one or two objects, then an extra round trip probably isn't that bad. If you're pulling back many objects for processing, then you might be better off feeding the query results into a MapReduce job so that it runs in parallel across the cluster.

You can use the index as input into a map reduce query which will bulk load the documents across the cluster.

You can then filter, transform, sort, limit, etc the documents from within the map reduce query.

What I'd like to see is the ability to use the index as the input and then use key filters to enable the ability to pre-filter the map-reduce query using meaningful keys. This maybe possible now, I haven't tried it.

Seems similar in thought to DNS's additional section, where a DNS server can say `hey, here is your answer, and oh by the way, you might want this other information too'. Example use case: if you get a CNAME back, then you will probably want the associated A record as well.

Given the current way [Riak] index queries are expressed, I was reminded of the unfortunately named HTSQL; I'm not sure if I am fond of it or not yet, but I thought I'd pass along a few references as it bears some at least superficial similarity to what exists in Riak at the moment, and that may be of use:

http://en.wikipedia.org/wiki/HTSQL

http://htsql.org/doc/ref/index.html

Reply on news.ycombinator.com