cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anuj Wadehra <>
Subject Drawbacks of Major Compaction now that Automatic Tombstone Compaction Exists
Date Tue, 14 Apr 2015 01:23:29 GMT
Recently we faced an issue where every repair operation caused addition of hundreds of sstables
(CASSANDRA-9146). In order to bring situation under control and make sure reads are not impacted,
we were left with no option but to run major compaction to ensure that thousands of tiny sstables
are compacted.

Does major compaction has any drawback after automatic tombstone compaction got implemented
in 1.2 via tombstone_threshold sub-property(CASSANDRA-3442)? 
I understand that the huge SSTable created after major compaction wont be compacted with new
data any time soon but is that a problem if purged data is removed via automatic tombstone
compaction? If we major compaction results in a huge file say 500GB, what are the drawbacks
of it?

If one big sstable is a problem, is there any way of solving the problem? We tried running
sstablesplit after major compaction to split the big sstable but as new sstables were of same
size they are again compacted into single huge table once Cassandra was started after executing


Anuj Wadehra

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message