一.什么是HBase
HBase是一个高可靠性,高性能,面相列,可伸缩的分布式存储系统.HBase是基于 hadoop的分布式文件系统(HDFS).HBase是基于Google基于发表的BigTable论文实现的nosql(not only sql 不仅仅是数据库)类型数据库.
HBase不是关系型数据库, 其表可以是稀疏的, 所以其非常适合存储非结构化数据..当然也能存储结构化数据.
二.HBase的优势,解决的问题
在聊HBase的优势之前,我们要先来聊聊为什么我们不用关系型数据库存储,以MySQL为例,分析对于关系型数据库我们存储数据所面临的问题和对应的解决措施.
MySQL如何应对大数据问题
问题1: 对于查询来说,很多表中的列是没有用的.我们往往只需要少数的列
假设我们有如下的User表-User表,记录个人的详细信息.(这里只列出一条数据做例子,假设有一亿条数据)
| ID | NAME | PASSWD | AGE | TEL | ADD | |
|---|---|---|---|---|---|---|
| 1 | zs | 123 | 18 | 18611111 | 110@qq.com | beijing |
但是我们往往需求中只需要部分的列,例如我们只需要查zs的基本信息,如年龄,名字,电话.其他详细信息我们并不需要, 这时候的sql语句是select name,age,tel from user where name='zs'.
分析1
- 这条sql语句没有错.但是对于其每列出的字段其实很少使用到,但是这些字段存在对于查询效率是有影响的.
- 关系型数据库中,每个字段都会占用存储空间,假设没有索引,如果我们要查下一条记录,那么必须得计算出上一条记录所占用的字节大小,然后加上其起始地址才能读取到下一条数据.然后这些其他列对于我们查询并没有什么用,却会影响我们查询.
解决方案1
对于这样的情况,我们往往会将表进行按列拆分,可以理解为按列分类,我们又将这种表称为宽表, 例如将User表分为用户基础信息表和用户详情信息表
- 用户基础信息表, t_user_base(id,name,age,tel)
- 用户详情信息表, t_user_detail(id,passwd,emial,add)
问题2: 尽管问题一提高了查询效率,但是当单表的达到300W就开始变慢,超过500W条性能会下降特别明显.这时候我们还需要再做优化.
分析2
- 一旦MySQL超过了500W数据,性能会急剧下降.对于这样的大表我们还需要进行拆分，我们将这样的表称之为高表.以上述例子为例
- 我们需要对
t_user_base和t_user_detail同时进行拆分,即对t_user表进行拆分.这时候我们对表进行横向的拆分.假设我们这里是一分为二,即拆分成t_user_1和t_user_2表. - 横向拆分完后,我们一般需要将表分别放在不同的数据库服务器上,因为用户可能会频繁访问其中某个表比如
t_user_1中的数据,这时候如果t_user_2也放在同一台服务器上会收到影响.
解决方案2
问题3: 经过问题2的优化,我们已经将负载均摊掉.但是对于优化是服务端做的事,客户端并不知道.所以我们要提供负载均衡器.
分析3
- 我们可以使用负载均衡器来转发客户端请求,将压到均摊掉.这又称为服务端的负载均衡.
- 尽管我们能够均摊压力,但是对于一瞬间的高并发请求,负载均衡器压力也很大.为了解决这个问题,现在一般都使用客户端的负载均衡,将负载均衡放到客户端做.并且使用注册中心返回可以用的服务器给客户端.
- 所以我们使用注册中心和客户端负载均衡技术解决这个问题
MySQL存在的问题
尽管MySQL通过水平和纵向的分表,分服务器能够一定程度上解决大量数据带来的性能下降问题.但是对于PB级别的大数据,其依然无能为力.
- MySQL的Innodb引擎对一张表存储多少并没有限制,但是其对表空间有限制,其对表空间的限制在64TB.
- MySQL的MyISAM引擎一张表存储的数据最大限制在256TB, 旦其对表空间没有限制.
由于上述的两个限制,使得MySQL并没有办法在存储大量数据,并且来实现高效的查询.即使其使用了各种优化手段.
而MySQL的这些问题,通通的被我要介绍的HBase数据库框架解决了.
