On Thu, Jun 13, 2019 at 2:44 PM Oleksandr Shulgin < oleksandr.shul...@zalando.de> wrote:
> On Thu, Jun 13, 2019 at 2:07 PM Léo FERLIN SUTTON > <lfer...@mailjet.com.invalid> wrote: > >> >> Overall we are talking about a 1.08TB table, using LCS. >> >> SSTable count: 1047 >>> SSTables in each level: [15/4, 10, 103/100, 918, 0, 0, 0, 0, 0] >> >> SSTable Compression Ratio: 0.5192269874287099 >> >> Number of partitions (estimate): 7282253587 >> >> >> We have recently (about a month ago) deleted about 25% of the data in >> that table. >> >> Letting Cassandra reclaim the disk space on it's own (via regular >> compactions) was too slow for us, so we wanted to force a compaction on the >> table to reclaim the disk space faster. >> > > To be clear, that compaction task is running the major compaction for this > column family? I have no experience with Leveled compaction strategy, so > not really sure what behavior to expect from it. I can imagine that with > that many SSTables and a major compaction, there might be quite some > overhead as it does more than an ordinary merge-sort as I would expect from > Size-tiered. > Yes It is running a major compaction. Even with a lot of overhead, we expect it to take more than two weeks :( We are hoping to find some way to speed up things a bit.
