HBase索引总结

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为值，当以这些列为条件进行查询时，引擎可以通过检索相应的“键-值”数据快速找到目标记录

一种解决办法

1. 将主数据和索引放在一张表里，给索引和主数据添加特别设计的Hash前缀，当Region切分时，索引和主数据划分在同一Region中。

2. 当全体数据按照RowKey排序时，排在前面的时候索引，排在后面的主数据。

3. 给索引和主数据分配不同的Column Family，在物理存储上将它们隔离，降低维护的复杂性

   

参考文献

1. HBase高性能复杂条件查询引擎

2. HBase介绍-blog