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 mohitanchlia@gmail.com
 designates 209.85.210.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4ea6fd6b.4216ec0a.6da8.ffffabba@mx.google.com>
References: 
 <CAADnm_cHOP_YZNx5iAx+nuqb2NGE9u_6RnnBv-i1Fpux3Avw1A@mail.gmail.com>
	<4ea6fd6b.4216ec0a.6da8.ffffabba@mx.google.com>
Date: Tue, 25 Oct 2011 11:22:50 -0700
Message-ID: 
 <CAOT3TWpqNvhc7mtENbSidf3hu3ZqTDUCb55m_WdbgW3VrVaS7A@mail.gmail.com>
Subject: Re: Cassandra cluster HW spec (commit log directory vs data file
 directory)
From: Mohit Anchlia <mohitanchlia@gmail.com>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 25, 2011 at 11:18 AM, Dan Hendry <dan.hendry.junk@gmail.com> wr=
ote:
>> 2. ... So I am going to use rotational disk for the commit log and an SS=
D
>> for data. Does this make sense?
>
>
>
> Yes, just keep in mind however that the primary characteristic of SSDs is
> lower seek times which translates into faster random access. We have a
> similar Cassandra use case (time series data and comparable volumes) and
> decided the random read performance boost (unquantified in our case to be
> fair) was not worth the price and we went with more, larger, cheaper 7.2k
> HDDs.
>
>
>
>> 3. What's the best way to find out how big my commitlog disk and my data
>> disk has to be? The Cassandra hardware page says the Commitlog disk
>> shouldn't be big but still I need to choose a size!
>
>
>
> As of Cassandra 1.0, the commit log has an explicit size bound (defaultin=
g
> to 4GB I believe). In 0.8, I dont think I have ever seen my commit log gr=
ow
> beyond that point but the limit should be the ammount of data you insert
> within the maximum CF timed flush period (=93memtable_flush_after=94 para=
meter,
> to be safe, maximumum across all CFs). Any modern drive should be
> sufficient. As for the size of your data disks, that is largely applicati=
on
> dependent, and you should be able to judge best based on your currnet
> cluster.
>
>
>
>> 4. I also noticed RAID 0 configuration is recommended for the data file
>> directory. Can anyone explain why?
>
>
>
> In comparison to RAID1/RAID1+0? For any RF > 1, Cassadra already takes ca=
re
> of redundancy by replicating the data across multiple nodes. Your
> applications choice of replication factor and read/write consistencies
> should be specified to tollerate a node failing (for any reason: disk
> failure, network failure, a disgruntled employee taking a sledge hammer t=
o
> the box, etc). As such, what is the point of waisting your disks duplicat=
ing
> data on a single machine to minimize the chances of one particular type o=
f
> failure when it should not matter anyways?

It all boils down to operations cost vs hardware cost. Also consider
MTBF and how equipped you are to handle disk failures which are more
common than others.
>
>
>
> Dan
>
>
>
> From: Alexandru Sicoe [mailto:adsicoe@gmail.com]
> Sent: October-25-11 8:23
> To: user@cassandra.apache.org
> Subject: Cassandra cluster HW spec (commit log directory vs data file
> directory)
>
>
>
> Hi everyone,
>
> I am currently in the process of writing a hardware proposal for a Cassan=
dra
> cluster for storing a lot of monitoring time series data. My workload is
> write intensive and my data set is extremely varied in types of variables
> and insertion rate for these variables (I will have to handle an order of=
 2
> million variables coming in, each at very different rates - the majority =
of
> them will come at very low rates but there are many that will come at hig=
her
> rates constant rates and a few coming in with huge spikes in rates). Thes=
e
> variables correspond to all basic C++ types and arrays of these types. Th=
e
> highest insertion rates are received for basic types, out of which U32
> variables seem to be the most prevalent (e.g. I recorded 2 million U32 va=
rs
> were inserted in 8 mins of operation while 600.000 doubles and 170.000
> strings were inserted during the same time. Note this measurement was onl=
y
> for a subset of the total data currently taken in).
>
> At the moment I am partitioning the data in Cassandra in 75 CFs (each CF
> corresponds to a logical partitioning of the set of variables mentioned
> before - but this partitioning is not related with the amount of data or
> rates...it is somewhat random). These 75 CFs account for ~1 million of th=
e
> variables I need to store. I have a 3 node Cassandra 0.8.5 cluster (each
> node is a 4 real core with 4 GB RAM and split commit log directory and da=
ta
> file directory between two RAID arrays with HDDs). I can handle the load =
in
> this configuration but the average CPU usage of the Cassandra nodes is
> slightly above 50%. As I will need to add 12 more CFs (corresponding to
> another ~ 1 million variables) plus potentially other data later, it is
> clear that I need better hardware (also for the retrieval part).
>
> I am looking at Dell servers (Power Edge etc)
>
> Questions:
>
> 1. Is anyone using Dell HW for their Cassandra clusters? How do they beha=
ve?
> Anybody care to share their configurations or tips for buying, what to av=
oid
> etc?
>
> 2. Obviously I am going to keep to the advice on the
> http://wiki.apache.org/cassandra/CassandraHardware and split the commmitl=
og
> and data on separate disks. I was going to use SSD for commitlog but then
> did some more research and found out that it doesn't make sense to use SS=
Ds
> for sequential appends because it won't have a performance advantage with
> respect to rotational media. So I am going to use rotational disk for the
> commit log and an SSD for data. Does this make sense?
>
> 3. What's the best way to find out how big my commitlog disk and my data
> disk has to be? The Cassandra hardware page says the Commitlog disk
> shouldn't be big but still I need to choose a size!
>
> 4. I also noticed RAID 0 configuration is recommended for the data file
> directory. Can anyone explain why?
>
> Sorry for the huge email.....
>
> Cheers,
> Alex
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.920 / Virus Database: 271.1.1/3972 - Release Date: 10/24/11
> 14:35:00