cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shu Zhang <szh...@mediosystems.com>
Subject RE: please help with multiget
Date Tue, 18 Jan 2011 18:57:44 GMT
Well, maybe making a batch-get is not  anymore efficient on the server side but without it,
you can get bottlenecked on client-server connections and client resources. If the number
of requests you want to batch is on the order of connections in your pool, then yes, making
gets in parallel is as good or maybe better. But what if you want to batch thousands of requests?

The server I can scale out, I would want to get my requests there without needing to wait
for connections on my client to free up.

I just don't really understand the reasoning for designing muliget_slice the way it is. I
still think if you're gonna have a batch-get request (multiget_slice), you should be able
to add to the batch a reasonable number of ANY corresponding non-batch get requests. And you
can't do that... Plus, it's not symmetrical to the batch-mutate. Is there a good reason for
that?
________________________________________
From: Brandon Williams [driftx@gmail.com]
Sent: Monday, January 17, 2011 5:09 PM
To: user@cassandra.apache.org
Cc: hector-users@googlegroups.com
Subject: Re: please help with multiget

On Mon, Jan 17, 2011 at 6:53 PM, Shu Zhang <szhang@mediosystems.com<mailto:szhang@mediosystems.com>>
wrote:
Here's the method declaration for quick reference:
map<string,list<ColumnOrSuperColumn>> multiget_slice(string keyspace, list<string>
keys, ColumnParent column_parent, SlicePredicate predicate, ConsistencyLevel consistency_level)

It looks like you must have the same SlicePredicate for every key in your batch retrieval,
so what are you suppose to do when you need to retrieve different columns for different keys?

Issue multiple gets in parallel yourself.  Keep in mind that multiget is not an optimization,
in fact, it can work against you when one key exceeds the rpc timeout, because you get nothing
back.

-Brandon

Mime
View raw message