HBase在0.92之后引入了coprocessors,提供了一系列的钩子,让我们能够轻易实现访问控制和二级索引的特性.下面简单介绍下两种coprocessors,第一种是Observers,它实际类似于触发器,第二种是Endpoint,它类似与存储过程.由于这里只用到了Observers,所以只介绍Observers,想要更详细的介绍请查阅(https://blogs.apache.org/hbase/entry/coprocessor_introduction).observers分为三种:

一.协处理器—Coprocessor 1. 起源Hbase 作为列族数据库最经常被人诟病的特性包括:无法轻易建立“二级索引”,难以执 行求和.计数.排序等操作.比如,在旧版本的(<0.92)Hbase 中,统计数据表的总行数,需 要使用 Counter 方法,执行一次 MapReduce Job 才能得到.虽然 HBase 在数据存储层中集成了 MapReduce,能够有效用于数据表的分布式计算.然而在很多情况下,做一些简单的相 加或者聚合计算的时候, 如果直接将计算过程放置在 server 端

一. 已知的问题和不足二.解决思路三.代码3.1 读取config文件内容3.2 封装SolrServer的获取方式3.3 编写提交数据到Solr的代码3.4 拦截HBase的Put和Delete操作信息四. 使用 一. 已知的问题和不足 在上一个版本中,实现了使用HBase的协处理器将HBase的二级索引同步到Solr中,但是仍旧有几个缺陷: 写入Solr的Collection是写死在代码里面,且是唯一的.如果我们有一张表的数据希望将不同的字段同步到Solr中该如何做呢? 目前所有配置相关信息

一. 背景二. 什么是HBase的协处理器三. HBase协处理器同步数据到Solr四. 添加协处理器五. 测试六. 协处理器动态加载 一. 背景 在实际生产中,HBase往往不能满足多维度分析,我们能想到的办法就是通过创建HBase数据的二级索引来快速获取rowkey,从而得到想要的数据.目前比较流行的二级索引解决方案有Lily HBase Indexer,Phoenix自带的二级索引,华为Indexer,以及360的二级索引方案.上面的目前使用比较广泛的应该是Lily HBase Index

情况描述:在MySQL的user表中,对a,b,c三个字段建立联合索引,那么查询时使用其中的2个作为查询条件,是否还会走索引? 根据查询字段的位置不同来决定,如查询a,     a,b    a,b,c    a,c   都可以走索引的,其他条件的查询不能走索引. 组合索引 有“最左前缀”原则.就是只从最左面的开始组合,并不是所有只要含有这三列存在的字段的查询都会用到该组合索引. 验证过程如下所示: 首先,在SQLyog中建立一个user表,如下图所示: 对中间3个字段(user_name,us

环境描述: 操作系统版本:CentOS release 6.5 (Final) 内核版本:2.6.32-431.el6.x86_64 phoenix版本:phoenix-4.10.0 hbase版本:hbase-1.2.6 hbase节点分布:1个HMaster,2个RegionServer 文档目的: 通过在phoenix客户端连接hbase数据库,在phoenix中创建二级索引. 配置过程: 1.登录到RegionSever节点,修改hbase-site.xml配置文件,加入如下配置 <pr

HBase的一级索引就是rowkey,我们仅仅能通过rowkey进行检索. 假设我们相对hbase里面列族的列列进行一些组合查询.就须要採用HBase的二级索引方案来进行多条件的查询. 常见的二级索引方案有下面几种: 1.MapReduce方案 2.ITHBASE方案 3.IHBASE方案 4.Coprocessor方案 5.Solr+hbase方案 MapReduce方案 IndexBuilder:利用MR的方式构建Index 长处:并发批量构建Index 缺点:不能实时构建Index 举例:

我们会经常谈及二级索引,这是对全表数据进行另外一种方式的组织存储,是针对table级别的.如果要为HBase上的表实现一个强一致性的二级索引,那么就无法逃避分布式事务,而这一直是用户最期待的功能. 而即使只需要保证最终一致性,这个索引也并不好实现,因为你需要额外的表以存储过程数据,需要解决宕机恢复问题等 撇开分布式事务,我们是否可以考虑对索引的要求进行降级,比如把Region看成是全表下的子表,实现一套Region级别的索引,通过功能上的牺牲以换取实现的简易及稳定. 在某些存在用户概念的场景下,

之前的环境是单独下载的CDH组件包搭建的集群,但是因为hadoop版本过低导致漏洞无法修复,重新搭建高版本集群环境. 新集群环境: 主要组件:hadoop,hbase,zookeeper,Key-Value Store Indexer 1.创建hbase表: hbase shell create 'users', { NAME => 'info', REPLICATION_SCOPE => '1' } 2.使用CDH创建solr集合并修改配置: 1)创建solr实体配置文件本地目录,tsolr

Coprocessor简介 (1)实现目的 HBase无法轻易建立“二级索引”: 执行求和.计数.排序等操作比较困难,必须通过MapReduce/Spark实现,对于简单的统计或聚合计算时,可能会因为网络与IO开销大而带来性能问题. (2)灵感来源          灵感来源于Bigtable的协处理器,包含如下特性: 每个表服务器的任意子表都可以运行代码: 客户端能够直接访问数据表的行,多行读写会自动分片成多个并行的RPC调用. (3)提供接口 RegionObserver:提供客户端的数据操

使用HBase存储中国好声音数据的案例,业务描述如下: 为了能高效的查询到我们需要的数据,我们在RowKey的设计上下了不少功夫,因为过滤RowKey或者根据RowKey查询数据的效率是最高的,我们的RowKey的设计是:UserID + CreateTime + FileID,那么我们在HBase中的数据格式如下: 每一行数据中包含两个Column:f:c和f:n 我们在查询的时候还是用了SingleColumnValueFilter这个Filter来过滤单个的Column的Value的值,我

HBase二级索引.读写流程 一.HBse二级索引方案 1.1 基于Coprocessor方案 1.2 Phoenix二级索引特点 1.3 Phoenix 二级索引方案 二.HBase读写流程 2.1 HBase写数据流程 2.2 HBase读数据流程 相关优秀博文案例: 博客园:花未全开*月未圆:HBase的二级索引 博客园:small_k:hbase实践之协处理器Coprocessor 简书:5c7b85ab9023:Hbase使用Coprocessor构建二级索引 CSDN:菜鸟级的IT之

HBase学习(四) 一.HBase的读写流程 画出架构 1.1 HBase读流程 Hbase读取数据的流程:1)是由客户端发起读取数据的请求,首先会与zookeeper建立连接2)从zookeeper中获取一个hbase:meta表位置信息,被哪一个regionserver所管理着     hbase:meta表:hbase的元数据表,在这个表中存储了自定义表相关的元数据,包括表名,表有哪些列簇,表有哪些reguion,每个region存储的位置,每个region被哪个regionserver

