76

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

4

5 回答 5

71

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

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

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

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

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

于 2011-02-08T07:23:32.470 回答
32

伊戈尔和马克给出了很好的答案。让我再补充一点……

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

ATS 确实提供分区级别的事务（实体组事务）。有关详细信息，请参阅此 MSDN 文章。这不像 SQL Azure 事务那样健壮，但它确实允许在单个事务中进行批处理操作。

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

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

于 2011-02-08T14:08:33.223 回答
17

其中一些答案似乎并不完整，所以我将添加我的 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 表查询会很快
  • 底线是，如果您使用 Azure Table 来像 SQL 一样操作，请不要添加大量数据。如果您有大量数据（千兆字节），请不要计划针对它进行高性能 SQL 查询。如果您不需要那些常规的 SQL 功能，您将节省资金。
于 2011-02-23T02:27:46.170 回答
10

在事务方面，情况正好相反：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

于 2011-02-08T07:26:09.153 回答
3

真正的答案是“尽量不要使用 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 表存储。

于 2013-09-20T21:52:22.463 回答