Hi all,
I got some keyspaces who becomes read-only after certain time, I would like to reduce the number of File descriptors and open files which consume a lot of memory , so I plan to compact keyspaces to a small number of sstables.My question is this, what would be the best practice in such a case? I am assuming that reducing it to 1 Data sstable might cause issues, as the summary file and the Index file will be quite large and demand a deeper scan on read.note: that these keyspaces are read-only , so I'm not concerned with many auto-compactions happen latter
Bringing together the Apache Cassandra experts from the community and DataStax.
Want to learn? Have a question? Want to share your expertise? You are in the right place!
Not sure where to begin? Getting Started
what is the Best practice to reducing sstable numbers of no-longer mutating keyspaces
@rzilkha_129571 there isn't a real need to reduce the number of SSTables in Cassandra and as you already know, you're likely to create more problems than what you are trying to solve. Normal compaction operations will eventually coalesce the data and we don't advice forcing major compactions on tables.
For tables using SizeTieredCompactionStrategy, if you really need to reduce the number of files then make sure you specify the --split-output flag so you don't end up with a single large SSTable. For more info, check out this KB article I wrote -- Why is forcing major compaction on a table not ideal? Cheers!
Thank you.
What about modifying the compaction strategy to Leveled Compaction , wouldn't it be a good approach for keyspaces, once they become read-only (in my use case) ?
@rzilkha_129571 there's no real benefit to switching to LCS since all you're doing is forcing a major compaction. That will normally happen on STCS. Again, there's no real reason why you need to focus on reducing the number of SSTables. Cheers!
3 People are following this question.
