HBase与Cassandra对比参考
2019-04-09 本文已影响0人
liuzx32
HBase Master工作机制
一、Master上线
Master启动进行以下步骤：
- 从zookeeper上获取唯一一个代表active master的锁，用来阻止其它master成为活着的master。
- 扫描zookeeper上的server父节点，获得当前可用的region server列表。
和每个region server通信，获得当前已分配的region和region server的对应关系。 - 扫描.META.region的集合，计算得到当前还未分配的region，将他们放入待分配region列表。
二、Master下线
Master下线后，HBase数据表的数据读写还可以正常进行。因此Master下线短时间内对整个HBase集群没有影响。
由于master只维护表和region的元数据，而不参与表数据IO的过程，master下线仅导致所有元数据的修改被冻结。其中包括
- 无法创建删除表；
- 无法修改表的schema；
- 无法进行region的负载均衡；
- 无法处理region上下线；
- 无法进行region的合并；
- 唯一例外的是region的split可以正常进行，因为只需要RegionServer参与即可；
| Name | Cassandra | HBase |
|---|---|---|
| 一致性 | Quorum NRW策略，通过Gossip协议同步Merkle Tree，维护集群节点间的数据一致性 | 单节点（RegionServer），无复制（但底层存储HDFS多副本），强一致性（Region只属于一个RegionServer） |
| 可用性 | 1，基于Consistent Hash相邻节点复制数据，数据存在于多个节点，无单点故障。2，某节点宕机，hash到该节点的新数据自动路由到下一节点做 hinted handoff，源节点恢复后，推送回源节点。3，通过Gossip协议维护集群所有节点的健康状态，并发送同步请求，维护数据一致性。4，SSTable，纯文件，单机可靠性一般。 | 1，存在单点故障，单个RegionServer宕机后，短时间内该server维护的region无法访问，需要等待failover生效后才提供数据可用性。2，通过Master维护各RegionServer的健康状况和Region的分布。3，可以有多个Master节点，Master宕机有ZK投票机制选取下一任Master。Master就算全宕机，也不影响Region读写。Master仅充当一个自动运维角色。4，HDFS为分布式存储系统，多副本且高可靠，0数据丢失。5，HDFS的namenode是一个SPOF（单点）。 |
| 伸缩性 | 1，Consistent Hash，快速定位数据所在节点。2，扩容需在Hash Ring上多个节点间调整数据分布。 | 1，通过ZK定位目标RegionServer，最后定位Region。2，RegionServer扩容，通过将自身发布到Master，Master均匀分布。 |
| 负载均衡 | 请求ZK取得整个集群地址，然后根据Consistent Hash选择合适的节点。client会缓存集群地址。 | 请求ZK取读写数据路由表定位RegionServer，Master会修改这个路由表。Client自身也会缓存一部分路由信息。 |
| 数据差异比较算法 | Merkle Tree , Bloom Filter | Bloom Filter |
| 锁与事务 | Client Timestap（Dynamo使用vector lock） | Optimistic Concurrency Control |
| 读写性能 | 数据读写定位非常快。 | 数据读写定位可能要通过最多6次的网络RPC，性能较低。 |
| CAP点评 | 属于AP产品，1，弱一致性，数据可能丢失。2，可用性高。3，扩容方便。 | 属于CP产品，1，强一致性，0数据丢失。2，可用性低。3，扩容方便。 |
