* Cassandra supports 1000s of ColumnFamilies in a cluster; HBase supports a handful (HBase book says “two or three” but let’s be generous)
* Cassandra’s p2p design gives you “read slaves” for free; HBase reads and writes all go through a single regionserver per region
* Cassandra offers built-in caching; HBase installations tend to rely heavily on memcached
* Cassandra is far, far ahead of HBase in dealing with compaction; this includes parallel (multiple threads per compaction) and concurrent (multiple simultaneous compactions per server), throttling to avoid latency spikes, “leveled” compaction to optimize for reads, and the ability to remove deleted or expired data during minor compactions as well as major
* Cassandra’s p2p design provides full availability, as well as the multi-datacenter capabilities you mentioned. HBase relies on the HDFS namenode SPOF as well as regionserver mini-SPOFs
* Multi-DC can also solve the batch/interactive conflict you mention; best practice for Cassandra is to create a “virtual DC” for your Hadoop jobs and let Cassandra replicate between that and your interactive “DC,” bidirectionally
* Cassandra manages its own local storage per node, which allows you to (for instance) dedicate a spindle to your commitlog, or pin certain columnfamilies to SSDs

Here are some notes that update discussion as of May 12 2012:
* Composite keys and ordering of records is now standard (just like HBase)
** this enables efficient parallel processing at the Mapper input stage for map-reduce. Although it would not be as fast as map-reduce directly over hdfs, it would be similar to a Mapper stage reading from HBase RegionServers
* super columns are deprecated (good thing)
* atomic counters were added
* Both have TTL, time to live metadata, which means self-cleaning (yeah).
* When FB switched from Cassandra to HBase, they said the change was driven by Cassandra team members leaving (perhaps going to DataStax) and also because eventual consistency was a problem in Cassandra.
* So far, Cassandra is easier to administer since they have a funded support company (DataStax) that gives out plenty of free advice.
** HBase might catch up eventually; big-table technology is proven to work fine for Google.
* Michael Stack has often said HBase is good for TB sized data and larger.
** For me, setting up HBase for 100GB on 4 nodes certainly seems harder than necessary.
** A P2P installation mechanism for HBase is not yet available (I continue to nudge).
* Any distributed store can have performance killing hotspots (all activity on one or 2 nodes) if keys are not chosen wisely.
* Under a heavy write and insert load ANY storage mechanism (distributed or not) can get behind on compacting/splitting/re-org.
** This is a matter of admin discipline, there must be headroom for periodic cleanup/reorg (when Scotty says the warp drives cannot go faster without later down time, he means it.)
** The safer approach is to separate batch and interactive operations.
* Both have commit logs and can detect/repair disk errors (over-write, wrong sector written, etc.)
* Cassandra deployments split across data centers has actually been attempted by FB, but I have not seen any experience reports on how well that works.
* Cassandra only supports the Thrift interface which does not have a way to stream large objects.