SQL Azure 联合的标识替代方案：Azure 队列或服务总线队列是一个不错的选择吗？答案

【问题标题】：Identity alternative for SQL Azure Federation : are Azure Queues or Service Bus Queues a good choice?SQL Azure 联合的标识替代方案：Azure 队列或服务总线队列是一个不错的选择吗？
【发布时间】：2012-11-25 13:18:21
【问题描述】：

与许多开发人员一样，我正在寻找一种将现有应用程序集成到 SQL Azure 联合的方法，而替换身份列（我的表的主键）是一个大问题。

出于多种原因，我不想将 GUID 用作我的主键（请不要打开关于 GUID 的辩论，这不是我的问题：我只是不想要 GUID，句号）。

所以我需要构建一个密钥提供程序来替换标准 SQL 数据库的“身份”功能。我正在使用实体框架，所以我可以很容易地找到一个在插入之前设置Id 值的地方（通过覆盖我的ObjectContext 类的SaveChanges 方法）。我只需要找到一个“不太复杂”的实现来获取当前的 ID，即“农场就绪”。

我读过这篇 SO 帖子：“ID Generation for Sharded Database (Azure Federated Database)”和“来自 MSDN 杂志的Synchronizing Multiple Nodes in Windows Azure”，但这个解决方案对我来说听起来有点复杂。

我正在考虑为每个 SQL 表创建（自动）一个 azure 队列，其中包含一个预加载的连续整数列表。当我想要一个 Id 值时，我只需要从队列中获取一条消息（它变得不可见并在途中被删除），这给了我当前可用的 Id。

关于“Windows Azure 队列”和“Windows Azure 服务总线队列”之间的选择，我更喜欢“Windows Azure 队列”，因为"high" latency of Service Bus Queues。我不认为 Azure Queues 缺少“订购保证”是个问题。

您如何看待使用 Azure 队列提供 Id 值的想法？您认为有什么理由可以放弃这个想法吗？在 SQL Azure 联合数据库中提供整数 id 是否有更好的想法，甚至是好的做法？谢谢。

编辑：

Astaykov 建议 SnowMaker。我终于完成了fork of SnowMaker 以完全兼容 Azure 存储库的 v2。

编辑 2

请注意，如here 所述，Azure SQL 联合将于 2015 年 9 月停用，包括 Web 和业务层。但是这个问题对于自定义分片解决方案仍然有效。

【问题讨论】：

标签： azure azure-sql-database federation azure-queues

【解决方案1】：

SnowMaker

虽然从未在生产中尝试过，但似乎相当合理和可靠。

更新

两件事：您可以安全地参考 Azure Storage Client 1.7.XX 和 Azure.Storage 2.X 以使 SnowMaker 工作。或者像您一样修复它以与 Storage 2 一起使用。

作为旁注，我个人认为身份并不能解决任何问题，它甚至引入了这样的问题（但我仍然使用它）。考虑到它赋予我们的权力和规模，不要认为缺乏身份是联邦的劣势。为了做大事，我们必须摆脱传统的想法，即数字自动生成。

很遗憾，我还没有与联邦合作的实际项目经验，但我真的很想尝试一下。我知道有大型应用程序部署使用联合并且可大规模扩展。

【讨论】：

感谢您指出这一点。不幸的是，SnowMaker 与 Azure Storage Library v2+ 不兼容，所以我不得不重写 BlobOptimisticDataStore 类，我现在只是在尝试。这个Identity的问题真的让我对SQL Federations有一种不完整的感觉……那真是可惜。顺便说一句，谢谢你的回答！
两件事：您可以安全地参考 Azure Storage Client 1.7.XX 和 Azure.Storage 2.X 以使 SnowMaker 工作。或者像你一样修复它以使用 Storage 2。
我同意你的观点，即身份并不能解决可扩展性方面的任何问题。但有时我们不需要可扩展性，我们只需要一个易于设置的小型多租户系统。在这种情况下，标识列不是问题。我认为 SQL Azure 联合是一种将单租户应用程序迁移到多租户应用程序的简单方法。事实上，这并不容易（至少目前如此）。对于身份的特殊情况，我理解并接受这个限制，但我很遗憾微软没有提供任何替换它的指南（当然除了 GUID）。
为了有一个同构的解决方案，我终于做了一个fork of SnowMaker 来完全兼容Azure Storage lib的v2。
太好了，我很高兴你分叉了 SnowMaker，我完全同意你的事实，即 MSFT 没有提供任何关于如何设计联邦的实际指南。这（为联邦设计）绝对是一项艰巨的任务。

【解决方案2】：

另一个选项是RustFlakes 项目。它提供了一种在分布式系统中生成唯一的、连续的 ID 而不会相互冲突的方法。它们与 GUID（128 位）大小相同，但由于它们是连续的，因此不会导致您在使用 GUID 时遇到的所有页面拆分、索引和相关问题。

【讨论】：

【解决方案3】：

不确定这是否对您有用，因为它不是 C#，但我已使用 0.3.3 版本的 Nodejs Azure Storage SDK 将 Snowmaker 移植到 Nodejs。

你可以使用 npm 安装它：

npm install snowmaker

Github 仓库是https://github.com/johnhamm/node-snowmaker

【讨论】：