首页 » NoSQL » HBase 索引表结构

HBase 索引表结构

原文 http://blog.csdn.net/Thousa_Ho/article/details/78901639

2017-12-27 02:01:39阅读(458)

1. 索引表的结构

HBase中,表格的Rowkey按照字典排序,Region按照RowKey设置split point进行shard,通过这种方式实现的全局、分布式索引,成为了其成功的最大的砝码

每一个索引建立一个表,然后依靠表的row key来实现范围检索。row key在HBase中是以B+ tree结构化有序存储的,所以scan起来会比较效率。
单表以row key存储索引,column value存储id值或其他数据 ,这就是Hbase索引表的结构。

Hbase QualifierFilter用于过滤qualifier,也就是一个列族里面data:xxx,冒号后面的字符串

2.RowKey的设计

大数据最好从rowkey入手,ColumnValueFilter的数度是很慢的,hbase查询速度还是要依靠rowkey,所以根据业务逻辑把rowkey设计好,之后所有的查询都通过rowkey,是会非常快。 批量查询最好是用 scan的startkey endkey来做查询条件

rowkey是hbase中很重要的一个设计,如果你把它当成普通字段那你的设计就有点失败了。它的设计可以说是一门艺术。你的查询如果不能把rowkey加入进来,那你的设计基本是失败的。加上rowkey,hbase可以快速地定位到具体的region去取你要的数据,否则就会满上遍野的找数据。

设计原则:

1.长度越短越好

Rowkey是一个二进制码流,Rowkey的长度被很多开发者建议说设计在10~100个字节,不过建议是越短越好,不要超过16个字节。

原因如下:

(1)数据的持久化文件HFile中是按照KeyValue存储的,如果Rowkey过长比如100个字节,1000万列数据光Rowkey就要占用100*1000万=10亿个字节,将近1G数据,这会极大影响HFile的存储效率;

(2)MemStore将缓存部分数据到内存,如果Rowkey字段过长内存的有效利用率会降低,系统将无法缓存更多的数据,这会降低检索效率。因此Rowkey的字节长度越短越好。

(3)目前操作系统是都是64位系统,内存8字节对齐。控制在16个字节,8字节的整数倍利用操作系统的最佳特性。

2.散列原则

如果Rowkey是按时间戳的方式递增,不要将时间放在二进制码的前面,建议将Rowkey的高位作为散列字段,由程序循环生成,低位放时间字段,这样将提高数据均衡分布在每个Regionserver实现负载均衡的几率。如果没有散列字段,首字段直接是时间信息将产生所有新数据都在一个 RegionServer上堆积的热点现象,这样在做数据检索的时候负载将会集中在个别RegionServer,降低查询效率。

3.唯一性

HBase按照指定条件获取一批记录时,使用的就是scan方法。scan方法有以下特点:

(1)scan可以通过setCaching与setBatch方法提高速度(以空间换时间);
(2)scan可以通过setStartRow与setEndRow来限定范围。范围越小,性能越高。
通过巧妙的RowKey设计使我们批量获取记录集合中的元素挨在一起(应该在同一个Region下),可以在遍历结果时获得很好的性能。
(3)scan可以通过setFilter方法添加过滤器,这也是分页、多条件查询的基础。

设计RowKey时可以这样做:采用UserID+CreateTime+FileId组成RowKey

需要注意以下几点:

(1)每条记录的RowKey,每个字段都需要填充到相同长度。假如预期我们最多有10万量级的用户,则userID应该统一填充至6位,如000001,000002…

(2)结尾添加全局唯一的FileID的用意也是使每个文件对应的记录全局唯一。避免当UserID与CreateTime相同时的两个不同文件记录相互覆盖。

3.HBase的二级索引

HBase在0.92之后引入了coprocessors,提供了一系列的钩子,能够轻易实现访问控制和二级索引的特性。下面介绍两种coprocessors,第一种是Observers,实际类似于触发器。第二种是EndPoint,类似存储过程。

