• 博客访问: 668048
  • 博文数量: 146
  • 博客积分: 3161
  • 博客等级: 中校
  • 技术积分: 3009
  • 用 户 组: 普通用户
  • 注册时间: 2011-09-27 14:53
文章存档

2014年(1)

2012年(31)

2011年(114)

微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

订阅
热词专题

分类: 数据库开发技术

在上篇文章中,我们讲述了SQL Server横向扩展(或者称之为“水平扩展”)方案中的两种:SODAP2P技术,本篇文章将会继续的介绍余下的方案。

Scalable Shared DatabaseSSD,可伸缩的共享数据库)


可以说SSDSQL Server中最容易实现的一种扩展方案。我们可以把数据存储放在一个SAN上面,然后在使用多个SQL Server的实例来访问这个SAN上面的数据。这些SQL Server实例可以使分别安装在不同的服务器上,也可以在同一个服务器上面安装多个实例。不过,我们一般是一台服务器一个SQL Server实例。


如下图,可以清晰的直到这个方案的架构图:


上面的图就是SSD的一个最基本的实现,但是谁也没有说“SSD只有上面一种实现”,因为SSD和之前的P2P一样,是一种架构的思想,而不是定死的技术。就好比编程世界中的设计模式一样,每一种设计模式的UML图只是给出这个模式的基本的结构和类图组成,不是说这个模式就非得一板一眼的按照这个UML来,而是根据需求而变化。所以,要领悟其“神”,而不是其“形”。


上面图示中展示的就是朋友们常常说的“共享磁盘”的数据库扩展方式。此时,所有的数据库实例都是用同一个存储设备,那么这个存储设备就是一个潜在的瓶颈和故障点。而且多个实例之前可能会发生资源的争夺。


熟悉SQL Server的朋友们马上可能就会问“多个数据库的锁会相互的影响吗?”。

一般而言,每一个SQL Server的实例都会把锁保存在各自的内存中,所以各个不同的数据库实例之间是不知道其他实例锁的信息的。这样就会出现一些问题,如数据库实例A修改某个数据,但是B确保数据锁定,但是B是不知道A锁定了数据的,那么最后导致数据不一样,甚至出现灾难导致数据崩溃。


所以SSD方案最好使用在只读的系统中(或者读操作占据绝大部分的应用),例如报表或者数据库操作等。


大家还记得我们之前谈到过的数据的几种类型吗,SSD比较适合于来扩展引用类型的数据,因为这些数据是不变的,或者变化的非常缓慢。


有人又要问了:难道SSD方案就如此的脆弱

现在的应用不可能说不存在数据更新等情况。能否改进SSD,使之满足需求,毕竟SSD的实现最为容易。

答案是:可以的


正如之前说过,SSD是一种架构设计的思想,我们可以将之适当的修改迎合实际的情况。

SSD只说了共享磁盘,共享存储,但是没有规定说:只能在共享的存储设备上面放一份数据。


所以,我们这里可以使用读写分离进行改进,设计如下:


在图中,我们可以把数据在SAN上面放置两份。然后让一个或者几个数据库实例负责写的操作,而另外的数据库实例负责读的操作,然后采用SQL ServerRepliaction技术,把数据同步。

这里和我们之前的P2P不同,在P2P中,每个数据库实例都有自己的单独的一份数据,而这里情况却不是这样的:可能是一个实例有一份数据,或者几个实例共享一份数据。

所以大家思维要开阔。


很多的朋友很喜欢说“共享磁盘不好”等等这样的问题。

其实这都是没有道理的。因为每个方案都有各自的适用场景,如果你认为无共享磁盘的数据库方案好,那么可以试想:如果每一份数据都不断的增长,到了TB,PB,那么数据的管理就非常的复杂,而且还有浪费几倍的存储空间,花费的人力,财力更不用说。所以,每次在谈一个技术的时候,不要随随便便的说“这个技术不行”,凡事都是有上下文的。


就拿我们现在讲的SSD和之前的P2P而言,它们可以适用的场景就不一样,P2P更加适合在写操作很多的应用中,如OLTP,而SSDOLAP系统中效果不错。今天就到这里,下一篇:Data-Dependent Routing

阅读(2904) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册