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 [dri...@gmail.com] Sent: Monday, January 17, 2011 5:09 PM To: user@cassandra.apache.org Cc: hector-us...@googlegroups.com Subject: Re: please help with multiget On Mon, Jan 17, 2011 at 6:53 PM, Shu Zhang <szh...@mediosystems.com<mailto:szh...@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
