Return-Path: 
 <user-return-22691-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org>
X-Original-To: apmail-cassandra-user-archive@www.apache.org
Delivered-To: apmail-cassandra-user-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 8585D9904
	for <apmail-cassandra-user-archive@www.apache.org>;
 Sat,  3 Dec 2011 02:14:25 +0000 (UTC)
Received: (qmail 75496 invoked by uid 500); 3 Dec 2011 02:14:23 -0000
Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org
Received: (qmail 75473 invoked by uid 500); 3 Dec 2011 02:14:23 -0000
Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@cassandra.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@cassandra.apache.org>
List-Post: <mailto:user@cassandra.apache.org>
List-Id: <user.cassandra.apache.org>
Reply-To: user@cassandra.apache.org
Delivered-To: mailing list user@cassandra.apache.org
Received: (qmail 75465 invoked by uid 99); 3 Dec 2011 02:14:23 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Dec 2011 02:14:23 +0000
X-ASF-Spam-Status: No, hits=-1.4 required=5.0
	tests=RCVD_IN_DNSWL_MED,RCVD_NUMERIC_HELO,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of
 gcdcu-cassandra-user-1@m.gmane.org designates 80.91.229.12 as permitted
 sender)
Received: from [80.91.229.12] (HELO lo.gmane.org) (80.91.229.12)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Dec 2011 02:14:16 +0000
Received: from list by lo.gmane.org with local (Exim 4.69)
	(envelope-from <gcdcu-cassandra-user-1@m.gmane.org>)
	id 1RWf6m-0005XS-HY
	for user@cassandra.apache.org; Sat, 03 Dec 2011 03:13:54 +0100
Received: from 58.240.26.202 ([58.240.26.202])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <user@cassandra.apache.org>; Sat, 03 Dec 2011 03:13:44 +0100
Received: from liangfeng by 58.240.26.202 with local (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <user@cassandra.apache.org>; Sat, 03 Dec 2011 03:13:44 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: user@cassandra.apache.org
From: liangfeng <liangfeng@made-in-china.com>
Subject: Re: Leveled Compaction in cassandra1.0 may not be perfect
Date: Sat, 3 Dec 2011 02:13:30 +0000 (UTC)
Lines: 24
Message-ID: <loom.20111203T025204-807@post.gmane.org>
References: <loom.20111202T071115-964@post.gmane.org>
 <CALdd-zhvXWPUvgfR3Ny2KcfP12T=BcWBWVCrm5WWiAGm9oVwOQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: sea.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 58.240.26.202 (Mozilla/5.0 (Windows NT 5.1;
 rv:8.0) Gecko/20100101 Firefox/8.0)



Jonathan Ellis <jbellis <at> gmail.com> writes:

> 
> I think you're confusing "temporary space used during a compaction
> operation" with "total i/o done by compaction."
> 
> Leveled compaction *will* do more i/o than size-tiered, because it's
> enforcing tighter guarantees on how compacted the data is.
> 

Yes.In fact ,I want to put two points in this topic.
1.There is no implementation in cassandra1.0 to ensure the conclusion "Only
enough space for 10x the sstable size needs to be reserved for temporary use by
compaction",so one special compaction may need big free disk space all the same.
2.Leveled compaction *will* do too much i/o,especially when we use
RandomPartitioner(because md5 token will cause overlap of many sstables all the
time). 
These two points may cause uncontrollablity when compaction occurs.
                             Thanks!