As far as latency is concerned, it seems like it wouldn't matter very much if the coordinator has to wait for all the responses to come back, or the client waits for all the responses to come back. I’ve got the same latency either way.
I would assume that 50 coordinations is more expensive than one coordination that does 50 times the work, but that’s probably insignificant when compared to the actual fetching of the data from the SSTables. I do see the point about putting stress on coordinator memory. In general, the documents will be very small, but there will occasionally be some rather large ones, potentially several megabytes in size. Definitely better to not make the coordinator hold on to that memory while it waits for other requests to come back. Robert On Oct 4, 2014, at 8:34 AM, DuyHai Doan <doanduy...@gmail.com<mailto:doanduy...@gmail.com>> wrote: Definitely 50 concurrent queries, possibly in async mode. If you're using the IN clause with 50 values, the coordinator will block, waiting for 50 partitions to be fetched from different nodes (worst case = 50 nodes) before responding to client. In addition to the very high latency, you'll put the stress on the coordinator memory. On Sat, Oct 4, 2014 at 3:09 PM, Robert Wille <rwi...@fold3.com<mailto:rwi...@fold3.com>> wrote: I have a table of small documents (less than 1K) that are often accessed together as a group. The group size is always less than 50. Which produces less load on the server, one query using an IN clause to get all 50 back together, or 50 concurrent queries? Which one is fastest? Thanks Robert
