cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "mck (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8574) Gracefully degrade SELECT when there are lots of tombstones
Date Mon, 09 Mar 2015 13:16:39 GMT


mck commented on CASSANDRA-8574:

{quote}…because it can be deleted but we need to wait on the non-short retry to get the

If StorageProxy were to only return a page of results which are known to have a quorum reply
over (ie the smallest returned liveCount), then therefore shouldn't corresponding tombstones
be always /there/ (known to be applied) within that current page? 

Aside from the poor protection which i presume is not knowing exactly which cells we have
a quorum reply over and/or not knowing if every reply just had a short read from different
tombstones (this is actually quite serious as it's a way to break consistency/reads). Otherwise
i'm hoping you already have the right fix in mind and will describe it in the new issue…

> Gracefully degrade SELECT when there are lots of tombstones
> -----------------------------------------------------------
>                 Key: CASSANDRA-8574
>                 URL:
>             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

View raw message