Should Riak have used dedicated nodes for secondary indices?

Runar Jordahl runar.jordahl at gmail.com
Wed Jan 25 08:15:49 EST 2012


Siddharth Anand, says that secondary indices (for a key-value store)
best is placed on a separate node, avoiding the need to look up 1 / N
nodes during a query:

"Systems that shard data based on a primary key will do well when
routed by that key. When routed by a secondary key, the system will
need to “spray” a query across all shards. If one of the shards is
experiencing high latency, the system will return either no results or
incomplete (i.e. inconsistent) results. For this reason, it would make
sense to store the secondary index on an unsharded (but replicated)
system."

http://highscalability.com/blog/2012/1/24/the-state-of-nosql-in-2012.html

If I understand Riak correctly, it takes the opposite approach,
storing secondary indices together with the data.

To me at appears like Riak’s approach gives a more uniform system,
with all nodes having the same responsibilities. Does anyone else have
any thoughts on this?

Kind regards
Runar Jordahl
blog.epigent.com



More information about the riak-users mailing list