标签：检索 专场 场景 查询 rowkey HBase Solr hbase

HBase检索能力增强思路

(1)HBase

主表一个rowkey，只能设计一个rowkey=X|Y这种场景。

合适场景：

• X=a

• X>=a, X>a

• X<=a,或者X<a

• X=a and Y = b

• X=a and Y <= b

• X=a and Y>=b

优点：

• 高并发、高效快速

缺点：

• 只有一个rowkey设计，后期业务变化不不能修改rowkey结构

• 检索场景简单，有局限性，一个rowkey必须由前缀X出现才能快速查找，比如上述只提供Y=b的话，依然需要全表扫描

(2)Phoenix/自建HBase索引

扩展更多rowkey设计，允许更多rowkey=X|Y rowkey=Y|Z rowkey=X|Z等这种设计。

合适场景：

• 一个表，允许更更多类似左边的场景

• 更多X、Y、Z...条件来组合来进⾏行行

• 类似左边描述的条件查询

优点：

• 依然保持高并发、高效rowkey查询。允许有更多rowkey设计，最大化hbase rowkey检索优势

缺点：

• 表变多，如果业务有U/V/W/X/Y/Z 6个条件两两组合的业务场景，就需要15个表，数据膨胀，例如这个时候，X在索引⾥里里被保存了5次

• 查询也有局限性

(3)Solr/ES

任意条件 X、Y、Z。

合适场景：

• X = a or Y= b (rowkey设计不不能实现的)

• X> a and Y < b (rowkey设计不不能实现的)

• X like “%hbase%”

• Geo地理距离检索

• 支持分词查询

• 支持facet/group分类分组查询返回，例如一个关键词搜索新闻网站，它可以分政治、体育、经济等类别返回统计与结果

• 任意条件组合查询等

优点：

• 支持检索功能更丰富； OR 组合查询，多个条件范围组合查询，like、分词等全文检索，这些查询使用hbase rowkey设计是难以满足的

• 对于类似U/V/W/X/Y/Z 6个条件两两组合的业务场景,数据膨胀率远低于 hbase的rowkey方案

缺点：

• 类似hbase这种简单kv查询下，并发不如hbase高效快速

HBase for Solr介绍

HBase rowkey查询已经不能满足复杂多变的用户业务查询需求，HBase for Solr就是为了满足广大HBase用户日益变化的查询需求，是HBase查询检索能力的补充，是大数据多模式数据库发展趋势的基础之一，比如一些图、时空等应用，都可以使用solr提供的索引服务。

标签：检索,专场,场景,查询,rowkey,HBase,Solr,hbase
来源： https://blog.51cto.com/15060465/2679315

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。