比较SQL Server 2008中的纵向扩容和横向扩容(下)

日期: 2009-05-13 作者:Don Jones翻译:冯昀晖 来源:TechTarget中国 英文

不一样的横向扩容(Scale out)   在SQL Server中维护多份数据副本之间的复杂性在于,采用横向扩容机制的用户不得不关注各数据副本。有一种技术是把数据分区。例如:在一个接收订单输入的大型数据库中,我们可以把客户信息存储在Server1,产品信息存储到Server2,订单信息放在Server3。订单信息可以被进一步划分开,如:北美来的订单在Server3,欧洲来的订单在Server4。

所有的数据都能保持连接。我们可以创建SQL Server的联邦视图(federated view)对象来使得客户端看到的是一个巨大的数据库,而不是三、四个独立分开的数据库。因为任何两台Server数据……

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

不一样的横向扩容(Scale out)

  在SQL Server中维护多份数据副本之间的复杂性在于,采用横向扩容机制的用户不得不关注各数据副本。有一种技术是把数据分区。例如:在一个接收订单输入的大型数据库中,我们可以把客户信息存储在Server1,产品信息存储到Server2,订单信息放在Server3。订单信息可以被进一步划分开,如:北美来的订单在Server3,欧洲来的订单在Server4。所有的数据都能保持连接。我们可以创建SQL Server的联邦视图(federated view)对象来使得客户端看到的是一个巨大的数据库,而不是三、四个独立分开的数据库。因为任何两台Server数据库之间都没有数据交集,所以不需要复制。在一定程度上,联邦视图(federated view)甚至可以降低为实现这种功能而重新修改客户端应用的工作量。

  然而,这种方式也有缺点。它要求每个客户端与每台服务器之间保持良好的网络连接——这一点基本上不可能做到。在一些小县城专用WAN连接昂贵难求,要保证良好连接更加困难。另一个问题是横向扩容变得更复杂,因为你不得不重新划分数据,然后把数据到处移动。

  上面描述的分区类型叫垂直分区(vertical partitioning),我们是把SQL Server的所有表分布存放。还有一种分区技术叫水平分区(horizontal partitioning)。水平分区比垂直分区实现起来更复杂,但是它克服了垂直分区的一些缺点。采用水平分区技术时,每一台服务器包含应用程序需要的所有表,但是不包含表的所有数据行。我们需要定义表中的某一列作为分区关键字段,从而根据该字段的值选择数据行存储在哪一台服务器上。

  例如:所有欧洲录入的订单都存储在Server3的Orders表中,Server3物理上存放在欧洲机房;北美录入的订单存储在Server4的Orders表中,Server4物理上存放在美国总部机房。这样使得数据在物理上离最可能使用它们的客户群很近。当然我们仍支持任何一个地点的客户获取全部数据,只是速度会慢一些(取决于网络连接速度)。

  考虑选用“云计算”

  数据库扩容还有最后一个选择:就是抛开你自己的SQL Server,把思维和数据转向“云计算”。正是由于横向扩容(Scale out)所面临的困难,微软建立了Windows Azure(微软的Azure服务平台,云端操作系统服务平台)和Azure services家族。我们可以重写后端逻辑,封装为Web service集,客户端应用通过Web service对数据进行读写操作。你的数据存储在专门的“云”SQL Server服务器上。

  在这种情况下,所有用户都可以通过Internet连接访问应用程序。似乎不可思议,微软能保证你的数据拷贝物理分布在它们该存储的各个地方,同时保证有充足的服务器资源可用于快速处理所有用户的请求。这是一种特别的扩容方式,它的扩容潜力几乎是无限的,而你只需要为你使用的那部分付费。

作者

Don Jones
Don Jones

投稿作者

相关推荐