第1章
◄ 初识HBase ►

1.1　海量数据与NoSQL

1.1.1　关系型数据库的极限

想必大家都用过类似MySQL或者Oracle这样的关系型数据库。一个网站或者系统最核心的表就是用户表，而当用户表的数据达到几千万甚至几亿级别的时候，对单条数据的检索将花费数秒甚至达到分钟级别。实际情况更复杂，查询的操作速度将会受到以下两个因素的影响：

• 表会被并发地进行插入、编辑以及删除操作。一个大中型网站的并发操作一般能达到几十乃至几百并发，此时单条数据查询的延时将轻而易举地达到分钟级别。
• 查询语句通常都不是简单地对一个表的查询，而有可能是多个表关联后的复杂查询，甚至有可能有group by或者order by操作，此时，性能下降随之而来。

因此，当关系型数据库的表数据达到一定量级的时候，查询的操作就会慢得无法忍受。姑且不论聘请经验丰富的DBA进行深度优化的成本多少，实际情况是，哪怕是进行了深度的优化，情况仍然不容乐观。原本这种情况只发生在某些垄断行业中，但是现在随着越来越多的“独角兽公司”（估值达到10亿美元以上的公司）的出现，在海量数据下进行快速开发，并进行高效运行的需求越来越多。这可难倒了全世界的关系型数据库专家，世界的数据库技术似乎达到了瓶颈。怎么办呢？

1.1.2　CAP理论

有的专家尝试将关系型数据库做成分布式数据库，把压力分摊到了多个服务器上，但是，随之而来的问题则是很难保证原子性。原子性可是数据库最根本的ACID中的元素啊！如果没有了原子性，数据库就不可靠了，这样的数据库还能用吗？如果增加一些必要的操作，那么原子性是保证了，但是性能却大幅下降了。专家们始终没有办法构建出一个既有完美原子性又兼具高性能的分布式数据库。

就在一筹莫展的时候，有人突然想起，20世纪90年代初期Berkerly大学有位Eric Brewer教授提出了一个CAP理论，如图1-1所示。

全称是Consistency Availability and Partition tolerance：

• Consistency（一致性）：数据一致更新，所有数据变动都是同步的。
• Availability（可用性）：良好的响应性能。
• Partition tolerance（分区容错性）：可靠性。

Brewer教授给出的定理是：

任何分布式系统只可同时满足二点，没法三者兼顾。

Brewer教授给出的忠告是：

架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。

这回人们可以不用纠结于如何设计一个拥有完美原子性的高性能分布式数据库了。现在的问题是，我们究竟要舍弃哪一个特性？

1.1.3　NoSQL

对CAP特性的放弃带来了一种全新类型的数据库——非关系型数据库。和关系型数据库正好相反，非关系型数据库NoSQL对事务性的要求并不严格，甚至可以说是相当马虎。

有些数据库是保证最终一致性，信息不会立即同步，而是经过了一段时间才达到一致性。比如你发了一篇文章，你的一部分朋友立马看到了这篇文章，另一部分朋友却要等到5分钟之后才能刷出这篇文章。虽然有延时，但是对于一个娱乐性质的Web 2.0网站又有谁会在乎这几分钟的延时呢？如果你用传统关系型数据库，网站可能早就宕掉了。

有些数据库可以在部分机器宕机的情况下依然可以正常运行，其实原理就是把同一份数据复制成了好几份放到了好几个地方，正应了那句老话：

不要把鸡蛋同时放在一个篮子里。

读者在之后的篇章中可以看到，HBase正是这种类型的NoSQL数据库。

总之，数据库的世界从此开始百花齐放起来了，如图1-2所示。

很多人以为NoSQL是非SQL的意思，其实它是Not Only SQL的缩写，意思是不只是SQL。