observers分为三种:

RegionObserver:提供数据操作事件钩子 WALObserver:提供WAL相关操作事件钩子 MasterObserver:提供DDL操作事件钩子

在二级索引的实现技术上一般有几个方案:

1.表索引

使用单独的Hbase表存储索引数据,业务表的索引列值做为索引表的rowkey,业务表的rowkey做为索引表的qualifier或value。

问题:对数据更新性能影响较大;无法保证一致性;Client查询需要2次RPC(先索引表再数据表)。

2.列索引

与业务表使用相同表,使用单独列族存储索引,用户数据列值做为索引列族的Qualifier,用户数据Qualifier做为索引列族的列值。适用于单行有上百万Qualifier的数据模型,如网盘应用中网盘ID做为rowkey,网盘的目录元数据都存储在一个hbase row内。(facebook消息模型也是此方案)

可保证事务性

为了实现像SQL一样检索数据,select * from table where col=val。针对HBase Secondary Indexing的方案,成为HBase新版本(0.96)呼声最高的一项Feature。

粗略分析了当前的技术,大概的方案可以总结为这样两类:

1.使用HBase的coprocessor。CoProcessor相当于HBase的Observer+hook,目前支持MasterObserver、RegionObserver和WALObserver,基本上对于HBase Table的管理、数据的Put、Delete、Get等操作都可以找到对应的pre***和post***。这样如果需要对于某一项Column建立Secondary Indexing,就可以在Put、Delete的时候,将其信息更新到另外一张索引表中。如图二所示,对于Indexing里面的value值是否存储的问题,可以根据需要进行控制,如果value的空间开销不大,逆向的检索又比较频繁,可以直接存储在Indexing Table

HBase 索引表结构

2.由客户端发起对于主表和索引表的Put和Delete操作的双重操作

它具体的做法总结起来有:

设置主表的TTL(Time To Live)比索引表小一点,让其略早一点消亡。 不要在IndexingTable中存储Value值。 Put操作的时候,对于操作的主表的所有列,使用同一的Local TimeStamp的值,更新到Indexing Table,然后使用该TimeStamp插入主表数据。 Delete操作时,首先操作主表的数据,然后再去更新Indexing Table的数据。

虽然在这种方案里无法保证原子性和一致性,但是通过TimeStamp的设置,No Locks和 No Server-side codes,使其在二级索引上有着较大的优势。至于中间出错的环节,我们看看是否可以容忍:

1)Put索引表成功,Put主表失败。由于Indexing Table不存储val值,仍需要跳转到Main Table,所以这样的错误相当于拿一个Stale index去访问对应Rowkey吧了,对结果正确性没有影响。

2)Delete主表成功,Delete索引表失败。都是索引表的内容>=主表的内容而已,而实际返回值需要通过主表进行。

应用场景:

1、主表服务在线业务,它的性能需要保证。使用coprocessor和客户端的封装也好,都会影响其性能,所以在正常情况下,直接操作都不太合适。如果想使用方案二,我倒是感觉,可以调整Indexing Table的操作方式,去除保证其安全性的内容,比如可以关闭写HLOG,这样会进一步减低其操作的延迟。

2、离线更新索引表。在真正需要二级索引的场景内,其时效性要求往往不高。可以将索引实时更新到Redis等KV系统中,定时从KV更新索引到Hbase的Indexing Table中。PS:Redis里面有DB设置的概念,可以按照时间段进行隔离,这样某段时间内的数据会更新到Redis上,保证Redis导入MapReduce之后仍然可以进行update操作。

最新发布

CentOS专题

关于本站

5ibc.net旗下博客站精品博文小部分原创、大部分从互联网收集整理。尊重作者版权、传播精品博文,让更多编程爱好者知晓!

小提示

按 Ctrl+D 键,
把本文加入收藏夹