Home/ Questions/Q 8722097
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T07:20:01+00:00

I’m working on a project where I use Riak with Ripple, and I’ve stumbled

  • 0

I’m working on a project where I use Riak with Ripple, and I’ve stumbled on a problem.
For some reason I get duplicates when link-walking a structure of links. When I link walk using curl I don’t get the duplicates as far as I can see.

The difference between my curl based link-walk

curl -v http://127.0.0.1:8098/riak/users/2306403e5177b4716da9df93b67300824aa2fd0e/_,projects,0/_,tasks,1

and my ruby ripple/riak-client based link walk

      result =   Riak::MapReduce.new(self.robject.bucket.client).
            add(self.robject.bucket,self.key).
            link(Riak::WalkSpec.new({:key => 'projects'})).
            link(Riak::WalkSpec.new({:key => 'tasks', :bucket=>'tasks'})).
            map("function(v){ if(!JSON.parse(v.values[0].data).completed) {return [v];} else { return [];} }", {:keep => true}).run

is as far as I can tell the map at the end.

However the result of the map/reduce contains several duplicates. I can’t wrap my head around why. Now I’ve settled for removing the duplicates based on the key, but I wish that the riak result wouldn’t contain duplicates, since it seems like waste to remove duplicates at the end.

I’ve tried the following:

  • Making sure there are no duplicates in the links sets of my ripple objects
  • Loading the data without the map reduce, but the link walk contains duplicate keys.

Any help is appreciated.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    What you’re running into here is an interesting side-effect/challenge of Map/Reduce queries.

    M/R queries don’t have any notion of read quorum values, and they necessarily have to hit every object (within the limitations of input filtering, of course) on every node.
    Which means, when N > 1, the queries have to hit every copy of every object.

    For example, let’s say N=3, as per default. That means, for each written object, there are 3 copies, one each on 3 different nodes.
    When you issue a read for an object (let’s say with the default quorum value of R=2), the coordinating node (which received the read request from your client) contacts all 3 nodes (and potentially receives 3 different values, 3 different copies of the object).
    It then checks to make sure that at least 2 of those copies have the same values (to satisfy the R=2 requirement), returns that agreed-upon value to the requesting client, and discards the other copies.
    So, in regular operations (reads/writes, but also link walking), the coordinating node filters out the duplicates for you.

    Map/Reduce queries don’t have that luxury. They don’t really have quorum values associated with them — they are made to iterate over every (relevant) key and object on all the nodes. And because the M/R code runs on each individual node (close to the data) instead of just on the coordinating node, they can’t really filter out any duplicates intrinsically. One of the things they’re designed for, for example, is to update (or delete) all of the copies of the objects on all the nodes. So, each Map phase (in your case above) runs on every node, returns the matched ‘completed’ values for each copy, and ships the results back to the coordinating node to return to the client. And since it’s very likely that your N>1, there’s going to be duplicates in the result set.

    Now, you can probably filter out duplicates explicitly, by writing code in the Reduce phase, to check if there’s already a key present and reject duplicates if it is, etc.
    But honestly, if I was in your situation, I would just filter out the duplicates in ruby on the client side, rather than mess with the reduce code.

    Anyways, I hope that sheds some light on this mystery.

    • 0