1

我目前正在开展一个项目，该项目需要使用 SQL Azure 数据库来存储即将推出的应用程序的数据。该项目的目标之一是能够利用 SQL Azure 中的联合（分片）。该项目的另一个既定目标是如果客户选择此方案，则能够在本地硬件上运行此应用程序。

我面临的“障碍”之一是联邦缺乏对 IDENTITY 的支持。

http://blogs.msdn.com/b/cbiyikoglu/archive/2011/06/20/id-generation-in-federations-identity-sequences-and-guids-uniqueidentifier.aspx

虽然我理解为什么Azure 不支持 IDENTITY，但我似乎有一个心理障碍，即接受使用 GUID 作为聚集索引是一个好主意。

聚集和非聚集索引性能

我已经在上面的第一个链接中执行了示例测试，并确认在将记录插入到具有 guid 作为聚集索引的表中与将相同数量的记录插入到具有用作聚集索引的 int 标识字段。

但是，由于我还需要支持本地安装，我认为可以肯定地说，当使用 guid 作为聚集索引而不是使用 int 标识时，本地性能会受到影响。

除了与性能相关的问题外，我还担心使用 16 字节宽的 guid 作为聚集索引与使用 4 字节宽的整数作为聚集索引。当然，磁盘空间相对便宜，但这仍然会很快增加（而且可能是不必要的）。

我意识到我最终将不得不在需要支持这两个既定项目目标的基础上做出权衡，但我希望做出我能做出的最明智的决定。

除了使用中间层 id 生成器之外，还有哪些替代方法可以在 Azure 上使用 Guid 作为聚集索引（和 \ 或主键）同时仍然使用联邦？

或者，我是否担心使用 Guid 作为离基的聚集索引（我承认他们很可能是这样）？如果是这样，为什么？

4

2 回答 2

0

显然，在 SQL Azure 中使用 GUID 不会产生与本地 SQL Server 安装相同的性能问题。

许多人的经验表明 GUID（唯一标识符）不适合集群键，因为它们不会被排序并导致页面拆分，从而导致更高的延迟和碎片？在 SQL Azure 上不行

http://blogs.msdn.com/b/cbiyikoglu/archive/2012/05/17/id-generation-in-federations-identity-sequences-and-guids-uniqueidentifier.aspx

所以我可能会选择Guid的

于 2012-10-09T04:32:21.930 回答
0

您对 16 字节 Guid 与 4 字节 Int 的烦恼是对的（我也这样做）。然而，有好的一面——联邦使您能够大规模扩展 DB 层。

现在问题 - 根据Online Documentation，Federation Distribution 类型只能是以下之一：

INT、BIGINT、UNIQUEIDENTIFIER 或 VARBINARY(n)，其中 n 最大为 900

所以我认为 UNIQUEIDENTIFIER 确实是您应用程序的唯一选择。

在应用程序级别使用任何类型的 id 生成器都会引入单点故障/单点“崩溃”或瓶颈，这显然是 SQL Azure Federations 试图解决的问题。所以我不会使用任何 ID 生成逻辑，而不是应用程序端的 Guid.NewGuid() 或数据库端的 NEWID()。

至于 UNIQUEIDENTIFIER 对本地解决方案的性能影响，我不能说，这是一个单独的问题。

于 2012-10-08T10:15:50.267 回答