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 <ostef...@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/
