首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

Phoenix快速入门系列(3) | 一文教你如何在Phoenix中创建 HBase 二级索引

在前面的学习中, 我们知道 HBase 只能通过 rowkey 进行搜索, 一般把 rowkey 称作一级索引. 在很长的一段时间里 HBase 就只支持一级索引.   HBase 里面只有 rowkey 作为一级索引, 如果要对库里的非 rowkey 字段进行数据检索和查询, 往往要通过 MapReduce/Spark 等分布式计算框架进行,硬件资源消耗和时间延迟都会比较高。   为了 HBase 的数据查询更高效、适应更多的场景, 诸如使用非 rowkey 字段检索也能做到秒级响应,或者支持各个字段进行模糊查询和多字段组合查询等, 因此需要在 HBase 上面构建二级索引, 以满足现实中更复杂多样的业务需求。   从 0.94 版本开始, HBase 开始支持二级索引.   HBase 索引有多种放方案, 我们今天要做的是使用 Phoenix 给 HBase 添加二级索引.

01

Hbase基础命令

我们可以以shell的方式来维护和管理HBase。例如:执行建表语句、执行增删改查操作等等。 4.1 需求 有以下订单数据,我们想要将这样的一些数据保存到HBase中。 订单ID 订单状态 支付金额 支付方式ID 用户ID 操作时间 商品分类 001 已付款 200.5 1 001 2020-5-2 18:08:53 手机; 接下来,我们将使用HBase shell来进行以下操作: 1.创建表 2.添加数据 3.更新数据 4.删除数据 5.查询数据 4.2 创建表 在HBase中,所有的数据也都是保存在表中的。要将订单数据保存到HBase中,首先需要将表创建出来。 4.2.1 启动HBase Shell HBase的shell其实JRuby的IRB(交互式的Ruby),但在其中添加了一些HBase的命令。 启动HBase shell: hbase shell 4.2.2 创建表

02

【DB】HBase的基本概念

一 Hbase是个啥东东? 在说Hase是个啥家伙之前,首先我们来看看两个概念。面向行存储和面向列存储。面向行存储。我相信大伙儿应该都清楚,我们熟悉的RDBMS就是此种类型的。面向行存储的数据库主要适合于事务性要求严格场合,或者说面向行存储的存储系统适合OLTP。可是依据CAP理论,传统的RDBMS。为了实现强一致性,通过严格的ACID事务来进行同步,这就造成了系统的可用性和伸缩性方面大大折扣。而眼下的非常多NoSQL产品,包含Hbase,它们都是一种终于一致性的系统,它们为了高的可用性牺牲了一部分的一致性。好像。我上面说了面向列存储,那么究竟什么是面向列存储呢?Hbase,Casandra,Bigtable都属于面向列存储的分布式存储系统。 看到这里,假设您不明确Hbase是个啥东东,不要紧,我再总结一下下: Hbase是一个面向列存储的分布式存储系统。它的长处在于能够实现高性能的并发读写操作,同一时候Hbase还会对数据进行透明的切分,这样就使得存储本身具有了水平伸缩性。 二 Hbase数据模型 HBase,Cassandra的数据模型很类似。他们的思想都是来源于Google的Bigtable,因此这三者的数据模型很类似,唯一不同的就是Cassandra具有Super cloumn family的概念,而Hbase眼下我没发现。好了。废话少说。我们来看看Hbase的数据模型究竟是个啥东东。 在Hbase里面有以下两个基本的概念,Row key,Column Family。我们首先来看看Column family,Column family中文又名“列族”,Column family是在系统启动之前预先定义好的,每个Column Family都能够依据“限定符”有多个column.以下我们来举个样例就会很的清晰了。 假如系统中有一个User表。假设依照传统的RDBMS的话。User表中的列是固定的,比方schema 定义了name,age,sex等属性。User的属性是不能动态添加的。可是假设採用列存储系统。比方Hbase。那么我们能够定义User表,然后定义info 列族。User的数据能够分为:info:name = zhangsan,info:age=30,info:sex=male等。假设后来你又想添加另外的属性。这样非常方便仅仅须要info:newProperty就能够了。 或许前面的这个样例还不够清晰,我们再举个样例来解释一下。熟悉SNS的朋友,应该都知道有好友Feed,一般设计Feed,我们都是依照“某人在某时做了标题为某某的事情”,可是同一时候一般我们也会预留一下keyword,比方有时候feed或许须要url,feed须要image属性等,这样来说。feed本身的属性是不确定的。因此假设採用传统的关系数据库将很麻烦。况且关系数据库会造成一些为null的单元浪费,而列存储就不会出现这个问题。在Hbase里,假设每个column 单元没有值,那么是占用空间的。

02

埋头三天才把冷热分离二期实现思路:冷数据存放到HBase给搞懂

◆ 冷热分离二期实现思路:冷数据存放到HBase ◆ 冷热分离一期解决方案的不足 不得不说,冷热分离一期的解决方案确实能解决写操作慢和热数据慢的问题,但仍然存在诸多不足。 1)用户查询冷数据的速度依旧很慢,虽然查询冷数据的用户比例很低。 2)冷数据库偶尔会告警。 这两点不足体现在用户侧是什么样呢?那就是一旦客服在工单查询表中勾选“查询归档”checkBox,页面就会一直转圈,而后台冷数据库的IO就会飙升。 如果客服发现页面没反应,可能会多点几次“查询”按钮,那么有可能把后台服务器的请求线程占满,导致整个系统

01
领券