关系数据库不具备可扩展性(SQL Databases Don't Scale)

时间 2019-12-05 标签关系数据库不具备扩展性 sql databases don't don scale

程序员

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

SQL Databases Don't Scale

“怎么样扩展关系数据库？”，我常常问别人这个问题。说到下降数据库的负载，有不少的方法：缓存，分片等等，可是数据库扩展问题的答案常常是咱们不扩展 … 。是的，关系数据库（ SQL Databases ）本质上是不具备可扩展性的！没有什么魔法烟尘能够撒上去让它突然能够扩展。 sql

什么是可扩展性

我想真正的可扩展性必须符合如下的准则：数据库

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

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

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

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

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

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

三、容错性，你能够从 RAID 磁盘阵列中取出一个磁盘，但它仍是能够正常的工做（虽然损失了性能），从新装入磁盘，它会恢复本身状态，应用 RAID 的程序并不知道全部这些过程（拔出、装入），因此应用程序的逻辑也不会受到干扰。 this

如今让咱们回顾下一些以往研究的用于数据库“扩展”的技术，并探讨它们为何不能知足可扩展性的 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/

本文地址：http://blog.csdn.net/dip_hu/archive/2011 /03/09/6234336.aspx 转载请保留