HBase作为存储方案

HBase存储特点

* Client

1. 包含访问HBase的接口，并维护cache来加快对HBase的访问，比如region的位置信息。

* Zookeeper：

1. 选举集群中的Master，Master与RegionServers 启动时会向ZooKeeper注册。

2. 存储所有Region的寻址入口。

3. 实时监控Region server状态并实时通知Master。

4. 存储HBase的schema和table元数据。

5. 使Master不存在单点故障。

* Master

1. 在Region Split后，为Region server分配region。

2. 管理HRegionServer的负载均衡，调整Region分布。

3. 发现失效的Region server后重新分配其上的region，并负责Regions迁移。。

4. 管理用户对table的增删改查操作。

* Region Server

1. Regionserver维护region，处理对这些region的IO请求，向HDFS文件系统读写数据。

2. Regionserver负责切分在运行过程中变得过大的region。

* Region

1. table按照行分割成若干Region，每个Region对应table中的一个Region。

2. Region由多个HStore组成。

* HLog

1. 类似mysql的binlog，数据会先写到WAL上，然后再放到内存中，数据恢复。

2. 已经持久化到StoreFile的HLog会定期被删除。

* HStore

1. HBase的存储核心，由MemStore和StoreFile组成。

2. 每个HStore对应Table的一个列族的存储。

* MemStore

1. 数据不直接写磁盘而是先写到MemStore，当满了才会Flush到StoreFile中。

2. 底层由HFile实现。

3. 数据只需写入到此内存即可返回，快速的插入操作。

* StoreFile

1. StoreFile文件数到一定阀值会触发Compact合并操作，多个StoreFile变成一个StoreFile。

2. 所有数据操作都是添加操作，保证I/O，而对于数据更新/删除都是在后续compact过程中完成。

底层存储

HBase支持很多文件系统的存储。

1. 操作系统原生文件系统。

2. HDFS文件系统。

3. 其他文件系统。

HDFS可靠性高及其同属同个生态，选择HDFS作为存储。

HBase 如何寻址

寻址过程大致为client -> -ROOT- -> .META. -> RS ->region -> rowkey。

client通过zookeeper的root-region-server节点获取哪个Server管理-ROOT-表，包含该机器的IP地址和端口。
接着访问-ROOT-表，该表只有一个Region且不会split，每行记录了.META.表的一个region信息，以及这个region的startkey和endkey，查找到.META.表包含要查的rowkey记录的Region的ip和端口。
接着访问该ip和端口的.META.表，根据rowkey找到用户表数据存放对应的Region的机器信息，根据rowkey查找对应的regionserver和region。最后到对应的region找到value。
根据查到的用户表信息到对应机器上查找数据。

客户端会缓存查询过的rowkey的地址。

client访问hbase上数据的过程并不需要master参与（寻址访问zookeeper和region server，数据读写访问region server），master仅仅维护table和region的元数据信息，负载很低。

HBase 的性能、如何扩展

HBase的插入性能很好，查询还不错，腾讯给出的数据是经过调优在百亿数据级别80%以上数据能在20ms查到。

详细的一些数据后面在写代码阶段会给出。

当数据峰值接近系统设计容量时，可以简单的通过增加服务器的方式来扩大容量。某种程度上来说，这个动态扩容过程无需停机，HBase系统可以照常运行并提供读写服务，完全实现动态无缝无宕机扩容。

balance模式下，会自动将数据迁移到新机器上，适合中小集群，迁移过程大量消耗机器资源。

非balance模式下，新写入文件写到新机器上。

运维

官方的命令行或二次开发，rest接口。官方有原生监控平台。
BigInsights。

最后的说明

hbase优势在于接近线性的任意水平扩展，不必在单机上与redis性能太较真，看自己场景选择。