incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filipe Gonçalves <the.wa.syndr...@gmail.com>
Subject Re: Multiget question
Date Fri, 04 Nov 2011 15:07:40 GMT
Thanks for the answer.
I hadn't realised requests were made in parallel, I first noticed it
when multiget's took linear time in machines with high loads. Looking
at the code led me to the previous conclusion (N gets for multiget for
N keys). I agree it would take a major overhaul of the code to change
the current behaviour, possiby more than it's worth for the potencial
gains.


2011/11/4 Sylvain Lebresne <sylvain@datastax.com>:
> 2011/11/4 Filipe Gonçalves <the.wa.syndrome@gmail.com>:
>> Multiget slice queries seem to fetch rows sequentially, at least
>> fromwhat I understood of the sources. This means the node that
>> receives amultiget of N keys does N get operations to the other nodes
>> in thecluster to fetch the remaining keys.
>> Am I right? Is this the way multiget works internally?
>
> The 'sequentially' is probably not right depending on what you meant
> by that (see below) but otherwise yes, a multiget of N keys is internally
> splitted into N gets.
>
>> Also, shouldn't this be done in parallel, to avoid contacting
>> nodesmore than once?
>
> It's done in parallel, in that the coordinating nodes send all the get
> requests in parallel. It doesn't wait for the result to the first get to
> issue the second one. But it does do every get separately, i.e. it may
> contact the same note multiple times.
>
> In theory we could do with at most one message to each node for each
> multiget. We don't do it because it would actually require quite a bit of
> change in the current code and it's unclear it would really buy us much.
> Since we already parallelize requests, we would mostly win a bit on network
> traffic (by merging messages) but there is good chance this is unsignificant
> (of course I could be wrong given we haven't tried).
>
> --
> Sylvain
>
>> --
>> Filipe Gonçalves
>>
>



-- 
Filipe Gonçalves

Mime
View raw message