cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fredrik <>
Subject Re: Question regarding major compaction.
Date Thu, 26 Apr 2012 09:37:02 GMT
Exactly, but why would reads be significantly slower over time when 
including just one more, although sometimes large, SSTable in the read?

Ji Cheng skrev 2012-04-26 11:11:
> 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 
> < 
> <>> 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

View raw message