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

Posted 2023-03-28

【中文标题】什么时候应该使用 Sql Azure，什么时候应该使用表存储？

【英文标题】：When should I use Sql Azure and when should I use table Storage?

【发布时间】：2011-06-23 06:08:05

【问题描述】：

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

【问题讨论】：

另见Intertech Windows Azure Table Storage vs. Windows SQL Azure

【参考方案1】：

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

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

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

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

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

【讨论】：

如果 ATS 仅支持同一分区键中的交易，那么来自金融交易的交易数据如何适用于 ATS？这让我大吃一惊……

因为“交易”意味着不同的东西。金融交易中的交易意味着记录，而对于支持 ATS 的交易而言，则意味着整个保存要么成功，要么失败。

你说的是“巨大的可扩展性”。那巨大有多大？有一些数据可以比较吗？

查看此链接：blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/… - 底部包含可扩展性目标

【参考方案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）。

【参考方案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 功能，您将节省资金。

【参考方案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

【讨论】：

我在谈论交易的方式是 Microsoft 所指的：在 Azure 的计费条款中，访问数据称为交易。 ATS 确实支持交易，尽管正如 David 已经提到的那样，其方式有些有限。

【参考方案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 表存储。

【讨论】：

在 ATS 中出现改进后，此建议在 2017 年 11 月仍然有效吗？

@Vikram - 我相信我的看法仍然有效，因为我实际上还没有看到任何对 ATS 本身的显着改进（如果我错过了一些具体的东西，请告诉我）。还有另一个相关选项，即 Cosmos DB，它能够通过其 Table API (docs.microsoft.com/en-us/azure/cosmos-db/table-introduction) 像 ATS 一样“行动”，但具有更好的一组功能。当然，我会想象它的定价类似于 Cosmos DB 而不是 ATS。但如果你刚开始并想要一个 Azure 原生选项，我会选择原生 Cosmos DB（或 Azure SQL）。

感谢您的建议...与 ATS 相比，CosmosDB 显然相当昂贵。我将进一步评估选项并继续。