不一样的横向扩容（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连接访问应用程序。似乎不可思议，微软能保证你的数据拷贝物理分布在它们该存储的各个地方，同时保证有充足的服务器资源可用于快速处理所有用户的请求。这是一种特别的扩容方式，它的扩容潜力几乎是无限的，而你只需要为你使用的那部分付费。