> 2. ... So I am going to use rotational disk for the commit log and an SSD 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 (defaulting to 4GB I believe). In 0.8, I dont think I have ever seen my commit log grow beyond that point but the limit should be the ammount of data you insert within the maximum CF timed flush period ("memtable_flush_after" parameter, to be safe, maximumum across all CFs). Any modern drive should be sufficient. As for the size of your data disks, that is largely application 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 care 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 to the box, etc). As such, what is the point of waisting your disks duplicating data on a single machine to minimize the chances of one particular type of failure when it should not matter anyways? Dan From: Alexandru Sicoe [mailto:adsi...@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 Cassandra 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 higher rates constant rates and a few coming in with huge spikes in rates). These variables correspond to all basic C++ types and arrays of these types. The 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 vars 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 only 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 the 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 data 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 behave? Anybody care to share their configurations or tips for buying, what to avoid etc? 2. Obviously I am going to keep to the advice on the http://wiki.apache.org/cassandra/CassandraHardware and split the commmitlog 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 SSDs 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