I'm also quite interested in this question. Here's my understanding on this problem.
1. If your workload is append-only, doing a major compaction shouldn't affect the read performance too much, because each row appears in one sstable anyway. 2. If your workload is mostly updating existing rows, then more and more columns will be obsoleted in that big sstable created by major compaction. And that super big sstable won't be compacted until you either have another 3 similar-sized sstables or start another major compaction. But I am not very sure whether this will be a major problem, because you only end up with reading one more sstable. Using size-tiered compaction against mostly-update workload itself may result in reading multiple sstables for a single row key. Please correct me if I am wrong. Cheng On Thu, Apr 26, 2012 at 3:50 PM, Fredrik <fredrik.l.stigb...@sitevision.se>wrote: > In the tuning documentation regarding Cassandra, it's recomended not to > run major compactions. > I understand what a major compaction is all about but I'd like an in depth > explanation as to why reads "will continually degrade until the next major > compaction is manually invoked". > > From the doc: > "So while read performance will be good immediately following a major > compaction, it will continually degrade until the next major compaction is > manually invoked. For this reason, major compaction is NOT recommended by > DataStax." > > Regards > /Fredrik >
