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中的1个Region。
2. Region由多个HStore组成。
* HLog
1. 类似mysql的binlog，数据会先写到WAL上，然后再放到内存中，数据恢复。
2. 已持久化到StoreFile的HLog会定期被删除。
* HStore
1. HBase的存储核心，由MemStore和StoreFile组成。
2. 每一个HStore对应Table的1个列族的存储。
* MemStore
1. 数据不直接写磁盘而是先写到MemStore，当满了才会Flush到StoreFile中。
2. 底层由HFile实现。
3. 数据只需写入到此内存便可返回，快速的插入操作。
* StoreFile
1. StoreFile文件数到1定阀值会触发Compact合并操作，多个StoreFile变成1个StoreFile。
2. 所有数据操作都是添加操作，保证I/O，而对数据更新/删除都是在后续compact进程中完成。

底层存储

HBase支持很多文件系统的存储。
1. 操作系统原生文件系统。
2. HDFS文件系统。
3. 其他文件系统。

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

HBase 如何寻址

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

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

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

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

HBase 的性能、如何扩大

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

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

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

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

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

运维

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

最后的说明

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