cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Wee <>
Subject Re: Leveled Compaction Strategy with a really intensive delete workload
Date Mon, 25 May 2015 08:52:36 GMT
...., due to a really intensive delete workloads, the SSTable is promoted
to t......

Is cassandra design for *delete* workloads? doubt so. Perhaps looking at
some other alternative like ttl?


On Mon, May 25, 2015 at 10:12 AM, Manoj Khangaonkar <>

> Hi,
> For a delete intensive workload ( translate to write intensive), is there
> any reason to use leveled compaction ? The recommendation seems to be that
> leveled compaction is suited for read intensive workloads.
> Depending on your use case, you might better of with data tiered or size
> tiered strategy.
> regards
> regards
> On Sun, May 24, 2015 at 10:50 AM, Stefano Ortolani <>
> wrote:
>> Hi all,
>> I have a question re leveled compaction strategy that has been bugging me
>> quite a lot lately. Based on what I understood, a compaction takes place
>> when the SSTable gets to a specific size (10 times the size of its previous
>> generation). My question is about an edge case where, due to a really
>> intensive delete workloads, the SSTable is promoted to the next level (say
>> L1) and its size, because of the many evicted tombstones, fall back to 1/10
>> of its size (hence to a size compatible to the previous generation, L0).
>> What happens in this case? If the next major compaction is set to happen
>> when the SSTable is promoted to L2, well, that might take too long and too
>> many tobmstones could then appear in the meanwhile (and queries might
>> subsequently fail). Wouldn't be more correct to flag the SStable's
>> generation to its previous value (namely, not changing it even if a major
>> compaction took place)?
>> Regards,
>> Stefano Ortolani
> --

View raw message