本节书摘来异步社区《HBase权威指南》一书中的第1章，第1.2节，作者： 【美】Lars George 译者： 代志远 , 刘佳 , 蒋杰 责编： 杨海玲，更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.2　关系数据库系统的问题

RDBMS在设计和实现商业应用方面扮演了一个不可或缺的角色（至少在可预见的未来仍旧如此）。只要用户需要保留用户、产品、会话、订单等信息，就会采用一些存储后端为前端应用服务器提供持久化数据的服务。这种结构非常适合有限的数据量，但对于数据急剧增长的情况，这种结构就显得力不从心了。

以我们之前提到的HBase短网址（HBase URL Shortener）服务——Hush为例。假设要构建一个初始就能支持几千个用户的系统，并且要节省成本，换句话说就是使用免费软件。这种经典案例就可以使用开源的LAMP⑨ 快速地搭建一个原型。

关系数据库模型通过用外键关联url表、shorturl表和click表，规范了存入user表的数据。其中这些数据表都有索引，可以保证你既能通过short ID检索到URL，又能通过username检索到用户。如果需要找出一个特定用户列表的所有短址URL，可以运行一个SQL的JOIN语句关联这两张表，得到一个全面的URL表，其中不仅包括短址URL，还包括所需的用户明细。

此外，还可以利用数据库内置的功能，如存储过程（stored procedure）。当数据系统需要始终保证多张表的数据一致性时，可以利用存储过程来解决多个客户端同时更新数据的一致性问题。

事务（transaction）提供了原子性跨表更新数据的特性，可以让修改同时可见或同时不可见。RDBMS提供了所谓的ACID⑩特性，这意味着用户数据是强一致性的（在稍后的“一致性模型”中有详细介绍）。参照完整性（referential integrity）负责约束不同的表结构之间的关系，利用特定域语言，即SQL，能够写出任意复杂的查询语句。最终，用户不需要关心实际上数据是怎样存储的，只需要关心更高层次的概念，例如，表结构，表结构在应用程序中提供了非常固定的访问模型。

通常这种模式的设计能在较长的一段时间里满足需求。如果足够幸运，你可能会成为下一个互联网上的热点，每天有越来越多的用户加入你的网站。但随着你网站用户数量的增加，共享数据库服务器的压力也会越来越大。增加应用服务器的数量相对来说比较容易，因为应用服务器之间是共享中央数据库的，但随着共享中央数据库的CPU和I/O负载的上升，你将很难预测你能承受这种增速度多久。

减少压力的第一步是增加用于并行读取的从服务器，将读写分离。这种方案保留了一个主数据库服务器，但是这个主数据库服务器现在只服务于写请求，这样做主要是考虑到网站的请求主要由用户浏览产生，因此写请求远少于读请求。如果这个方案也因用户数的持续增加而失败了，或者降低了系统的性能，又该怎么办呢？

下一步常见的做法是增加缓存，如Memcached⑪。现在可以将读操作接入到高速的在内存中缓存数据的系统中，但是这种方案无法保证数据一致性，因为用户更新数据到数据库，而数据库并不会主动更新缓存系统中的数据，所以需要尽可能快地同步缓存和数据库视图，把更新缓存数据与更新数据库数据的时间差最小化。

虽然这种方案能够缓解读请求的压力，但是写请求压力的增加问题还是没有得到解决。一旦主数据库服务器写性能下降，可以把主服务器换成加强服务器，即垂直扩容，让加强服务器使用更多的内核、更多的内存、更快的磁盘……总之，与初始的主服务器相比要花费更多的金钱。同时值得注意的是，用户如果已经选择了主从的配置方案，就必须要让从服务器的性能与主服务器同样强，否则从服务器的更新速度就会跟不上主服务器的更新速度，这样增加一倍到两倍的成本，甚至更多。

伴随着网站受欢迎程度增加，网站会需要增加更多新功能，而这些新功能无疑都会转化为后台数据库的查询语句。以前顺利执行的SQL JOIN语句执行突然变慢了，或是干脆无法执行，这时候就不得不采用逆范式化存储结构。如果情况越来越糟，就不得不停止使用存储过程，因为存储过程最后会慢得无法执行。本质上讲，减少数据库中的存储数据才能优化访问。

所以随着用户越来越多，负载会不断提高，合乎逻辑的方式就是不时地预先实现最昂贵的查询方案，从而给用户提供更快的数据服务。最终，不得不放弃辅助索引的使用，原因就是数据量增大的同时，索引量也大到了足以让数据库的性能直线下降。最后所能提供的查询模式只剩下了按照主键查询。

这时该怎么办？如果负载在未来的几个月里预期会增加一个数量级或更多又该怎么办？此时用户可以考虑将数据分区（sharding）到多个数据库中，但是采用此方案会使运维操作变成噩梦，而且代价非常昂贵，因此也不是最合理的解决方案。但从本质来讲，采用RDBMS也是因为没有其他可以选择的方案。

分区

分区（sharding）主要描述了逻辑上水平划分数据的方案。这个方案的特点是将数据分文件或分服务器存储，而不是连续存储。

数据的分区是在固定范围内实施的：在传入数据之前，必须提前划分好数据的存储范围，如果一个水平划分的压力超过其所能提供的容量，就需要将数据重分区（reshard）并迁移数据。

重分区并迁移数据是非常消耗资源的操作，等同于数据重做。需要重新划分边界然后横向拆分（split）。大规模的复制操作会消耗大量的I/O资源，同时还会临时性地增加存储需求。在对数据重分区的过程中，客户端应用仍然会有更新操作要执行，不过此时的更新操作受重分区的影响会执行得非常慢。

可以采用虚拟分区（virtual shard）的方式来减少这种资源消耗，虚拟分区按照关键词定义范围较大的数据分区，每个服务器加载同等数量的数据分区。但是在新增服务器的时候，需要重新加载数据分区到新服务器，并且这个过程仍旧需要将数据迁移到新服务器。

分区是简单的完全脱离用户操作的事后操作，如果没有数据库的支持，可能会对生产系统造成严重破坏。
对于关系数据库系统的问题就讲到这里，客观地讲，RDBMS已经在大量的公司里使用，并形成了较大规模的技术体系。例如，Facebook、Google都已经大规模地使用了MySQL，因为MySQL的安装和使用都已经非常简洁，相关的参考资料和范例也非常充分。这个数据库适合特定场景的业务，并且短期内不会被取代。这里有个问题是：如果你想开发一个新产品，并且在设计阶段就已经预料到系统拓展速度非常快，那么，你是希望所有的功能都可用，还是使用某些有一定制约的功能？