HBase二级索引实践(带你感受二级索引的力量)

 hyper_table之前HBase SQL BulkLoad环节创建的,我们将数据通过BulkLoad方式导入预先分好Region的hyper_table表中。具体参考如下博文:

HBase中利用SQL BulkLoad快速导入数据

 

这里大家只要清楚此表结构即可,结构如下:

hyper_table表结构
字段rowkeynumcountryrd
类型stringintintstring


创建二级索引(全局索引)

我们有两种方式创建索引,一种是利用SQL通过Inceptor分布式SQL引擎与HBase交互,创建二级索引。另一种是直接在HBase shell中创建二级索引。两者创建时都需要指定索引的名字、索引所在表的名字、创建的索引列。

  • 在Inceptor中利用SQL创建二级索引:
-- 创建二级索引(全局索引)
create global index index_num on hyper_table(num);
  • 在HBase shell中创建二级索引:
add_index 'hyper_table','index_num','COMBINE_INDEX|INDEXED=f:q2:8|rowKey:rowKey:9'

 创建好的索引在Hbase中会以表的形式存在,表名为 "表名_索引名" ,如下所示:

 

rebuild二级索引

rebuild命令为生成索引的命令,他会在上一步生成的索引表中插入索引数据,生成二级索引。进入到HBase Shell,重构索引。(注:Inceptor目前不支持SQL生成索引,仅支持创建二级索引)

rebuild_global_index '{$yourDBName}:hyper_table', 'index_num';

 

可以看到,生成二级索引的过程 需要用到之前创建好的索引信息、表region信息。

 

底层是通过mapreduce任务生成的。

 

测试二级索引性能

1、精准查询性能:

不走索引:

select * from hyper_table where num=503;

走索引:

select /*+USE_INDEX(e USING index_num)*/ * from hyper_table e where num =503;

可以看到,num列走二级索引的情况下,精准查询的性能有明显提升。因为不走索引,HBase会从第一条记录开始遍历全表,而走索引,直接通过索引表查询到对应的num值即可。

 

2、范围查询性能: 

# 不走索引
select * from hyper_table where NUM>520 LIMIT 10;

# 走索引
select /*+USE_INDEX(e USING index_num)*/ * from hyper_table e where num >520 LIMIT 10;

 

注意:后来测试发现,虽然精准查询走二级索引效率明显提升,但如果是范围查询,则走二级索引效率反而更低,经过分析发现,在重构基于num列的二级索引(全局索引)时,会将num进行升序排序,故走不走索引查询时间大致相同,而不走索引直接访问原表省去了查询索引表的时间,故在范围查询情况下,不走索引效率更高。 

 

(补充1)何时会走索引?

Inceptor默认运行在Cluster Mode下,查询时不基于索引,因为对索引文件的访问可能会比较慢。在Cluster Mode下,只有明确声明(/*+USE_INDEX(e USING index_num)*/ *),Inceptor才基于索引进行查询。

如果我们将Inceptor切换为Local Mode,Inceptor自动匹配合适的索引进行查询。切换方式如下:

# 切换Inceptor模式为Local Mode
set ngmr.exec.mode=local;
set hyperbase.integer.transform=true;

切换回Cluster模式如下:

# 将Inceptor切换为Cluster Mode
set ngmr.exec.mode=cluster;

 

(补充2)无法创建二级索引的解决办法:

可能是因为名称冲突问题,解决方法删除原先二级索引,重新创建。

因为二级索引在HBase中也是以表的形式存在的,如之上的例子,hypet_table的num列的索引存在hyper_table_index_num表里,我们直接disable掉它,再drop掉,之后就能重新创建了(通过Inceptor中的SQL或者HBase shell皆可)。

# 下线二级索引表
disable 'hyper_table_index_num'
# 删除二级索引表
drop 'hyper_table_index_num'

 

 

 

  • 1
    点赞
  • 36
    收藏
    觉得还不错? 一键收藏
  • 6
    评论
概述 在 Hbase 中,表的 RowKey 按照字典排序, Region 按照 RowKey 设置 split point 进行 shard, 通过这种方式实现的全局、分布式索引. 成为了其成功的最大的砝码。 然而单一的通过 RowKey 检索数据的方式,不再满足更多的需求,查询成为 Hbase 的瓶颈,人 们更加希望像 Sql 一样快速检索数据,可是,Hbase 之前定位的是大表的存储,要进行这样 的查询,往往是要通过类似 Hive、Pig 等系统进行全表的 MapReduce 计算,这种方式既浪费 了机器的计算资源,又因高延迟使得应用黯然失色。于是,针对 HBase Secondary Indexing 的方案出现了。 Solr Solr 是一个独立的企业级搜索应用服务器,是 Apache Lucene 项目的开源企业搜索平台, 其主要功能包括全文检索、命中标示、分面搜索、动态聚类、数据库集成,以及富文本(如 Word、PDF)的处理。Solr 是高度可扩展的,并提供了分布式搜索和索引复制。Solr 4 还增 加了 NoSQL 支持,以及基于 Zookeeper 的分布式扩展功能 SolrCloud。SolrCloud 的说明可 以参看:SolrCloud 分布式部署。它的主要特性包括:高效、灵活的缓存功能,垂直搜索功 能,Solr 是一个高性能,采用 Java5 开发,基于 Lucene 的全文搜索服务器。同时对其进行 了扩展,提供了比 Lucene 更为丰富的查询语言,同时实现了可配置、可扩展并对查询性能 进行了优化,并且提供了一个完善的功能管理界面,是一款非常优秀的全文搜索引擎。 Solr 可以高亮显示搜索结果,通过索引复制来提高可用,性,提供一套强大 Data Schema 来定义字段,类型和设置文本分析,提供基于 Web 的管理界面等。 Key-Value Store Indexer 这个组件非常关键,是 Hbase 到 Solr 生成索引的中间工具。 在 CDH5.3.2 中的 Key-Value Indexer 使用的是 Lily HBase NRT Indexer 服务. Lily HBase Indexer 是一款灵活的、可扩展的、高容错的、事务性的,并且近实时的处理 HBase索引数据的分布式服务软件。它是 NGDATA 公司开发的 Lily 系统的一部分,已开放 源代码。Lily HBase Indexer 使用 SolrCloud 来存储 HBase索引数据,当 HBase 执行写 入、更新或删除操作时,Indexer 通过 HBase 的 replication 功能来把这些操作抽象成一系 列的 Event 事件,并用来保证写入 Solr 中的 HBase 索引数据的一致性。并且 Indexer 支持 用户自定义的抽取,转换规则来索引 HBase 列数据。Solr 搜索结果会包含用户自定义的 columnfamily:qualifier 字段结果,这样应用程序就可以直接访问 HBase 的列数据。而且 Indexer 索引和搜索不会影响 HBase 运行的稳定性和 HBase 数据写入的吞吐量,因为索引和 搜索过程是完全分开并且异步的。Lily HBase Indexer 在 CDH5 中运行必须依赖 HBase、 SolrCloud 和 Zookeeper 服务。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 6
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值