关系数据库不具有可扩展性

前阵子翻译了一篇文章，分享一下。一家之言，难免有疏漏、错误，多多指正

 

 

      “怎么样扩展关系数据库？”，我经常问别人这个问题。说到降低数据库的负载，有很多的方法：缓存，分片等等，但是数据库扩展问题的答案经常是我们不扩展 … 。是的，关系数据库（ SQL Databases ）本质上是不具有可扩展性的！没有什么魔法能让它忽然可以具有可扩展性。

 

什么是可扩展性

       我想真正的可扩展性必须符合以下的准则：

1、  水平可扩展：越多的服务器带来越多的负载。

2、  对应用程序的透明性：服务器的扩展性实现必须与业务的应用逻辑无关，对之透明。

3、  容错性，节点可拆卸：不允许单个服务器节点的当机导致应用的错误、失败。

 

可以从电脑硬件方面举个例子： RAID 磁盘阵列就提供了可扩展性：

1、  水平扩展性：你可以用 4 个或者 12 个、 20 个磁盘组成 RAID5 ，更多的磁盘带来更的的存储空间和更高的性能。

2、  对应用程序的透明性，在应用程序看来 RAID 磁盘阵列就像是一个单独的设备，如文本编辑器根本就不知道它存储的文件被分割到多个磁盘。

3、  容错性，你可以从 RAID 磁盘阵列中取出一个磁盘，但它还是可以正常的工作（虽然损失了性能），重新装入磁盘，它会恢复自己状态，应用 RAID 的程序并不知道所有这些过程（拔出、装入），所以应用程序的逻辑也不会受到干扰。

 

现在让我们回顾下一些以往研究的用于数据库“扩展”的技术，并探讨它们为什么不能满足可扩展性的 3 个标准。

垂直扩展

一个扩展数据库的方法就是“扩展”服务器，提供一个更高性能，更佳存储的服务器，这经常被称为“垂直扩展”，有时候我们也称之为“摩尔定律”扩展。这种扩展的问题是什么呢？

 

l         扩展过程比较复杂，经常需要人的人工参与，也经常导致服务器的停机。

l         被替换的服务器变得没有价值，这导致了资源的浪费，并可能“鼓励”你超支的购买了你并不想买的高性能服务器。

l         服务器性能再高也有个瓶颈！

 

经常有很多公司碰到了最后一个问题（即使用的是 256 核的 SUN 服务器），并走入了死角。

所以，你可以把数据库装在一个更高性能的服务器上来获得更多的负载，但是垂直扩展的方式并不满足可扩展要求的第一点（水平可扩展）。

分区，或者说分片

分片就是更加应用程序制定的“界限”把数据切分到不同的数据库上。比如，你可能根据用户名的开头字母， 把 A-M 开头的用户存储到一个数据库，把 M-Z 的用户存储到另一个数据库。（这个划分的标准有很多，用户的 ID 划分也可以）。

这次方式的扩展需要和应用程序的逻辑紧密的结合起来，并且要精心的设计划分的模式和数据库的模式，和系统可能有的查询方式，总的一句话：令人痛苦的事！！

所以，分片的方式虽然是一个水平扩展的方式，但是却违反了可扩展性的第二个准则：它对应用程序的业务逻辑不透明。

分片引起的更深的问题是与关系数据库的本质有关的，关系数据库中的的表一般维护者关系模式，如果记录被切分到不同的服务器上，这相当于你需要维护者多个模式，也意味着你很可能要更改客户端的程序，分片的扩展方式使得关系数据库带来的很多优点荡然无存。

读写分离

MySQL 就可以简单的配置主从复制的方式来实现读写分离，数据库的“主”服务器实时的把数据分发复制到“从”服务器，“从”服务器提供只读的功能。这样就就可以在客户端和服务器之间制定一个智能的路由代理（或者在客户端的类库中实现这一个智能路由）：把一切的读操作（ SELECT ）分发到一个只读的“从”服务器，把一切的写操作（ INSERT, UPDATE, DELETE ）分发到“主”服务器。

Postgres 数据库也提供这种复制的方式（通过 Slony ），但是它的配置比 MySQL 的配置方式复杂得多。复制的方式是行得通，但也带来了不同程度配置、维护的头痛。

对于关系数据库的扩展技术来说，读写分离可能是最好的方式了，在读方面它提供了水平的可扩展性，并且对于应用程序来说它也是透明的，这也是很多大型关系数据库系统采用的方式。

但是，读写分离最终还是一个受限的技术，它的瓶颈在于“主”服务器，特别对于一些写操作频繁的应用。并且对于可扩展性的第三个准则，它也不满足：“主”服务器当机，应用肯定出现错误。不止是在数据库挂掉的情况，在日常的数据库维护过程也会比较麻烦，利用只读“从”服务器，可以很方便的恢复另一个服务器的数据，但这也要对“从”服务器的状态时刻地做监视。

读写分离带来了水平扩展性和读性能的提高，但是对于写的性能和数据库容量的提升并没有帮助。水平的可扩展性不止要提升查询的负载也必须提升数据本身存储的负载。这就是在 RAID 磁盘阵列中你如何提高存储的空间：给它足够多的磁盘，就可以获得一个比市场上任意一个磁盘容量大得多的容量的空间。主从复制的方式需要完全的复制，这就面临了一个问题：到底你需要多大的数据空间，你的业务数据是一定范围的吗？

长期的探讨过程

       我们到底要怎么做？一些人可能回答：“继续研究如何使关系数据库变的可扩展。”。我不同意这个观点。成百上千的公司，天才的程序员、系统管理员对这个问题已经研究了二十几年，至今为止还没有一个大家可以大体接受的方案，这就告诉我，这个问题是无法解决的！我们只能通过改变问题本身来解决问题。（ we can only solve this problem by redefining the question ）

 

翻译原文地 址： h t t p ://adam.heroku.com/past/2009/7/6/sql_databases_dont_scale/