HBase和Cassandra比较

HBase是一个开源的分布式存储系统。他可以看作是Google的Bigtable的开源实现。如同Google的Bigtable使用Google File System一样，HBase构建于和Google File System类似的Hadoop HDFS之上。

Cassandra可以看作是Amazon Dynamo的开源实现。和Dynamo不同之处在于，Cassandra结合了Google Bigtable的ColumnFamily的数据模型。可以简单地认为，Cassandra是一个P2P的，高可靠性并具有丰富的数据模型的分布式文件系统。

HBase vs Cassandra

	HBase	Cassandra
语言	Java	Java
出发点	BigTable	BigTable and Dynamo
License	Apache	Apache
Protocol	HTTP/REST (also Thrift)	Custom, binary (Thrift)
数据分布	表划分为多个region存在不同region server上	改进的一致性哈希（虚拟节点）
存储目标	大文件	小文件
一致性	强一致性	最终一致性，Quorum NRW策略
架构	master/slave	p2p
高可用性	NameNode是HDFS的单点故障点	P2P和去中心化设计，不会出现单点故障
伸缩性	Region Server扩容，通过将自身发布到Master，Master均匀分布Region	扩容需在Hash Ring上多个节点间调整数据分布
读写性能	数据读写定位可能要通过最多6次的网络RPC，性能较低。	数据读写定位非常快
数据冲突处理	乐观并发控制（optimistic concurrency control）	向量时钟
临时故障处理	Region Server宕机，重做HLog	数据回传机制：某节点宕机，hash到该节点的新数据自动路由到下一节点做 hinted handoff，源节点恢复后，推送回源节点。
永久故障恢复	Region Server恢复，master重新给其分配region	Merkle 哈希树，通过Gossip协议同步Merkle Tree，维护集群节点间的数据一致性
成员通信及错误检测	Zookeeper	基于Gossip
CAP	1，强一致性，0数据丢失。2，可用性低。3，扩容方便。	1，弱一致性，数据可能丢失。2，可用性高。3，扩容方便。

facebook为什么放弃Cassandra？

参考：http://www.zhihu.com/question/19593207:

Facebook开发Cassandra初衷是用于Inbox Search，但是后来的Message System则使用了HBase，Facebook对此给出的解释是Cassandra的最终一致性模型不适合Message System，HBase具有更简单的一致性模型，当然还有其他的原因。HBase更加的成熟，成功的案例也比较多等等。Twitter和Digg都曾经很高调的选用Cassandra，但是最后也都放弃了，当然Twitter还有部分项目也还在使用Cassandra，但是主要的Tweet已经不是了。