I completely agree with others here. It depends on your use case. We were
using Hi1.4xlarge boxes and paying huge amount to Amazon, lately our
requirements changed and we are not hammering C* as much and our data size
has gone down too, so given the new conditions we reserved and migrated to
c3.4xl
Still using good ol' m1.xlarge here + external caching (memcached). Trying
to adapt our use case to have different clusters for different use cases so
we can leverage SSD at an acceptable cost in some of them.
On Tue, Aug 19, 2014 at 1:05 PM, Shane Hansen
wrote:
> Again, depends on your use cas
Again, depends on your use case.
But we wanted to keep the data per node below 500gb,
and we found raided ssds to be the best bang for the buck
for our cluster. I think we moved to from the i2 to c3 because
our bottleneck tended to be CPU utilization (from parsing requests).
(Discliamer, we're n
You're pricing it out at $ per GB… that's not the way to look at it.
Price it out at $ per IO… Once you price it that way, SSD makes a LOT more
sense.
Of course, it depends on your workload. If you're just doing writes, and
they're all sequential, then cost per IO might not make a lot of sense.
Short answer, it depends on your use-case.
We migrated to i2.xlarge nodes and saw an immediate increase in performance.
If you just need plain ole raw disk space and don’t have a performance
requirement to meet then the m1 machines would work, or hell even SSD EBS
volumes may work for you. Th
The latest consensus around the web for running Cassandra on EC2 seems to
be "use new SSD instances." I've not seen any mention of the elephant in
the room - using the new SSD instances significantly raises the cluster
cost per TB. With Cassandra's strength being linear scalability to many
terabyte
