学习笔记–Hbase

  • 2020 年 2 月 10 日
  • 筆記

后面做的项目估计要使用到Hbase,因此做知识储备。个人学习路线为参考慕课网相关教学视频,然后翻看Hbase权威指南,并未做很深的原理剖析。 本次学习还有一些其他收获:

1. 传统RDBMS的扩展思路是什么? 传统关系型数据库一般早期是主从结构,一是数据安全的备份,二是读写分离分担主库压力,随着数据量的增加增加从节点,进一步降低主库压力,这些是建立在读远远大于写的情况下一种常规做法,在随着业务量的上升,终极解决方案是分库分表,分库分表解决了单一主节点写入的问题,可以把数据分散到多个主节点中,当然分库分表页带来了诸多的限制,比如事务,跨表或者跨库join。那么造成这些的根本原因是关系型数据库很难做到分布式,所以大家都是从应用层想办法解决数据库性能问题。 当然目前类似TiDB这样的分布式关系型数据库正在崛起,相信以后能够解决这些问题。

2. Hbase分布式的思路 Hbase并不是一个关系型数据库,其面对的场景时海量数据,所以吞吐量是它的目的。高吞吐量自然要使用分布式方案来解决,在Hbase架构中存在一个轻量级master节点,以及众多的region server节点,master只负责集群的管理以及分配工作,数据访问以及写入都通过region server节点进行处理,这是一种设计思路,region server与master可以理解为非强依赖,即使master挂了在短时间内也不会影响客户端的数据访问,而本身master节点又是轻量级,因此挂了快速重启即可,另一种思路就是主备master,当主master挂了之后切换到备用master,当然这样又使得应用本身复杂性增加了不少。 多个region server节点用于承担数据读写请求,那么就涉及到数据分片,Hbase与Redis很类似,其都有一个唯一的key标识,利用该值可以做sharding,Redis是最初就分为16000多个槽,然后数据分散到不同的槽当中,对于Hbase则动态的分配region,每一个region处理不同的分段rowKey,当region过大则动态分裂。

下面是本次学习笔记,后面有其他理解会在笔记中补充。