incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ji Cheng <memol...@gmail.com>
Subject Re: Question regarding major compaction.
Date Thu, 26 Apr 2012 09:11:21 GMT
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.stigback@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
>

Mime
View raw message