Window Azure SQL Database（之前名为SQL Azure）是微软公司的云数据库服务。发布之初，Window Azure SQL Database的扩展性非常不好，往往会影响连接的应用和数据库本身。在那之后，微软公司增加了一项新服务来支持我们做扩展，即SQL数据库联合（SQL Database Federations）。

　　联合服务是应用于Window Azure SQL Database上的一套分片（Sharding）管理技术。分片也被称为联合（Federating），意思是把大表分成很多小表的过程，这些表分布在多个硬件设备上的多个数据库中，解决了单个系统容量和性能的限制问题。通过使用SQL 数据库联合，你可以创建联合，跨许多个SQL 数据库分割巨型表，同时对连接的应用程序隐藏基础结构的复杂性。联合服务并不是没有限制，但是在了解更多内容之前，我们先来看看如何在Window Azure SQL Database中部署联合。

　　理解Windows Azure SQL Database联合

　　联合就是一组SQL数据库，提供必要的机制跨这些数据库进行表的分发。要创建联合，你要先在常规Windows Azure SQL Database中定义一个联合对象。在创建这个对象的时候，你必须指定一个联合名称，一个分发主键及其数据类型。分发键映射到每个联合表的指定字段列上，决定了如何跨联合分发数据。托管联合对象的数据库被认为是“根”数据库。

　　你可以在根数据库中创建一个或多个联合，但是该数据库本身不能包含任何实际联合数据。数据要在联合成员（或分片）之间分发，这些成员本身都是SQL数据库。在创建联合时，联合服务会自动创建第一个SQL 数据库联合成员。也就是说，不管你什么时候添加联合，你总会得到两个数据库：根数据库和第一个成员数据库。然后，你可以划分成员，创建更多成员数据库。

　　一旦你添加了联合，你就可以定义需要联合处理的表，也就是说，定义哪些表的数据需要分发到联合成员中。每个联合表必须包含一个列映射到分发键，该列（也就是联合列）必须配置为与分发键完全相同的数据类型。联合服务限制数据类型为“INT, BIGINT, UNIQUEIDENTIFIER 和VARBINARY（最多900字节） ”。

图1

　　为了更好地描述这些分散片段如何协作，我们来看一个例子。图1展示了一个名为“BooksFed”的联合。该联合的分发键定义为“book_id”，它被配置为“INT”数据类型。该联合包含三个成员，每个成员都是Windows Azure SQL Database。此外，有三个表参与在此联合中：“Books”，“Sales ”和“Marketing”。每个表都包含“BookID ”列，该列映射到分发键“book_id”。这样，表中的数据会基于“book_id”列的值分发到表中。

　　默认情况，联合的初始成员在联合表中提取所有行。然而，当你给联合添加成员时，你就是定义了如何根据分发键划分数据。在我们的例子中，第一个成员（最上面的那个）包含有“BookID ”值小于“10,000”的所有行，而最后一个成员（最底下的那个）包含有“BookID ”值大于“20,000”的所有行。这就意味着联合表中“BookID ”值为“5000 ”的行会被存储在第一个成员中，而“BookID ”值为“25000 ”的行会存储在第三个成员中。

　　应用程序通过根数据库连接到联合，联合服务会把查询定位到合适的成员。这样，应用程序就不必关心背后的复杂连接关系了。

　　你也可以在成员数据库中存储非联合表——也叫引用表。这些表包含不需要做联合的数据。美国全国邮政区号或者州名称可能就是使用引用表很好的例子。但是，因为引用表并不是自动跨成员复制的，所以如果你想让所有成员数据库的数据都可用的话，你必须建立一套系统来做这件事。同时，要意识到Windows Azure SQL 数据库不支持跨数据库连接表（join操作）。

　　Windows Azure SQL Database联合的限制

　　如果你设计表时就考虑了联合，那么在SQL数据库中对表做联合就是一个相对简单的过程。但是，如果你的表没有这方面考虑，那么要做联合数据库可能需要对数据库和应用程序做不少调整才行，这样才能在联合服务的限定内起作用。例如，联合成员不支持“IDENTITY”属性。你不但需要重新定义那些列，而且可能还需要找到另一种方式来确保在所有联合成员中实现唯一主键。此外，联合成员不支持“TIMESTAMP”和“ROWVERSION”数据类型，也就是说你还必须去掉这两种类型的字段，如果你数据库中有的话。你的联合列必须配置为与分发键相同数据类型，所以这里可能也需要做一定的重构。

　　SQL 数据库最大的限制之一是不能跨数据库做表关联，这一点在做表联合时显得尤为重要。例如，如果数据跨越数据库边界了，你不能强迫引用完整性或者执行查找。此外，引用表不支持与联合表的外键关系，而且联合表需要所有的唯一和集群索引包含联合列。因此，你不能确保某个列跨联合唯一，除非它包含了分发键。

　　如果你想对表做联合，你还必须考虑几个其它管理和实施问题。例如，如果你需要跨联合成员修改对象，你必须更新每个成员。也就是说，有可能出现不同成员下对象不同的情况。同样，你给联合表加载初始数据的过程可能会是乏味和耗时的过程，如果你需要节省资源，可能还有缩减过程，如果各成员之间的对象不同步的话这个过程就变得更复杂了。

　　尽管有这么多限制，你可能仍然会认为联合功能很适合你的组织，尤其是你在设计数据库时就考虑了联合功能的情况下。联合服务支持你实时划分成员，无需让应用程序脱机，而且它处理起来会很快和轻松。因此，你可以根据需要扩展，利用更多的物理资源，同时降低I/O瓶颈和数据库吞吐。此外，还可能根据需要扩展或收缩，这有助于降低你的总拥有成本。

　　最后，你可能发现选择SQL数据库联合路线不适合你。也许你的数据库不能改造并应用联合环境。但是，如果你可以忍受必要的限制，SQL Server联合可以在扩展云数据库方面证明它是有价值的资源。