HBase 学习笔记之一

写在前面

​ 本系列是本人学习大数据生态中 HBase 相关内容的学习笔记会以实战和感想或者是理解的方式来整体相关内容,作为开篇我像先介绍一下 HBase 相关的背景以及其能够解决那些问题。

HBase VS RDBMS

​ HBase 全称 Hadoop Database,同样是 database 那不免就会将其和传统的 RDBMS 如 Mysql、Oracle 进行比较,两者的显著区别当然是 HBase 以 HDFS 为基础,而 RDBMS 则以计算器的文件系统为基础。除此之外更关键的是 HBase 是一种 NoSql ( Not Only Sql)其在大数据场景下解决了 RDBMS 会导致的一些问题,下面就根据个人的理解来分析一下并看看 HBase 是如何解决的。

行式存储

​ 传统的 RDBMS 存储文件或者说数据的方式是按照来存储的,见下图:

在这里插入图片描述

​ 这样的存储方式很符合常识也非常好理解,但是这种情况会带来两个问题:

  1. 宽表导致的查询效率下降
  2. 无法很好的应对业务的动态变化
宽表导致查询效率下降

​ 在传统的 RDBMS 中由于行存储的特点每次读取数据必然会取出完整的一行,即使使用 select 一个属性也会取出完整一行的数据,因此当表的宽度特别宽即属性列特别多的情况下查询的效率会显著的下降,而在大数据的场景下,因为数据量的特点我们会趋向于细化实体的属性并将其全部存储,因此表的宽度会趋向于越来越宽从而记录完整的维度信息。
​ 当然,在 RDBMS 的场景下我们可以拆分表来完成表的 “瘦身”,例如讲课程相关内容拆分出去形成一个码表或者说维度表,这样即减少了属性列也减少了课程相关数据所占的空间,但是这样同样也导致了一个问题,如果拆分出去的表太多,那么在查询时会导致过多的 join 操作也会降低查询的效率,而且查询语句也会变的难以完成。
​ 基于上述行存储的问题,HBase 以另一种列式存储的方式存储数据,其将属性列而非数据行作为存储的基本单元,这样的情况下当我们只需要一些特点属性时 HBase 就能够只读取属性列的数据,而不会读取其他属性列,当然这种情况下对于一行数据的查询效率就会变低了,理由其实和行存储查询一列数据相同。
​ HBase 这样设计的理由主要是因为其和传统 RDBMS 的目的不同,在大数据的场景下人们更关系数据背后隐藏的统计数据或者说统计规律,而这些规律往往是某个属性或者说某几个属性反应出来的,因此以列的方式存储数据能够在分析时更加高效。

无法应对业务的动态变化

​ 传统 RDBMS 另一个问题是其无法面对业务的变化或者是不擅于面对业务的变化,考虑如下场景:公司的数据库中有一张表记录的客户的全部数据,随着时代的变迁,联系方式中除了电话号码,多了一项微信,但是微信作为一种较新的通讯方式,可能大部分老年用户都没有(此处只是讲述案例),因此新增加一列 wechat 属性会导致许多空出来的存储空间,即产生了内存碎片一样的存在,这也是由于行式存储所引发的问题。
​ 而在 HBase 列存储的情况下,就不会存在这种问题,因为其列是存储的特性空缺的数据则直接不占用空间,此外 HBase 中还有列族(column family),其可以理解为一类属性的的父类,例如:姓名,年龄,职业,性别这些信息都是个人信息因此可以将其同一为一个列族 info,由此在 HBase 中我们可以弹性的在列族中添加列属性,且若某些行无此属性也不会占据存储空间。

总结

​ HBase 是面向列存储的数据库,由于其在统计某些属性时相比传统的 RDBMS 更具优势,于此同时得益于列存储的特性其能动态的扩展列族中的属性列使得 HBase 比起 RDBMS 更具弹性能够适应变化,本篇作为 HBase 相关内容的开篇,主要比较其和传统数据库的区别,下一篇会通过 HBase 的组成架构来更详细的分析其面向列的存储特点。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值