Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 9 Mar 2015 12:38:38 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12765401.1420647550000.36844.1425904718931@Atlassian.JIRA>
In-Reply-To: <JIRA.12765401.1420647550000@Atlassian.JIRA>
References: <JIRA.12765401.1420647550000@Atlassian.JIRA>
 <JIRA.12765401.1420647550984@arcas>
Subject: [jira] [Commented] (CASSANDRA-8574) Gracefully degrade SELECT when
 there are lots of tombstones
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Sylvain Lebresne commented on CASSANDRA-8574:
---------------------------------------------

bq. If short reads is the underlying problem \[...\] indicate from StorageProxy back to the pager that this is a short read (opposed to end of results) and the pager should continue.

Short reads aren't the underlying problem, but for the record, we can't do what you suggest because short reads could make us return something we shouldn't (because it can be deleted but we need to wait on the non-short retry to get the tombstone). I'll note that this case is actually not properly handled by the current short read protection but I'll try to open a ticket about it later today.

> Gracefully degrade SELECT when there are lots of tombstones
> -----------------------------------------------------------
>
>                 Key: CASSANDRA-8574
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8574
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Jens Rantil
>             Fix For: 3.0
>
>
> *Background:* There's lots of tooling out there to do BigData analysis on Cassandra clusters. Examples are Spark and Hadoop, which is offered by DSE. The problem with both of these so far, is that a single partition key with too many tombstones can make the query job fail hard.
> The described scenario happens despite the user setting a rather small FetchSize. I assume this is a common scenario if you have larger rows.
> *Proposal:* To allow a CQL SELECT to gracefully degrade to only return a smaller batch of results if there are too many tombstones. The tombstones are ordered according to clustering key and one should be able to page through them. Potentially:
>     SELECT * FROM mytable LIMIT 1000 TOMBSTONES;
> would page through maximum 1000 tombstones, _or_ 1000 (CQL) rows.
> I understand that this obviously would degrade performance, but it would at least yield a result.
> *Additional comment:* I haven't dug into Cassandra code, but conceptually I guess this would be doable. Let me know what you think.


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