cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-8483) Support streaming results
Date Mon, 15 Dec 2014 15:26:13 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-8483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14246735#comment-14246735
] 

Benedict edited comment on CASSANDRA-8483 at 12/15/14 3:25 PM:
---------------------------------------------------------------

bq. or even if the effort is really worth the trouble

Well, streaming reads comes up regularly as a topic, and it makes a lot of sense for keeping
GC requirements constant regardless of workload. However if we decide we don't want to introduce
them in future this ticket is definitely superfluous. I think we would be mistaken not to
target a world where all workloads require a static amount of resources to service, to reduce
total heap requirements and just as importantly to avoid hunting through heap dumps just to
tell the user there are problems with their data model. But that's just me, and I'll let others
chime in if they think it's a terrible idea.


was (Author: benedict):
bq. or even if the effort is really worth the trouble

Well, streaming reads comes up regularly as a topic, and it makes a lot of sense for keeping
GC requirements constant regardless of workload. However if we decide we don't want to introduce
them in future this ticket is definitely superfluous. I think we would be mistaken not to
target a world where all workloads require a static amount of resources to service, to reduce
total heap requirements and just as importantly to avoid hunting through heap dumps just to
tell the user there are problems with their data model.

> Support streaming results
> -------------------------
>
>                 Key: CASSANDRA-8483
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8483
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Core
>            Reporter: Benedict
>             Fix For: 3.0
>
>
> Currently we stream the number of rows back to the client before serializing, which means
we need to know how many there are before doing so, which means materializing the entire resultset.
We currently get around this with paging which attempts to restrict the amount of materialization
done in any step, but supporting streaming entire result sets in one native transport "action"
without materializing them all upfront would remove the need for paging in many cases, and
would permit resultsets to be streamed _with isolation_, which most users probably don't realise
is broken by paging.
> We can't use this change yet, but the sooner support for this is introduced to the protocol,
the more likely it is clients will be able to make use of streaming reads once we're actually
able to deliver them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message