I'd like to move forward on this idea, and want to get more advises about
it.
Currently, I already have a hacked version of the batched read requests,
which implements a MultiReadCommand, and the coordinator nodes will group
the read commands to the same first endpoint together and construct a
new
I create a new jira to track this: CASSANDRA-12814, which is linked to
CASSANDRA-10414.
@Nate, agree. And it would be great if we can batch the reads from
different partitions but still on the same physical host as well, which
will be valuable for our existing and potential use cases.
Thanks
Dika
I see a few slightly different things here (equally valuable) in
conjunction with CASSANDRA-10414:
- Wanting a small number of specific, non-sequential rows out of the
same partition (this is common, IME) and grouping those
- Extending batch semantics to reads with the same understanding with
mutat
There's a similar ticket focusing on range reads and secondary index
queries, but the work for these could be done together:
https://issues.apache.org/jira/browse/CASSANDRA-10414
On Tue, Oct 18, 2016 at 5:59 PM, Dikang Gu wrote:
> Hi there,
>
> We have couple use cases that are doing fanout read
We've had some luck with bulk known key reads with grouping by replica and
doing SELECT... WHERE key IN(...). Not compatible with all data models, but
it works well where we can get away with it.
As a more general purpose construct it makes sense to me. In our driver
layer we have abstracted batch
Hi there,
We have couple use cases that are doing fanout read for their data, means
one single read request from client contains multiple keys which live on
different physical hosts. (I know it's not recommended way to access C*).
Right now, on the coordinator, it will issue separate read command
