Reddit's May 2010 "State of the Servers" report
blog.reddit.com
blog.reddit.com
Reddit was originally on L instances.
(HMXL is generally the sweet spot for Cassandra price/performance on EC2, IMO.)
The first category will start small. The smallest production deployment I know is a single 256MB VM, but usually even starting small you should not have less than 2 servers (why tempt fate with a non-redundant setup when Cassandra makes it so easy to be safe?).
The second group is where you see larger deployments out of the gate. 3 machines does seem small for reddit; I guess they made up the difference with memcached. Unfortunately they deployed just before the 0.6.0 final release was out, which is where we added the row cache feature that could have made memcached unnecessary.
+There are people using cassandra for non-scale-related reasons, though. Most of these people are motivated by multi-datacenter replication.
I have no idea what TFA meant by "at only three nodes we weren't able to take advantage of most of Cassandra's safeguards for ending up in this situation," except in the sense that adding an extra 20k ops/s on a 30 node cluster will be 10% of capacity instead of 100%. (Just picking reasonable ballpark numbers, I don't know what reddit's are.)
The consistency guarantees Cassandra gives you are based upon configuration values (ReplicationFactor) and a ConsistencyLevel provided at runtime when performing an operation. A perfectly available, partition-tolerant and perfectly consistent system is impossible so adjusting these settings lets you specify the tradeoffs you desire.
If for all operations you specify a consistency level of ALL, you are guaranteed consistency. However, you lose availability if one server (for a given part of a keyspace) goes down.
Conversely, you can also use Cassandra in a way that offers few consistency guarantees by specifying a ConsistencyLevel of ANY, or ONE. Further, you can perform reads with ConsistencyLevel ONE that don't give you a guarantee that the information you read is consistent. As long as no servers go down, you have consistency, and as long as you have one server left, you have complete availability.
The QUORUM consistency level guarantees at least (ReplicationFactor/2 + 1) nodes agree on a write and gets the latest timestamp from a majority of servers on read. This offers both consistency and availability. For three servers with a ReplicationFactor of 2 this is the same as ALL; if your ReplicationFactor is 1 you lose effective consistency guarantees.
So, to be able to use the full range of options in the consistency/availability tradeoff space one needs a cluster of at least four servers. Someone let me know if my reasoning is incorrect.
See http://wiki.apache.org/cassandra/API for more info.
That said, there are ways we can mitigate this, primarily in https://issues.apache.org/jira/browse/CASSANDRA-685
I took a break and checked out Reddit and HN. Stumbled upon this article and the GrooveShark AMA. I realized that these days some of the big websites are moving toward similar situation with that of a typical enterprise apps situation where there are different components/sub-systems written in different technologies. Is my assumption wrong?
Seems like between Enterprise App (whatever Enterprise means) and these big Web 2.0 apps, the difference is only in the matter of the users; the former is geared toward businesses where the latter is leaning toward customers/end-users. The technology obstacles are rather similar.
ahh the joy of robot-email-responders.