分布式数据库HBase的架构设计详解

《分布式数据库HBase的架构设计详解》要点：
本文介绍了分布式数据库HBase的架构设计详解，希望对您有用。如果有疑问，可以联系我们。

讲师介绍：陈鸿威

云财经大数据CTO

• 曾任百度高级工程师,现主持设计开发云财经股市情报和大数据中心；
• 拥有丰富的在线电商、证券实时系统、金融海量数据在线计算的实战经验；致力于各类分布式和大数据开源项目研究.

主题简介：

1、传统数据库回顾

2、分布式基础理论

3、HBase特征

4、HBase底层架构

5、HBase设计要点

传统数据库回顾

近些年来,各种互联网+的公司如雨后春笋般出现,做一个在线平台或者做一个APP基本成为这些公司的标配.Web系统的流行,数据收集越来越容易,促使各类数据库系统应用得越来越广泛.

我们在平时的技术讨论或者实际应用中经常会提到传统数据库.提到传统数据库,很多人会很容易联想到Oracle、MySQL、SQL Server等带有很明显关系型数据库特征的数据库系统.在我看来,传统数据库并不等于这些数据库,而是看你怎么用的.一般来说,传统数据库包括以下三个鲜明的特点：

1、事务的保障：ACID

ACID一言以蔽之就是原子性、一致性、隔离性、持久化事务,它是四个单词的缩写：

• Atomicity 原子性 事务中所有操作要么全部完成,要么全失败.
• Consistency 一致性 在事务开始时或者结束时,数据库应该处于同一状态.
• Isolation 隔离性 事务将假定只有它自己在操作数据库,彼此不知晓.
• Durablity 一旦事务完成,就不能返回.

要做到ACID,从编程的角度来说,数据库系统一定会用到锁.

一般对事务要求比较高的主要是交易场景,银行系统、大型在线电商交易系统用得比较多.对于绝大多数创业公司而言,事务是一个偏理论的概念.实际上在,在线系统中,事务是一个很有用的东西,我们举个栗子：

用户A在平台购买增值服务的场景,会有很多种处理方式.

一般的程序员会如下处理：

1. 在财务表中增加一条用户A的扣费记录.(扣费)
2. 在用户增值服务表中增加一条用户A的增值服务记录.(开通服务)

用户至上的程序员会如下处理：

1. 在用户增值服务表中增加一条用户A的增值服务记录.(开通服务)
2. 在财务表中增加一条用户A的扣费记录.(扣费)

三年以上工作经验的程序员会如下处理：

1. 在财务表中增加一条用户A的扣费记录.(扣费)
2. 判断财务表中是否扣费成功,不成功通知系统交易失败.
3. 在用户增值服务表中增加一条用户A的增值服务记录.(开通服务)
4. 判断用户增值服务表中是否增加成功,不成功删除财务表中的扣费并且通知系统交易失败.

那么用上事务之后,你只要提交给数据库一般程序员操作,数据库就会给你三年以上工作经验的程序员的操作结果,在主从架构读写分离的数据库结构中效果还会更好.

2、丰富的数据类型和SQL的操作方式

传统的数据库系统可以存很多种类型的数据,主要包括：

1. 数字家族、整数和小数.整数又可以分为32位的,64位的…
2. 字符串类型.字符串又分为固定长度的和可变长度的…
3. 时间家族.日期、时间…
4. 二进制流…

这么多类型,确实很丰富.我们所看到的,都可以是字符,就算二进制流,也可以通过Base64转码用字符串表示.当然,在讲字符串的时候,我们是把编程语言进化到了一个很高级的程度,开发的友好性大于存储成本.

对于传统数据库系统的常用操作,我们一般会说CURD.即对表的增删改查,基本都用SQL语句来实现.SQL语句的结构主要分为以下几大部分：

1. 操作,select、insert、update、delete.
2. 表对象.
3. 字段范围(*/f1/f2…).
4. Where条件.
5. Order排序(desc/asc).
6. 查询范围限制(top/limit).

……

SQL语句是为使用者友好而设计的,无论何种数据库引擎,SQL最后都被映射成为IO和内存操作.

3、严格的数据模型：行式存储

在传统数据库系统中,一般来说在第一次写入数据之前,都需要创建库和创建表,而每一个表都有确定的表头,确定列数,每一列的名字以及确定的数据类型.在新数据的写入或者数据的修改的时候,数据库系统会根据创建好的表结构严格校验数据的合法性,对表结构的调整一般都需要很大的修改代价.

在存储单元里,同一行的数据会分布在相邻的存储单元里.

列式存储相对于行式存储而言,其同一列的数据会分布在相邻的存储单元里.

题外话：除了行存储和列存储,常见还有文档模型,典型的代表就是MongoDB.如果用传统的行的角度来看,不同的行列数可以不一样,列的名字和数据类型也可以不一样,列里面可以是另一个嵌套的行.

互联网的需求

在互联网化的大环境下,很多系统都很容易在短时间内系统收集上亿的数据,并且这些数据经过加工,还要为几十万、几百万甚至更多用户提供访问.从平台角度来说,一般就是从小到大,从简单到复杂的过程.主要来说,具有一下三方面特点：

• 对数据高并发读写的要求

数据库读写压力巨大,硬盘IO无法承受.一般处理方法是主从架构,读写分离,分库、分表,缓解写压力,增强读库的可扩展性.

• 对海量数据的存储和访问

存储记录数量有限,SQL查询效率极低的情况下.通过分库、分表,缓解数据增长压力.

• 伸缩性,可用性,可靠性方面的需求

横向扩展艰难,无法通过快速增加服务器节点实现,系统升级和维护造成服务不可用.通过主从架构,增强读库的扩展性,利用MMM架构处理写的瓶颈.

传统数据库的瓶颈

分库分表缺点：

1. 受业务规则影响,需求变动导致分库分表的维护复杂.
2. 系统数据访问层代码需要修改.

（编辑：ASP站长网）