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

  “怎么样扩展关系数据库？”，我经常问别人这个问题。说到降低数据库的负载，有很多的方法：缓存，分片等等，但是数据库扩展问题的答案经常是我们不扩展 … 。是的，关系数据库（ 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 的配置方式复杂得多。复制的方式是行得通，但也带来了不同程度配置、维护的头痛。
对于关系数据库的扩展技术来说，读写分离可能是最好的方式了，在读方面它提供了水平的可扩展性，并且对于应用程序来说它也是透明的，这也是很多大型关系数据库系统采用的方式。
但是，读写分离最终还是一个受限的技术，它的瓶颈在于“主”服务器，特别对于一些写操作频繁的应用。并且对于可扩展性的第三个准则，它也不满足：“主”服务器当机，应用肯定出现错误。不止是在数据库挂掉的情况，在日常的数据库维护过程也会比较麻烦，利用只读“从”服务器，可以很方便的恢复另一个服务器的数据，但这也要对“从”服务器的状态时刻地做监视。