首先要回答一个问题,为何要使用HBase? 随着业务不断发展.数据量不断增大,MySQL数据库存在这些问题: MySQL支持的数据量为TB级,不能一直保留历史数据.而HBase支持的数据量为PB级,适合存储久远的历史冷数据 新增列的代价较高,数据量越大耗费时间越长.而HBase可以随意增加列,空列不占据空间,业务模型可以灵活变化 要使用HBase,最重要的一点是rowkey行键设计,如果设计不妥,后续要改的代价非常大. HBase行键设计原则 下面列几个HBase rowkey设计的原则: 组合

比较常用的数据库是关系型数据库,但很多场景下nosql数据库会更加擅长,从sql到nosql实施的第一步就是设计表结构,这是两种不同的思维方式,这里说下HBase表设计. 需求:需要一张stock表用于保存市场所有股票的分钟走向,即每个股票每分钟记录一次价格. 方案一:瘦表. 用stockId+datetime作为RowKey,这样方便通过stockId或datetime快速扫描获取到相关记录. RowKey ColumnFamily "stock_cf" stockId+dateti

为什么Rowkey这么重要 RowKey 到底是什么 我们常说看一张 HBase 表设计的好不好,就看它的 RowKey 设计的好不好.可见 RowKey 在 HBase 中的地位.那么 RowKey 到底是什么?RowKey 的特点如下: 类似于 MySQL.Oracle中的主键,用于标示唯一的行: 完全是由用户指定的一串不重复的字符串: HBase 中的数据永远是根据 Rowkey 的字典排序来排序的. RowKey的作用 读写数据时通过 RowKey 找到对应的 Region: MemSt

环境 虚拟机:VMware 10 Linux版本:CentOS-6.5-x86_64 客户端:Xshell4 FTP:Xftp4 jdk8 hadoop-2.6.5 hbase-0.98.12.1-hadoop2 HBase中表的设计 主要是将原来的关系解开 问题: 例子: 表设计一: 表设计二: 这是一个双向查询,根据人员查角色,根据角色查人员 问题: 0为顶级部门,1为子部门 放到一张表中不会对效率产生影响,因为HBASE是海量存储,海量读写的. Redis是一个内存数据库,新浪微博是使用R

为啥要把表设计拿出来独立成章?因为我觉得像我这样搞了很多年Java后端开发的技术人员,在学习HBase的时候,会受到关系型数据库3NF.BCNF的影响.事实上,数据库范式在HBase里完全没用,必须转变思想.因此把这一点单独写出来,供类似情况的技术人员参考. HBase逻辑视图 这个图看起来像是Excel表格,不同的是,它的一个单元格可以有多个版本的数据,这是HBase的多版本特性,默认版本数是1.实际存储格式是每个单元格一行记录,如下图. hbase(main):003:0> scan 'te

摘要:本篇是本人在做一个大数据项目时,对于系统架构的一点总结,如何在保证存储量的情况下,又能保证数据的检索速度. 前提:      Solr.SolrCloud提供了一整套的数据检索方案,HBase提供了完善的大数据存储机制.需求:      1.对于添加到HBase中的结构化数据,能够检索出来.             2.数据量较大,达到10亿,100亿数据量.             3.检索的实时性要求较高,秒级更新. 说明:      以下是使用Solr和HBase共同搭建的系统架构.

