HBase和Cassandra比较

2014.06.24 | Comments

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已经不是了。


原创文章,转载请注明: 转载自JavaChen Blog,作者:JavaChen
本文链接地址:http://blog.javachen.com/2014/06/24/hbase-vs-cassandra.html
本文基于署名2.5中国大陆许可协议发布,欢迎转载、演绎或用于商业目的,但是必须保留本文署名和文章链接。 如您有任何疑问或者授权方面的协商,请邮件联系我。