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 jbellis@gmail.com designates
 209.85.215.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA7A96E5.2B3CB%arun.jacob@email.disney.com>
References: <CA7A96E5.2B3CB%arun.jacob@email.disney.com>
From: Jonathan Ellis <jbellis@gmail.com>
Date: Wed, 24 Aug 2011 21:54:16 -0500
Message-ID: 
 <CALdd-zhNWia1=DmBPSsSbo4oY6cB8wndnvD+cpM6b4UqHn0tKQ@mail.gmail.com>
Subject: Re: Cassandra Node Requirements
To: user@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 24, 2011 at 1:54 PM, Jacob, Arun <Arun.Jacob@disney.com> wrote:
> we need to cap data size at 50% of total node storage capacity for
> compaction

Sort of.  There's some fine print, such as the 50% number is only if
you're manually forcing major compactions, which is not recommended,
but a bigger thing to know is that 1.0 will introduce "leveled
compaction" [1] inspired by leveldb.  The free space requirement will
then be a small number of megabytes.

[1] https://issues.apache.org/jira/browse/CASSANDRA-1608

> SSDs are preferred, but of course =A0reduce storage capacity
> using standard storage means you bump up your RAM to keep as much in memo=
ry
> as possible.

You want to keep "as much in ram as possible" either way; whether you
need SSDs or not depends on whether that's adequate for your "hot"
working set.

> is 8TB (meaning 1.33 actual TB storage/node) a reasonable per node storag=
e
> size for Cassandra?

That's fine, but keep in mind that repairing that much data if you
lose a node could take a while.  Other things being equal, I'd prefer
more nodes with less capacity.

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