Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of jbellis@gmail.com designates
 209.85.214.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <OFCF1B95BC.F7B96FC4-ONC12579DC.004EA966-C12579DC.004F3139@urssaf.fr>
References: 
 <OFCF1B95BC.F7B96FC4-ONC12579DC.004EA966-C12579DC.004F3139@urssaf.fr>
From: Jonathan Ellis <jbellis@gmail.com>
Date: Tue, 10 Apr 2012 11:14:23 -0500
Message-ID: 
 <CALdd-zibCcJ5kJ3Z848Qg8sga3fOmRjcBD4na0KMLHo9VrWqiQ@mail.gmail.com>
Subject: Re: Why so many SSTables?
To: user@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

LCS explicitly tries to keep sstables under 5MB to minimize extra work
done by compacting data that didn't really overlap across different
levels.

On Tue, Apr 10, 2012 at 9:24 AM, Romain HARDOUIN
<romain.hardouin@urssaf.fr> wrote:
>
> Hi,
>
> We are surprised by the number of files generated by Cassandra.
> Our cluster consists of 9 nodes and each node handles about 35 GB.
> We're using Cassandra 1.0.6 with LeveledCompactionStrategy.
> We have 30 CF.
>
> We've got roughly 45,000 files under the keyspace directory on each node:
> ls -l /var/lib/cassandra/data/OurKeyspace/ | wc -l
> 44372
>
> The biggest CF is spread over 38,000 files:
> ls -l Documents* | wc -l
> 37870
>
> ls -l Documents*-Data.db | wc -l
> 7586
>
> Many SSTable are about 4 MB:
>
> 19 MB -> 1 SSTable
> 12 MB -> 2 SSTables
> 11 MB -> 2 SSTables
> 9.2 MB -> 1 SSTable
> 7.0 MB to 7.9 MB -> 6 SSTables
> 6.0 MB to 6.4 MB -> 6 SSTables
> 5.0 MB to 5.4 MB -> 4 SSTables
> 4.0 MB to 4.7 MB -> 7139 SSTables
> 3.0 MB to 3.9 MB -> 258 SSTables
> 2.0 MB to 2.9 MB -> 35 SSTables
> 1.0 MB to 1.9 MB -> 13 SSTables
> 87 KB to =A0994 KB -> 87 SSTables
> 0 KB -> 32 SSTables
>
> FYI here is CF information:
>
> ColumnFamily: Documents
> =A0 Key Validation Class: org.apache.cassandra.db.marshal.BytesType
> =A0 Default column value validator: org.apache.cassandra.db.marshal.Bytes=
Type
> =A0 Columns sorted by: org.apache.cassandra.db.marshal.BytesType
> =A0 Row cache size / save period in seconds / keys to save : 0.0/0/all
> =A0 Row Cache Provider: org.apache.cassandra.cache.SerializingCacheProvid=
er
> =A0 Key cache size / save period in seconds: 200000.0/14400
> =A0 GC grace seconds: 1728000
> =A0 Compaction min/max thresholds: 4/32
> =A0 Read repair chance: 1.0
> =A0 Replicate on write: true
> =A0 Column Metadata:
> =A0 =A0 Column Name: refUUID (72656655554944)
> =A0 =A0 =A0 Validation Class: org.apache.cassandra.db.marshal.BytesType
> =A0 =A0 =A0 Index Name: refUUID_idx
> =A0 =A0 =A0 Index Type: KEYS
> =A0 Compaction Strategy:
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy
> =A0 Compression Options:
> =A0 =A0 sstable_compression: org.apache.cassandra.io.compress.SnappyCompr=
essor
>
> Is it a bug? If not, how can we tune Cassandra to avoid this?
>
> Regards,
>
> Romain


--=20
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com