HBase介绍
Hbase源于google的BigTable,建立在hdfs之上,提供高可靠性、高性能、列存储、可伸缩、实时读写的数据库系统。有以下特点:
大:一个表可以有上亿行,上百万列
面向列:面向列族的存储,列族独立检索
稀疏:对于空(null)的列,不占用存储空间
存储
Hbase 以表的形式存储数据,表结构如下
在物理存储中的一条记录如下:
<row,column family,column,timestamp >:<value>
记录按照row key排序,每插入一条会生成本条记录的时间戳(update)。Table中的所有行都按照row key的字典序排列,在行的方向上分割为多个Hregion。
Region按大小分割的,每个表一开始只有一个region,随着数据不断插入表,region不断增大,当增大到一个阀值时候,Hregion就会等分成两个新的Hregion。Hregion是Hbase中分布式存储和负载均衡的最小单元。最小单元就表示不同的Hregion可以分步在不同的Hregion server上。但一个Hregion是不会拆分到多个server上的。
Hregion虽然是分布式存储的最小单元,但并不是存储的最小单元。在下层还有Store,而Store以Hfile的格式保存在HDFS上。
架构
Client
访问hbase的借口,维护着region位置的缓存信息
Zookeeper
保证任何时候,集群中只有一个master;
存储所有Region的寻址入口;
实时监控region server的状态。将上下线信息通知master;
存储hbase的schema,包括有哪些table,每个table有哪些column family
Master
为Region server分配region;
负载region server的负载均衡;
发现失效的region server并重新分配其上的region;
GFS上的垃圾文件回收;
处理schema更新请求
Region Server
维护master分配给它的region,处理IO请求;
负责切分过大的region,可以看到client访问hbase上数据的过程并不需要master参与
问题背景
HBase的表数据按RowKey进行字典排序, RowKey实际上是数据表的一级索引(Primary Index),由于HBase本身没有二级索引(Secondary Index)机制,基于索引检索数据只能单纯地依靠RowKey,为了能支持多条件查询,开发者需要将所有可能作为查询条件的字段一一拼接到RowKey中
基本思想
针对目标记录的某个或某些列建立的“键-值”数据,以列的值为键,以记录的RowKey为值,当以这些列为条件进行查询时,引擎可以通过检索相应的“键-值”数据快速找到目标记录
一种解决办法
将主数据和索引放在一张表里,给索引和主数据添加特别设计的Hash前缀,当Region切分时,索引和主数据划分在同一Region中。
当全体数据按照RowKey排序时,排在前面的时候索引,排在后面的主数据。
给索引和主数据分配不同的Column Family,在物理存储上将它们隔离,降低维护的复杂性