分片数据库（Azure 联合数据库）的 ID 生成

Question

我一直在寻找一些关于 Azure 联合数据库的 id 生成（联合/主键）最佳实践的文章或指南，但没有发现任何令人信服的内容。联合表不支持标识列，因此在我看来，唯一实用的 id 类型是 GUID，因为尝试集中创建和使用 BigInt 会在应用程序中创建单点故障。我主要关心的是在 BigInts 上使用 GUID 对性能的影响（尤其是对表进行索引）。

是否有任何推荐/最佳实践（或现有库）来为分布式系统创建独特的 BigInts（或者我不应该担心使用 GUID 对性能的影响？）。

[更新]

自从发布问题以来，已经阅读了更多关于此的内容，在我看来，密钥生成将成为 Azure 中的一个问题。根据 Microsoft 的此 blog 帖子，建议使用 GUID 作为联合密钥。但是他们没有提到联合表上的所有索引（包括聚集索引）都必须包含联合键。这意味着所有这些索引都将包含一个 GUID，这会降低插入性能。

替代方案似乎是使用集中式密钥生成服务（如下文 Simon 所述），它在成为潜在瓶颈和中心故障点方面有其自身的缺点。

我原以为微软会对此提供更多指导，因为这肯定是每个创建联合表的人都会面临的问题！

总的来说，我决定使用集中式密钥生成服务，但这确实让我有点担心。如果有人有一些魔术技巧，我很想听听（或者如果我遗漏了一些明显的东西，请告诉我）！

Answer 1

您可以使用多种技术在应用程序中创建序列，但由于分布式特性，它们并不简单。一个相当不错的方法是使用blob storage and preconditions。

根据您的项目计划，您可能希望使用SQL 2012 SEQUENCE 并将所有序列放入一个小型非联合数据库中。 SEQUENCE 在 SQL Azure 上尚不可用。

Answer 2

当您考虑联合密钥时，重要的是要考虑一个实际上会在联合成员之间产生良好分布的密钥，因此在许多情况下生成的 id 并不是一个好主意。 例如 - 按订单 id 分区意味着所有最新订单都在最新的联盟成员中，并且很可能是大多数用户正在操作的订单，因此联盟的好处将大大降低，按国家/客户 id 分区/etc 更有可能实现联邦旨在带来的可扩展性优势。

当涉及到一行的唯一身份时，您需要考虑实体将存储在不同的数据库中，因此身份或序列生成不可用，请查看 Cihan Biyikoglu blog post on this - 他的建议是使用 uniqueidentifier或 datetimeoffset

Answer 3

在我的项目中，我总是使用 GUID 作为联合密钥，因为我认为它不会导致严重的性能问题。也许我的项目并没有那么大，但它确实对我有用。所以我对你的第一个问题的回答是“是”。

你的下一个问题，我正在考虑在那里有一个 ID 生成器服务，正如你所想的那样，但是是的，它可能是一个瓶颈。我在想我们是否可以有一个 ID 池，它利用一些分发缓存来存储此服务生成的 ID。因此，任何人都想要一个 ID，它将从池中检索，而不是按需生成。因此 ID 生成器将继续在该池中推送 ID，消费者将从其中弹出一个 ID。这可能会有所帮助，但同样，我从来没有以这种方式实施过，所以我可能无法说这是否是最佳做法。

希望这会有所帮助。

Answer 4

使用 GUID 作为主键的一个不利因素是，如果表聚集在主键上，则会导致插入时出现大量页面拆分。这是因为好的 GUID 不是按时间顺序生成的，因此难以猜测。

Azure SQL 表确实需要聚集索引。我的建议是在基于范围的值（如日期时间）上建立一个聚集索引，并为主键使用一个非聚集索引，这将是 GUID。