Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
Sender: scode@scode.org
In-Reply-To: <1311006328710-6595415.post@n2.nabble.com>
References: <1311006328710-6595415.post@n2.nabble.com>
Date: Mon, 18 Jul 2011 18:43:36 +0200
Message-ID: 
 <CAO5xsd0JdLySo8zu6S-stFzdF=rN9S7DNSETn_zaSuEXq02-1g@mail.gmail.com>
Subject: Re: How are column sort handled?
From: Peter Schuller <peter.schuller@infidyne.com>
To: user@cassandra.apache.org
Cc: cassandra-user@incubator.apache.org
Content-Type: text/plain; charset=UTF-8

> Trying to understand the overhead when multiple columns are spread accross
> ssTables. For eg: Key K1 column b and c are in ssTable 1 and column a in
> ssTable 2. As I understand columns in a given row are sorted at the time
> it's stored. So does it mean that when "a" goes to ssTable 2 it also fetches
> column "b" and "c" from ssTable 1 and writes a,b,c in ssTable 2? Or in this
> case the sorting occurs on the columnSlice read call?

Currently, the only time data is "moved" to other sstables is during
compaction. When sstable 2 is flushed containing column "a", that
causes subsequent reads for data in the row to have to read from
sstable 1 and 2 both. At some future point where sstable 1 and sstable
2 participate in a compaction, they will be merged (or indirectly
later on if they don't directly participate in a compaction).

This is why slowly spreading out writes over lots of rows over time
can decrease read performance, as the average row can become more
spread out over multiple sstables. This is one potential driver for
compaction.

-- 
/ Peter Schuller (@scode on twitter)