cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11521) Implement streaming for bulk read requests
Date Fri, 08 Apr 2016 18:45:25 GMT


Sylvain Lebresne commented on CASSANDRA-11521:

The first thing that I think should be answered here is how do we "expose" this "externally".
My initial though was more or less what I think your proof of concept is doing, that is having
a different "paging mode" where the server sends pages "as fast as possible" rather than waiting
for the client to ask for them.

But I'm starting to wonder if that's the best approach. Because one of the question in that
case is "how to make sure we don't overwhelm the client?". And taking a step back, I strongly
suspect that by far the majority of the gain of "streaming" in the numbers on CASSANDRA-9259
is due to not having to re-start a new query server side for each page. Because other than
that, the difference between clients requesting pages as-fast-as-they-can versus server sending
them as-fast-as-they-can (without waiting on the client to ask) is really just the latency
of 2 client-server messages per page, which should be fairly small (and probably not even
noticeable if the server can send data faster than the client can process).

So an alternative could be to not change how current paging works in general, but simply allow
user to provide a "hint" when they know that they intend to consume the whole result set no
matter what (and do so rapidly).  That hint would be used by the driver and server to optimize
based on that assumption, which would mean for the driver to try to ask all pages to the same
replica and for the server to, at CL.ONE at least, maintain the ongoing query iterator in

My reasoning is that this would trade some hopefully negligable amount of latency between
pages for:
# a simple solution to the problem of rate limiting for clients sake (since client will still
control how fast things come).
# almost no change to the native protocol. We only need to pass the new "hint" flag, which
would really only mean "please optimize if you can". In particular, we could actually introduce
this _without_ a bump of the native protocol since we have flags available for query/execute
messages. Given that so far we have no plan on doing the protocol v5 before 4.0, this would
let us deliver this earlier which is nice.
# very little changes for the drivers: all they probably have to do is make sure they reuse
the same replica for all pages if the "hint" is set by users but that should be pretty trivial
to implement.
# it makes the question of what CL is supported moot: the "hint" flag will be just that, a
hint, so users will be able to use it whenever. It just happens that we'll only optimize CL.ONE
Overall, assuming the loss in latency (compared to having the server sends page as fast as
it can) is indeed very small (which we should certainly validate), this would appear to a
pretty good tradeoff to me.

But anyway, that's my initial brain dump on that first question of "how we expose this?".
There are other questions too that needs to be discussed (and the sooner the better). For
instance, how do we concretely handle the long running queries that this will allow? Holding
an OpOrder for too long feels problematic to name just one problem.

> Implement streaming for bulk read requests
> ------------------------------------------
>                 Key: CASSANDRA-11521
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Local Write-Read Paths
>            Reporter: Stefania
>            Assignee: Stefania
>             Fix For: 3.x
> Allow clients to stream data from a C* host, bypassing the coordination layer and eliminating
the need to query individual pages one by one.

This message was sent by Atlassian JIRA

View raw message