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？
Facebook开发Cassandra初衷是用于Inbox Search，但是后来的Message System则使用了HBase，Facebook对此给出的解释是Cassandra的最终一致性模型，不适合Message System，HBase具有更简单的一致性模型，