Cassandra Notes from Bits and Bytes

Dominic Williams has an excellent post at Bits and Bytes on why he (his company, really) moved to Cassandra. This post is a simple digesting of the salient points he makes that speak to me (and a few points I add as commentary). For any who might care, because of the heavy analytical work I’m involved in, we’ll be sticking with Hadoop and perhaps HBase for the time being, but it’s good to keep an eye on this technology. I’ve actually got a few projects that are queued up in my mind which Cassandra would be a great fit for… at least… I think it will be… until I get a chance to play with it!

1. Blood Line
   1. Gross generalization of breed strengths.
   2. Who made this technology and why?
   3. Brutally pragmatic.
   4. HDFS is for analyitics.
   5. Cassandra is for distributed access.
   6. Code culture – what can you expect from the community.
2. Momentum
   1. Generally, who is still moving forwards and at what rate?
   2. Consider that HBase is older.
   3. Consider that Cassandra is yonger, but yet quite mature. Bit momentum there.
   4. Consider the raw count of developers in #cassandra and #hbase on freenode.org’s IRC server at any given time.
3. CAP – CA vs. AP
   1. CAP – Consistency, Availability, Partitioning.
   2. False dichotomy between CA and AP.
   3. Cassandra lets you choose.
   4. HBase focuses intentionally on CA. Region Node is a failure point.
   5. Specifically, notice the read and write levels mentioned in the Cassandra wiki.
4. HBase requires setting up Hadoop and Zookeeper. Added management thrash, but added systems which you may be using anyway.
5. Cassandra seems to have a performance edge for single record references.
6. MapReduce will be available for Cassandra in v. 0.6. Yay!

So, there you go. Not an earth shattering post, but an exercise that’s helped me. Hope you enjoyed it!

About these ads