全部博文（141）
分类： 数据库开发技术
2012-09-26 16:53:38
在上篇文章中，我们讲述了SQL Server横向扩展（或者称之为“水平扩展”）方案中的两种：SODA和P2P技术，本篇文章将会继续的介绍余下的方案。
Scalable Shared Database（SSD，可伸缩的共享数据库）
可以说SSD是SQL Server中最容易实现的一种扩展方案。我们可以把数据存储放在一个SAN上面，然后在使用多个SQL Server的实例来访问这个SAN上面的数据。这些SQL Server实例可以使分别安装在不同的服务器上，也可以在同一个服务器上面安装多个实例。不过，我们一般是一台服务器一个SQL Server实例。
如下图，可以清晰的直到这个方案的架构图：
(31.61 K)上面的图就是SSD的一个最基本的实现，但是谁也没有说“SSD只有上面一种实现”，因为SSD和之前的P2P一样，是一种架构的思想，而不是定死的技术。就好比编程世界中的设计模式一样，每一种设计模式的UML图只是给出这个模式的基本的结构和类图组成，不是说这个模式就非得一板一眼的按照这个UML来，而是根据需求而变化。所以，要领悟其“神”，而不是其“形”。
上面图示中展示的就是朋友们常常说的“共享磁盘”的数据库扩展方式。此时，所有的数据库实例都是用同一个存储设备，那么这个存储设备就是一个潜在的瓶颈和故障点。而且多个实例之前可能会发生资源的争夺。
熟悉SQL Server的朋友们马上可能就会问“多个数据库的锁会相互的影响吗？”。
一般而言，每一个SQL Server的实例都会把锁保存在各自的内存中，所以各个不同的数据库实例之间是不知道其他实例锁的信息的。这样就会出现一些问题，如数据库实例A修改某个数据，但是B确保数据锁定，但是B是不知道A锁定了数据的，那么最后导致数据不一样，甚至出现灾难导致数据崩溃。
所以SSD方案最好使用在只读的系统中（或者读操作占据绝大部分的应用），例如报表或者数据库操作等。
大家还记得我们之前谈到过的数据的几种类型吗，SSD比较适合于来扩展引用类型的数据，因为这些数据是不变的，或者变化的非常缓慢。
有人又要问了：难道SSD方案就如此的脆弱？
现在的应用不可能说不存在数据更新等情况。能否改进SSD，使之满足需求，毕竟SSD的实现最为容易。
答案是：可以的。
正如之前说过，SSD是一种架构设计的思想，我们可以将之适当的修改迎合实际的情况。
SSD只说了共享磁盘，共享存储，但是没有规定说：只能在共享的存储设备上面放一份数据。
所以，我们这里可以使用读写分离进行改进，设计如下：
(44.69 K)在图中，我们可以把数据在SAN上面放置两份。然后让一个或者几个数据库实例负责写的操作，而另外的数据库实例负责读的操作，然后采用SQL Server的Repliaction技术，把数据同步。
这里和我们之前的P2P不同，在P2P中，每个数据库实例都有自己的单独的一份数据，而这里情况却不是这样的：可能是一个实例有一份数据，或者几个实例共享一份数据。
所以大家思维要开阔。
很多的朋友很喜欢说“共享磁盘不好”等等这样的问题。
其实这都是没有道理的。因为每个方案都有各自的适用场景，如果你认为无共享磁盘的数据库方案好，那么可以试想：如果每一份数据都不断的增长，到了TB,PB，那么数据的管理就非常的复杂，而且还有浪费几倍的存储空间，花费的人力，财力更不用说。所以，每次在谈一个技术的时候，不要随随便便的说“这个技术不行”，凡事都是有上下文的。
就拿我们现在讲的SSD和之前的P2P而言，它们可以适用的场景就不一样，P2P更加适合在写操作很多的应用中，如OLTP，而SSD在OLAP系统中效果不错。今天就到这里，下一篇：Data-Dependent Routing
