Hbase非关系型数据库简介
Hbase
HBase-Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩、实时读写的分布式数据库。
Hadoop生态圈中，它是其中一部分且利用Hadoop HDFS作为其文件存储系统,利用Hadoop MapReduce来处理HBase中的海量数据,利用Zookeeper作为其分布式协同服务,主要用来存储非结构化和半结构化的松散数据（NoSQL非关系型数据库有redis、MongoDB等）。
关系型数据库和非关系型数据库
关系型数据库的3大优点：
容易理解：二维表结构是非常贴近逻辑世界的一个概念，关系模型相对网状、层次等其他模型来说更容易理解
使用方便：通用的SQL语言使得操作关系型数据库非常方便
易于维护：丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率
关系型数据库的3大瓶颈：
高并发读写需求：网站的用户并发性非常高，往往达到每秒上万次读写请求，对于传统关系型数据库来说，硬盘I/O是一个很大的瓶颈，并且很难能做到数据的强一致性。
海量数据的读写性能低：网站每天产生的数据量是巨大的，对于关系型数据库来说，在一张包含海量数据的表中查询，效率是非常低的。
扩展性和可用性差：在基于web的结构当中，数据库是最难（但是可以）进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移。
非关系型数据库特点：
- 一般不支持ACID特性，无需经过SQL解析，读写性能高
- 存储格式：key value，文档，图片等等
- 数据没有耦合性，容易扩展
Hbase数据模型
- ROWKEY：决定一行数据，按字典顺序排序
- ColumnFamily列族：作为表结构的一部分，必须在建表时给出，一个列族可以包含多个列，不同列族在存储时占用不同的store。
- Qulifier列：为列族的子单元，由实际的业务场景需要决定
- Cell单元格：为行与列的交叉所决定，内容为具体的数据，以字节数组的形式存放，单元格是有版本的
- Timestamp时间戳：根据时间戳区分单元格每个版本的差异，类型为64位整型
- HLog：HLog SequeceFile的Value是HBase的KeyValue对象，即对应HFile中的KeyValue。存储hbase表的操作记录，KV数据信息
Hbase体系架构
Client：包含访问HBase的接口并维护cache来加快对HBase的访问。
HMaster：与RegionServer为一主多从架构，存在单点故障问题，一般设置多个HMaster，由Zookeeper提供协同服务。HMaster负责为RegionServer的负载均衡，管理用户对表的增删改操作，发现失效的RegionServer并重新分配其上的region。
Zookeeper：存储Hbase数据库中表的元数据信息metadata，为HMaster提供协同服务，存储所有region的寻址入口信息，Hbase高度依赖ZK。
RegionServer：负责维护region，处理对region的I/O请求。负责对过大region的切分。
HLog：在RegionServer中，存储表的元数据metadata与实际数据data，数据先存储在HLog后存储进region。
Region：存储在RegionServer中，表被划分为多个区域，存储在不同的region中，region超过一定大小就会裂变。
Store：一个region由多个store组成，一个store对应一个列族，包括MemStore和StoreFile。MemStore在内存中，StoreFile在磁盘中。数据先写入MemStore，达到某个阈值后落地到StoreFile。
Region裂变机制
当Region中所有的storefile大小之和过大，超过一定的阈值，就会发生裂变。
一张表可能很大，在表增大的过程中，存储表的Region会裂变成2个，当table中的行不断增多，就会有越来越多的region，一个RegionServer有过多的Region后，下一次裂变时Master会将分裂后的Region放到不同的RegionServer上存储，实现负载均衡。
Hbase强依赖于Zookeeper
Hbase表的元数据metadata存储在zookeeper中，而zookeeper还负责master的协同服务以及region入口地址的存储，如果zookeeper出现问题，hbase将无法正常工作。
Hbase的优化
- 采用预分区的方式，解决热点问题，预先定义几个分区region，用startkey和endkey区间界定，存储数据时不同的rowkey直接进入所属的分区。
- rowkey的设计符合规则：定长、唯一、符合业务逻辑、具有散列性
- 尽量不要设计超过3个列族（最好1个）
- 创建表的时候将inmemory设置为true，保证查询时能被cache命中
- 控制版本数量，如没有特殊需求maxVersions设置为1
- 设置TimeToLive生命周期，没有需求尽量设短
- 控制合并和裂变的过程，使其少占资源
- 写表操作可以通过设置多个Table并发写，多个线程并发写，最有效的办法是使用MapReduce任务确保任务并行。
- 同样读表操作也可以通过设置多个Table，多线程并发读，同样利用MapReduce保证并行。
- 利用BlockCache，设置更大的BlockCache占用内存比率可以增加读取时缓存的命中率