If the requests from the clients are not so frequent, there might be another option, to emulate multiget by running mapreduce with keylist input. This will make Riak run cover operation internally, so the throughput won't improve but latency would improve, because it runs inside the server in parallel. Hope this helps.
https://gist.github.com/kuenishi/7226938 Thanks, On Tue, Oct 29, 2013 at 10:49 PM, Sean Cribbs <s...@basho.com> wrote: > Vincent, > > We will consider this for a future release of Riak. In the meantime, have > you considered JRuby for your app? It has much better multi-threaded > behavior than MRI. > > > On Tue, Oct 29, 2013 at 5:24 AM, Vincent Chavelle > <vincent.chave...@gmail.com> wrote: >> >> Hi, >> >> I fell in love with riak and riak-cs, I have migrated all my stack on it >> (originally from mongodb). >> But I have one big issue. I have a lot of key to request simultaneously >> and thanks for multi_get implementation (ruby) it's already optimised for >> the client side (concurrent requests). But I would like to know if any >> server implementation to come because, in my case, it is very very slow to >> request 1000 objects (unlike mongodb). >> >> You will make me the happiest man in the world. And I could take off my >> hideous memory caching solution :-) >> >> Thanks >> >> Vincent Chavelle >> >> _______________________________________________ >> riak-users mailing list >> riak-users@lists.basho.com >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >> > > > > -- > Sean Cribbs <s...@basho.com> > Software Engineer > Basho Technologies, Inc. > http://basho.com/ > > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > -- Kota UENISHI / @kuenishi Basho Japan KK _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
