Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of jonathan.colby@gmail.com
 designates 74.125.82.44 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=from:content-type:content-transfer-encoding:subject:date:message-id
         :to:mime-version:x-mailer;
        b=OcyoHqLKoHfUNyfcuSWfZ/dsA2NnA8O/xu0yp+72LZkeOea7EN38noPbqXDbEH4z/3
         6YG3QZowWgzpxJeLD6uRkmPEfIZDLfMUrbRT/Xf3FtZW5AgI/vk1CKdcvBErAh6ecU3q
         EpkcZpfYGWnVJkHMsHa9Q01K+x5qqiSobmPYc=
From: Jonathan Colby <jonathan.colby@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: simple question about merged SSTable sizes
Date: Wed, 22 Jun 2011 18:35:57 +0200
Message-Id: <CB52C501-2ECD-4B43-9C5A-6E053F2B2806@gmail.com>
To: user@cassandra.apache.org
Mime-Version: 1.0 (Apple Message framework v1084)


The way compaction works,  "x" same-sized files are merged into a new =
SSTable.  This repeats itself and the SSTable get bigger and bigger.

So what is the upper limit??     If you are not deleting stuff fast =
enough, wouldn't the SSTable sizes grow indefinitely?

I ask because we have some rather large SSTable files (80-100 GB) and =
I'm starting to worry about future compactions.

Second, compacting such large files is an IO killer.    What can be =
tuned other than compaction_threshold to help optimize this and prevent =
the files from getting too big?

Thanks!=