转自:http://blog.sina.com.cn/s/blog_4a1f59bf01018apd.html 附hbase如何创建二级索引以及创建二级索引实例:http://www.aboutyun.com/thread-8857-1-1.html 华为二级索引(原理):http://my.oschina.net/u/923508/blog/413129 在HBase中,表格的Rowkey按照字典排序,Region按照RowKey设置split point进行shard,通过这种方式实现的全局

一.概述 Hbase适用于大表的存储,通过单一的RowKey查询虽然能快速查询,但是对于复杂查询,尤其分页.查询总数等,实现方案浪费计算资源,所以可以针对hbase数据创建二级索引(Hbase Secondary Indexing),供复杂查询使用. Solr是一个高性能,采用Java5开发,基于Lucene的全文搜索服务器.同时对其进行了扩展,提供了比Lucene更为丰富的查询语言,同时实现了可配置.可扩展并对查询性能进行了优化,并且提供了一个完善的功能管理界面,是一款非常优秀的全文搜索引擎.

一.简述 Hbase 作为列族数据库最经常被人诟病的特性包括:无法轻易建立"二级索引",难以执 行求和.计数.排序等操作.比如,在旧版本的(<0.92)Hbase 中,统计数据表的总行数,需 要使用 Counter 方法,执行一次 MapReduce Job 才能得到.虽然 HBase 在数据存储层中集成 了 MapReduce,能够有效用于数据表的分布式计算.然而在很多情况下,做一些简单的相 加或者聚合计算的时候,如果直接将计算过程放置在 server 端,能够减少通讯开销,从

Phoenix创建Hbase二级索引 官方文档 1. 配置Hbase支持Phoenix创建二级索引   1.  添加如下配置到Hbase的Hregionserver节点的hbase-site.xml  <!-- phoenix regionserver 配置参数 --> <property> <name>hbase.regionserver.wal.codec</name> <value>org.apache.hadoop.hbase.regio

摘要 HBase只提供了一个基于字典排序的主键索引,在查询中你只能通过行键查询或扫描全表来获取数据,使用Phoenix提供的二级索引,可以避免在查询数据时全表扫描,提高查过性能,提升查询效率   测试环境: 数据约370万 数据格式:(数据来自搜狗实验室) 三节点集群(一主两从,hadoop和HBase属同一集群)   目录 Covered Indexes(覆盖索引) Functional indexes(函数索引) Global indexes(全局索引) Local indexes(本地索引

上一篇介绍了Phoenix基于HBase的二级索引的基本知识,这一篇介绍一下和索引相关的一致性和优化相关内容. 一致性的保证 Phoenix客户端在成功提交一个操作并且得到成功响应后,就代表你所做的操作已经成功应用到原表和相关的索引表中.换句话说,索引表的维护和处理原表数据是同步的,并且各自是强一致性保证的.但是因为索引表和原表是在不同的表中,根据表的属性和索引的类型,当服务端崩溃导致一次提交失败时,原表和索引表中的数据就会有一些变化.所以在使用二级索引的时候,就要根据需求个用例充分考虑. 下面

索引永远是最好的查询解决方案嘛? 索引并不总是最好的工具.总的来说,只有当索引帮助存储引擎快速查找到记录带来的好处大于其带来的额外工作(比如插入操作后索引的维护)时,索引才是高效的. 对于非常小的表:大部分情况下简单的全表扫描更高效. 中到大型表:索引非常高效. 特大型表:建立和使用索引的代价非常高,可以使用分库分表或分区技术代替. 高性能的索引策略 索引的选择性越高则查询效率越高 因为选择性高的索引可以让MySQL在查找时过滤掉更多的行.唯一索引的选择性是1,这是最好的索引选择性,性能也是最好