Azure 表还是 SQL Azure？答案

【问题标题】：Azure Tables or SQL Azure?Azure 表还是 SQL Azure？
【发布时间】：2019-07-03 13:39:49
【问题描述】：

我正处于一个 Web 应用程序的规划阶段，该应用程序将使用 ASP.NET 托管在 Azure 中，用于网站和网站内的 Silverlight，以获得丰富的用户体验。我应该使用 Azure Tables 还是 SQL Azure 来存储我的应用程序数据？

【问题讨论】：

标签： azure azure-sql-database azure-table-storage

【解决方案1】：

Azure 表存储似乎比 SQL Azure 便宜。它也比 SQL Azure 具有更高的可扩展性。

如果您一直在做大量的关系数据库工作，那么 SQL Azure 会更容易使用。如果您要移植一个已经在使用 SQL 数据库的应用程序，那么将其移至 SQL Azure 将是显而易见的选择，但这是我唯一推荐的情况。

Azure Tables 的主要限制是缺少二级索引。这是在 PDC '09 上宣布的，目前被列为即将推出，但没有任何时间框架公告。（见http://windowsazure.uservoice.com/forums/34192-windows-azure-feature-voting/suggestions/396314-support-secondary-indexes?ref=title）

我已经看到建议使用混合系统，您可以使用表和 Blob 存储来存储大量数据，但使用 SQL Azure 进行索引、搜索和过滤。但是，我自己还没有机会尝试该解决方案。

将二级索引添加到表存储后，它本质上将是一个基于云的NoSQL 系统，并且会比现在有用得多。

【讨论】：

希望他们在 Build 2014 上宣布这一点。
正如我在回答中所说，这是在 2009 年的 PDC（他们过去称为 Build）上宣布的！几年前我停止了屏住呼吸。 Build 2014 上的公告将是可笑的。他们只需要发布该功能。 Azure Tables 可能是一个竞争者。

【解决方案2】：

尽管名称相似，但 SQL Azure 表和表存储几乎没有共同之处。

这里有两个链接可能对您有所帮助：

基本上，第一个问题应该是我的应用程序真的需要扩展吗？如果不需要，那就选择 SQL Azure。

【讨论】：

【解决方案3】：

对于那些试图在这两个选项之间做出决定的人，请务必将报告要求纳入等式。 SQL Azure Reporting 和其他报告产品支持开箱即用的 SQL Azure。如果您需要生成复杂或灵活的报告，您可能希望避免使用表存储。

【讨论】：

【解决方案4】：

Azure 表比 SQL Azure 更便宜、更简单且可扩展性更好。 SQL Azure 是托管 SQL 环境，本质上是多租户，因此您应该分析您的性能要求是否适合 SQL Azure。 SQL Azure 的高级版本已发布，并在撰写本文时处于预览状态（请参阅HERE）。

我认为在 SQL Azure 和 Azure 表之间做出决定的决定性因素如下：

您需要进行复杂的连接并使用二级索引吗？如果是，SQL Azure 是最佳选择。
您需要存储过程吗？如果是，SQL Azure。
您需要自动缩放功能吗？ Azure 表是最佳选择。
Azure 表中的行大小不能超过 4MB。如果需要在一行内存储大数据，最好将其存储在 blob 存储中，并在表行中引用 blob 的 URI。
您需要存储海量的半结构化数据吗？如果是，Azure 表是有利的。

虽然 Azure 表在简单性和成本方面非常有利，但仍需要考虑一些限制。请参阅HERE 获取一些初步指导。

【讨论】：

【解决方案5】：

另一个考虑因素是延迟。曾经有一个站点，Microsoft 使用表存储和 SQL Azure 对各种对象大小的吞吐量和延迟进行微基准测试。由于该站点不再可用，因此我将根据我的记忆给您一个粗略的近似值。表存储的吞吐量往往比 SQL Azure 高得多。 SQL Azure 往往具有较低的延迟（高达 1/5）。

已经提到表存储很容易扩展。但是，SQL Azure 也可以通过Federations 进行扩展。请注意，Federations（实际上是sharding）给您的应用程序增加了很多复杂性。我也不确定联邦对性能的影响有多大，但我想会有一些开销。

如果优先考虑业务连续性，请考虑默认使用 Azure 存储you get cheap geo-replication。使用 SQL Azure，您可以使用SQL Data Sync 完成类似但更努力的事情。请注意，SQL 数据同步也会产生性能开销，因为它需要所有表上的触发器来监视数据更改。

【讨论】：

【解决方案6】：

我意识到这是一个老问题，但仍然是一个非常有效的问题，所以我正在添加我的回复。

CoderDennis 和其他人指出了一些事实 - Azure Tables 更便宜，Azure Tables 可以更大、更高效等。如果你 100% 确定你会坚持使用 Azure，那就选择 Tables。

但是，这假设您已经决定使用 Azure。通过使用 Azure Tables，您将自己锁定在 Azure 平台中。这意味着编写非常特定于 Azure Tables 的代码，不仅要移植到 Amazon，还必须重写代码的这些区域。另一方面，使用 LINQ 对 SQL 数据库进行编程将更容易移植到另一个云服务。

如果您已经决定使用云平台，这可能不是问题。

【讨论】：

【解决方案7】：

我建议结合 Azure 表查看 Azure 缓存。仅表就有 200-300 毫秒的延迟，偶尔会有更高的峰值，这会显着减慢响应时间/UI 交互性。对我来说，Cache + Table 似乎是一个成功的组合。

【讨论】：

【解决方案8】：

关于你的问题，我想谈谈如何用逻辑决定选择SQL Table，哪些需要使用Azure Table。

众所周知，SQL Table 是一个关系数据库引擎。但是如果你在一个表中有大数据，则 SQL 表不适用，因为 SQL 查询获取大数据很慢。

这时候你可以选择Azure Table，Azure Table查询比SQL Table查询大数据要快，比如在我们的网站上，有人订阅了很多文章，我们把文章作为feed给用户，每个用户都有文章标题和描述的副本，所以文章表中有很多数据，如果我们使用SQL表，每个查询执行可能需要30多秒。但是在 Azure Table 中通过 PartitionKey 和 RowKey 获取用户文章提要是如此之快。

从这个例子你可能知道如何在 SQL Table 和 Azure Table 之间进行选择。

【讨论】：

听起来您应该在 SQL 表中添加一些索引。

【解决方案9】：

我想知道我们是否会在适当的时候推出一些“独立于供应商”的云 API 库？

【讨论】：

【解决方案10】：

我认为您必须首先定义您的应用程序使用渠道是什么。您的数据模型会经常变化还是稳定？您必须能够执行超快速的插入和读取不是那么复杂吗？你需要高级谷歌搜索吗？存储 BLOBS？

这些是您必须自问和回答的问题（不仅是），以便决定您是否更有可能使用 NoSql 或 SQL 方法来存储数据。

请考虑这两种方法可以轻松共存，也可以使用 BLOB 存储进行扩展。

【讨论】：

【解决方案11】：

Azure Tables 和 SQL Azure 是两种不同的野兽。两者都适用于不同的场景，azure table 的一个缺点是您不能从 azure 迁移到任何其他平台，除非您在代码中编写可以处理此类转变的提供程序.

【讨论】：