什么时候应该使用 Sql Azure，什么时候应该使用表存储？

Question

什么时候应该使用 Sql Azure，什么时候应该使用表存储？ 我在想，将表存储用于事务处理场景，例如当数据不用于交易目的（例如报告）时，借记贷方帐户类型的场景并使用 Sql Azure。 你怎么看？

Answer 1

这是一个很好的问题，也是解决方案架构师在为 Azure 进行设计时必须做出的更艰难和更难扭转的决定之一。

需要考虑多个维度： 不利的一面是，SQL Azure 对于千兆字节的存储来说相对昂贵，不能很好地扩展，并且仅限于 150gigs/数据库， 但是，这非常重要，SQL Azure 没有交易费用，而且您的开发人员已经知道如何针对它进行编码。

ATS 是一种完全不同的动物。具有超大规模的可扩展性，存储起来非常便宜，但频繁访问却变得昂贵。它还需要来自节点的大量 CPU 能力来进行操作。它基本上迫使您的计算节点成为迷你数据库服务器，因为所有关系活动的委托都移交给它们。

因此，在我看来，不需要巨大可扩展性且规模不是超大的频繁访问的数据应该用于 SQL Azure，否则为 Azure 表服务。

您的具体示例，来自金融交易的交易数据非常适合 ATS，而元信息（帐户配置文件、姓名、地址等）非常适合 SQL Azure。

Answer 2

Igor 和 Mark 给出了很好的答案。让我再补充一点……

使用 SQL 数据库（以前称为 SQL Azure），您现在可以拥有高达 500GB 的数据库。除此之外，您需要对数据进行分区。 注意：最初我建议使用 SQL 联合进行分片，但该功能已被淘汰。

ATS 确实提供分区级别的事务（实体组事务）。请参阅this MSDN article 了解更多信息。这不像 SQL Azure 事务那样健壮，但它确实允许在单个事务中进行批量操作。

编辑这个问题被问（和回答）已经一年多了。一个比较点是定价。虽然 SQL Azure 仍然比 ATS 更贵，但 SQL Azure 的成本在过去一年中已大幅下降。数据库现在有分层定价，从 100MB 的 4.99 美元起，150GB 的 225 美元起（与去年的 9.99 美元/GB 定价相比大幅下降。完整的定价详情为 here。

2014 年 8 月编辑 又过了一年，又一次更新。虽然 Web/业务层继续存在，但它们正在被淘汰（并且 SQL 联合不再可用）。新的 Basic、Standard 和 Premium 层级现已推出（有关详细信息，请参阅 here）。

Answer 3

其中一些答案似乎不完整，所以我将添加我的 2 美分。

Azure Table 的优点：

• 优势在于它能够存储大量小数据； Azure 表基于 Azure Blob，但面向较小的数据
• 比 Azure SQL Server 便宜很多
• 只要知道分区键和行键，数据访问就会非常快。
• Entity transactions 如果您将两个不同的“模式”放在同一个分区键中，则可能。
• 总行大小小于 980K（SQL 行）
• 每个属性小于 64K（SQL 列）
• 它可以充当穷人的SQL。

Azure 表的缺点：

• SQL 是弱点。不要期望在任何大型 SQL 表上使用它，否则您会遇到性能问题。
• 有限的 SQL 可用，不要指望任何类型的连接，除了你在 Linq 中实现的内容
• Azure Table SQL 无法扩展，也无法存储无限量的数据
• 任何时候您没有在 WHERE 子句中同时指定分区键和行键，都会出现缓慢的表扫描
• 预计表扫描性能会随着您添加更多行而降低
• 不要指望 Azue Table 查询在您添加更多行时会很快
• 底线，如果您使用 Azure Table 来像 SQL 一样操作，请不要添加大量数据。如果您有大量数据（千兆字节），请不要计划针对它进行高性能 SQL 查询。如果您不需要这些常规 SQL 功能，您将节省资金。

Answer 4

在事务方面，情况正好相反：SQL Azure 支持事务；表存储没有。

SQL Azure 基本上是在 Windows Azure 中运行的 SQL Server，因此如果您有一个使用 SQL Server 的现有应用程序，SQL Azure 提供了一个良好的迁移路径。但是，您在 SQL Azure 上可以拥有多大的数据库（当前为 150 GB）是有限制的，因此它可以扩展的程度是有限的。

另一方面，表存储具有极强的可扩展性，但需要不同的思维方式。它不是关系数据库。参见例如这篇文章很好的介绍：http://msdn.microsoft.com/en-us/magazine/ff796231.aspx

Answer 5

真正的答案是“尽量不要使用 Azure 表存储”。每当您从关系数据库迁移到无 SQL 数据库时，您当然必须改变对存储架构的看法。但 ATS 的问题远不止需要“以不同的方式思考”。正如其他人所指出的，它不仅仅是一个“No-SQL”数据存储，它是一个特别发育不良、残障且功能非常低的 No-SQL 存储实例。这不是需要对 ATS 进行“不同思考”的问题；这是 ATS 没有为您提供完成工作所需的工具的问题 - 其他 no-sql 数据存储提供为您提供的工具。

关于 ATS 的唯一好处是您可以非常快速地将大量数据放入其中，并且存储费用最低。但是，除非您足够幸运地拥有一个神奇地匹配其分区键/行键存储模型的用例，否则您基本上不能希望再次获取该数据。如果您不这样做 - 我怀疑很少有人这样做 - 您将进行大量分区扫描，并自己处理数据。

除此之外，Azure 表存储在发展方面似乎处于死胡同。如果您查看 Azure 反馈论坛 (http://feedback.windowsazure.com/forums/217298-storage/suggestions/396314-support-secondary-indexes) 上的“支持二级索引”请求，您可以看到早在 2011 年就承诺支持二级索引，但没有取得任何进展。对表存储的任何其他最高请求也没有任何进展。

现在，我知道 Scott Guthrie 是一个高素质的人，所以我希望表存储方面的所有这些停滞是 Azure 修复它并提出一些非常酷的东西的前奏。这是我的希望（尽管我的证据为零）。但就目前而言，除非您别无选择，否则我强烈建议您不要使用 Azure 表存储。使用 Azure SQL；使用您自己的 MongoDB 实例或其他 No-SQL DB；或使用 Amazon DynamoDB。但不要使用 Azure 表存储。