cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Khangaonkar <khangaon...@gmail.com>
Subject Re: Leveled Compaction Strategy with a really intensive delete workload
Date Mon, 25 May 2015 02:12:35 GMT
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 <ostefano@gmail.com>
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
>



-- 
http://khangaonkar.blogspot.com/

Mime
View raw message