导语:本文介绍的项目主要解决 check 和 opinion2 张历史数据表(历史数据是指当业务发生过程中的完整中间流程和结果数据)的在线查询.原实现基于 Oracle 提供存储查询服务,随着数据量的不断增加,在写入和读取过程中面临性能问题,且历史数据仅供业务查询参考,并不影响实际流程,从系统结构上来说,放在业务链条上游比较重.该项目将其置于下游数据处理 Hadoop 分布式平台来实现此需求. 背景介绍 本项目主要解决 check 和 opinion2 张历史数据表(历史数据是指当业务发生过程中

1. 表的设计 1.1 Pre-Creating Regions 默认情况下,在创建HBase表的时候会自动创建一个region分区,当导入数据的时候,所有的HBase客户端都向这一个region写数据,直到这 个region足够大了才进行切分.一种可以加快批量写入速度的方法是通过预先创建一些空的regions,这样当数据写入HBase时,会按照 region分区情况,在集群内做数据的负载均衡. 预分区的一个例子: public static boolean createTable(HBaseA

1.建表高级属性 建表过程中常用的shell命令 1.1 BLOOMFILTER 默认是 NONE 是否使用布隆过虑及使用何种方式,布隆过滤可以每列族单独启用 使用HColumnDescriptor.setBloomFilterType(NONE|ROW|ROWCOL)对列族单独启用布隆 - Default = ROW 对行进行布隆过滤 - 对 ROW,行键的哈希在每次插入行时将被添加到布隆 - 对 ROWCOL,行键 + 列族 + 列族修饰的哈希将在每次插入行时添加到布隆 使用方法: crea

Rowkey设计 Rowkey设计原则 Rowkey设计应遵循以下原则: 1.Rowkey的唯一原则 必须在设计上保证其唯一性.由于在HBase中数据存储是Key-Value形式,若HBase中同一表插入相同Rowkey,则原先的数据会被覆盖掉(如果表的version设置为1的话),所以务必保证Rowkey的唯一性 2. Rowkey的排序原则 HBase的Rowkey是按照ASCII有序设计的,我们在设计Rowkey时要充分利用这点.比如视频网站上对影片<泰坦尼克号>的弹幕信息,这个弹幕是按

转自 http://blog.csdn.net/lifuxiangcaohui/article/details/40621067 hbase所谓的三维有序存储的三维是指:rowkey(行主键),column key(columnFamily+qualifier),timestamp(时间戳)三部分组成的三维有序存储. 1.rowkey,我们知道rowkey是行的主键,而且hbase只能用个rowkey,或者一个rowkey范围即scan来查找数据.所以 rowkey的设计是至关重要的,关系到你应

转自:http://www.bcmeng.com/hbase-rowkey/ 建立Schema Hbase 模式建立或更新可以通过 Hbase shell 工具或者使用Hbase Java API 中的 Admin类. 当列族发生变动时 hbase表必须处于 disabled 状态.例如:   Configuration config = HBaseConfiguration.create(); Admin admin = new Admin(conf); String table = "myT

Rowkey设计 Region: 基于RowKey的分区,可理解成MySQL的水平切分. 每个Region Server就是Hadoop集群中一台机器上的一个进程. 比如我们的有1-300号的RowKey, 那么1-100号RowKey的行被分配到Region Server 1上,同样,101-200号分配到Region Server 2上, 201-300号分配到Region Server 3上. 在内存模型中,我们说RowKey保证了相邻RowKey的记录被连续地写入了磁盘.在这里,我们发现

hbase所谓的三维有序存储的三维是指:rowkey(行主键),column key(columnFamily+qualifier),timestamp(时间戳)三部分组成的三维有序存储. 1.rowkey.我们知道rowkey是行的主键,并且hbase仅仅能用个rowkey,或者一个rowkey范围即scan来查找数据.所以 rowkey的设计是至关重要的,关系到你应用层的查询效率.我们知道.rowkey是以字典顺序排序的.而存储的字节码,字典排序,我们知道,假设是字 母,那就是字母的顺序,比

背景介绍 本项目主要解决 check 和 opinion2 张历史数据表(历史数据是指当业务发生过程中的完整中间流程和结果数据)的在线查询.原实现基于 Oracle 提供存储查询服务,随着数据量的不断增加,在写入和读取过程中面临性能问题,且历史数据仅供业务查询参考,并不影响实际流程,从系统结构上来说,放在业务链条上游比较重.本项目将其置于下游数据处理 Hadoop 分布式平台来实现此需求.下面列一些具体的需求指标: 数据量:目前 check 表的累计数据量为 5000w+ 行,11GB:opin

HBase中的rowkey是按字典顺序排序的,通过rowkey查询可以对千万级的数据实现毫秒级响应.然而,如果rowkey设计不合理的话经常会出现一个很普遍的问题----热点.当大量client的请求(读或者写)只指向集群的一个节点,或者很少量的几个节点时,也就代表产生了热点问题. 避免产生热点的方式也就是尽可能的将rowkey均匀分散到所有的region上,下面介绍了几种rowkey设计常用的方式: 第一:加盐(salting) 加盐是指在rowkey的前缀添加随机数据,使rowkey尽可能的

hbase 数据获取方式 直接根据 rowkey 查找,速度最快 scan,指定 startrowkey.endrowkey 和 limit获取数据,在 rowkey 设计良好的情况下,效率也不错 全表扫,强烈不推荐这种做法,效率极差,在线业务不用考虑这种方式 hbase 数据排序怎么做? 我觉得这个分两种情况,一是数据量比较少,业务上每次拉取所有的数据,可以在客户端做排序,二是数据比较多,需要分页,这种情况下客户端做显然不合适,因为要从服务器拉取所有数据,排序完成,获取某一页,剩余的数据全都不

Hbase是三维有序存储的,通过rowkey(行键),column key(column family和qualifier)和TimeStamp(时间戳)这三个维度可以对HBase中的数据进行快速定位. Hbase中Rowkey可以唯一标识一行记录,在Hbase查询的时候,有以下几种方式: 1.通过get方式,指定rowkey获取唯一一条记录 2.通过scan方式,设置StartRow和EndRow参数进行范围匹配 3.全表扫描,即直接扫描整张表中所有行记录 Rowkey长度原则 rowkey是

充分利用有序性 1.1 如果要scan操作,且不是很频繁,可以利用rowkey的有序性将需要一起扫描的数据放到一起.例如直接用时间戳.这样就可以按时间scan了.这个只要是简单的全表扫描都行. 1.2 同样是scan,还可以利用rowkey的有序性实现数据本地化,设同一类别的数据需要一起扫描,那就可以给rowkey加一个类别前缀.(为了节约磁盘空间,需将类别名称编码) 这个不如垂直爬虫,我要扫描新闻类,或者BBS类,就可以为rowkey加个编码后的新闻,bbs类别id,实现同一类别的url本地化

一.Client 包含访问HBase的接口并维护cache来加快对HBase的访问. 二.Zookeeper 1.保证任何时候,集群中只有一个master. 2.存储所有Region的寻址入口. 3.实时监控Region server的上线和下线信息,并实时通知Master. 4.存储HBase的schema和table元数据. 三.Master 1.为Region server分配region. 2.负责Region server的负载均衡. 3.发现失效的Region server并重新分配

Hbase 概述 大数据及 NoSQL 的前世今生 传统的关系型数据库处理方式是基于全面的 ACID 保证,遵循 SQL92 的标准表设计模式(范式)和数据类型,基于 SQL 语言的 DML 数据交互方式.长期以来这种基于关系型数据库的 IT 信息化建设中发展良好,但受制于关系型数据库提供的数据模型,对于逐渐出现的,为预先定义模型的数据集,关系型数据库不能很好的工作.越来越多的业务系统需要能够适应不同种类的数据格式和数据源,不需要预先范式定义,经常是非结构化的或者半结构化的(如用户访问网站的日志