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 ben.coverston@datastax.com
 designates 209.85.210.44 as permitted sender)
Message-ID: <4DEE4ECD.1070407@datastax.com>
Date: Tue, 07 Jun 2011 10:16:13 -0600
From: Benjamin Coverston <ben.coverston@datastax.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: user@cassandra.apache.org
Subject: Re: Backups, Snapshots, SSTable Data Files, Compaction
References: <4DEDB132.4070100@dude.podzone.net>	<4DEDB65C.203@datastax.com>
	<4DEDD135.6090800@dude.podzone.net>
 <BANLkTi=-Zks61ghf1WOZ5qUnhS5PT+UESA@mail.gmail.com>
 <4DEE4068.9090802@dude.podzone.net>
In-Reply-To: <4DEE4068.9090802@dude.podzone.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi AJ,

Unfortunately, for storage capacity planning it's a bit of a guessing 
game. Until you run your load against it and profile the usage you just 
are not going to know for sure. I have seen cases where planning to have 
50% excess capacity/node was plenty, and I have seen other extreme cases 
where 3x planned capacity was not enough when replica counts and entropy 
levels are high.

Cassandra will _try_ to work within the resource restrictions that you 
give it, but keep in mind that if it has excess resources in terms of 
disk space it may be a bit more lazy than you would expect in getting 
rid of some of the extra files that are sitting around waiting to be 
deleted. You know if they are scheduled to be deleted have a .compacted 
marker. If you want to actually SEE this happen use the stress.java or 
stress.py tools and do several test runs with different workloads. I 
think actually watching it happen would be enlightening for you.

Lastly while I have seen a few instances where people have chosen to use 
node sizes with 10's of TB, it is an unusual case. Most node sizing I 
have seen falls in the range of 20-250GB. Not to say that there aren't 
workloads where having many TB/Node doesn't work, but if you're planning 
to read from the data you're writing you do want to ensure that your 
working set is stored in memory.

HTH,
Ben


On 6/7/11 9:14 AM, AJ wrote:
> On 6/7/2011 2:29 AM, Maki Watanabe wrote:
>> You can find useful information in:
>> http://www.datastax.com/docs/0.8/operations/scheduled_tasks
>>
>> sstables are immutable. Once it written to disk, it won't be updated.
>> When you take snapshot, the tool makes hard links to sstable files.
>> After certain time, you will have some times of memtable flushs, so
>> your sstable files will be merged, and obsolete sstable files will be
>> removed. But snapshot set will remains on your disk, for backup.
>>
>
> Thanks for the doc source.  I will be experimenting with 0.8.0 since 
> it has many features I've been waiting for.
>
> But, still, if the snapshots don't link to all of the previous sets of 
> .db files, then those unlinked previous file sets MUST be safe to 
> manually delete.  But, they aren't deleted until later after a GC.  
> It's a bit confusing why they are kept after compaction up until GC 
> when they seem to not be needed.  We have Big Data plans... one node 
> can have 10's of TBs, so I'm trying to get an idea of how much disk 
> space will be required and whether or not I can free-up some disk space.
>
> Hopefully someone can still elaborate on this.
>
>

-- 
Ben Coverston
Director of Operations
DataStax -- The Apache Cassandra Company
http://www.datastax.com/