Well that figures. In micro benchmarks (always unreliable), the two are
not even close . The 20 separate gets blow the map reduce multiget out of
the water. With info likely in os disk cache, we see:
20 gets including forking/joining: ~25ms total
single map reduce multiget using erlang: ~250ms
I guess there must be a lot of overhead using the map reduce framework.
This is for my local single node testing cluster. I'll have to retest in a
multinode cluster...
Is this in alignment with what others are seeing?
Thanks,
Jacques
On Thu, Jun 16, 2011 at 9:52 AM, Jacques <whs...@gmail.com> wrote:
> Thanks for the info. As a note, I found that the javascript function was
> having trouble return binary values.
>
> I followed your suggestion and am now using the following function. (Here
> for others.)
>
> -module(multiget).
> -export([key_value/3]).
>
> key_value({error, notfound}, _KD, _) ->
> none;
> key_value(RiakObject, _KD, _) ->
> [riak_object:bucket(RiakObject),riak_object:key(RiakObject),
> riak_object:get_value(RiakObject)].
>
>
> Thanks again for your help. I haven't done performance tests yet but am
> hoping that this is more performant than 20 individual gets.
>
> I must say that I'm still quite surprised that a key value store of Riak's
> caliber doesn't have a native binary multiget within the core pbc api.
>
> Jacques
>
> On Thu, Jun 16, 2011 at 5:03 AM, Russell Brown <russell.br...@me.com>wrote:
>
>> Hi Jaques,
>> Sorry for the slow reply. I think this one just slipped by me.
>>
>> Ok. answers inline below:
>>
>> On 14 Jun 2011, at 18:26, Jacques wrote:
>>
>> Does anybody have any insight on my questions below?
>>
>> Thanks,
>> Jacques
>>
>>
>> On Tue, Jun 7, 2011 at 6:12 PM, Jacques <whs...@gmail.com> wrote:
>>
>>> I've been working on this. I have it working with an anonymous
>>> javascript function. I was hoping to move it to using the
>>> "map_object_value" built-in erlang function. However, when I attempt to use
>>> this function, I get failures if any of my keys don't exist. Is there a way
>>> to construct my map phase so that it gracefully handles not founds and just
>>> returns what it finds?
>>
>>
>> Yes. riak_kv_mapreduce:map_object_value accepts an arg value of
>> either "filter_notfound", "include_notfound" or "include_keydata", so your
>> not found values can be omitted by passing "filter_notfound" as the arg
>> value for the map phase (instead of ATOM_NONE in your construction.)
>>
>>
>>> Also, using this function, is there a way to return the bucket and key
>>> names?
>>>
>>
>> No not using riak_kv_mapreduce:map_object_value, you could use
>> riak_kv_mapreduce:map_identity to get the whole riak object (meta data, key
>> and value) or just write your own map reduce function that returns the data
>> you want (and can filter out the not founds just like map_object_value)
>>
>> Or can one assume the response order is identical to the order of inputs?
>>>
>>
>> No.
>>
>> deletia
>>
>>
>> Cheers
>>
>> Russell
>>
>>
>
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
