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

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

这是一个很好的问题，是解决方案架构师在为Azure设计时必须做出的决策中越来越难的一项。

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

ATS完全是另一种动物。它具有巨大的可扩展性，但存储起来很便宜，但是频繁访问却变得昂贵。它还需要您的节点大量的CPU能力才能进行操作。当所有关系活动的委托移交给它们时，它基本上会迫使您的计算节点成为mini-db服务器。

因此，我认为，不需要巨大可伸缩性且大小不是超大的频繁访问的数据应运用于SQL Azure，否则应运用于Azure Table Services。

在您的特定示例中，来自金融交易的交易数据是ATS的理想之地，而元信息（帐户配置文件，姓名，地址等）则非常适合SQL Azure。

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

使用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联合不再可用）。新的基本，标准和高级层现已可用（有关详细信息，请参见此处）。

其中一些答案似乎并不完整，所以我加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表来充当SQL，则不要添加大量数据。如果您有大量数据（千兆字节），则不打算针对它获取高性能SQL查询。如果您不需要那些常规的SQL功能，则可以节省金钱。

关于事务，这只是另一种方式：SQL Azure支持事务；表存储没有。

SQL Azure基本上是在Windows Azure内部运行的SQL Server，因此，如果您已有使用SQL Server的应用程序，则SQL Azure提供了一个很好的迁移路径。但是，在SQL Azure上可以拥有的数据库大小（当前为150 GB）是有限制的，因此可以扩展的数据库量也有限制。

另一方面，表存储具有极高的可伸缩性，但是需要不同的思维方式。它不是关系数据库。请参见本文，以获得很好的介绍：http : //msdn.microsoft.com/zh-cn/magazine/ff796231.aspx

真正的答案是，“尽力不使用Azure表存储”。无论何时从关系型数据库迁移到无SQL数据库，您当然都必须更改对存储体系结构的看法。但是ATS所带来的问题远远超出了需要“另类思考”的范围。正如其他人指出的那样，它不仅是“ No-SQL”数据存储，它还是No-SQL存储的特技，残障和功能非常低下的实例。不必对ATS进行“不同思考”；ATS没有为您提供完成工作所需的工具，而是其他no-sql数据存储确实为您提供的工具。

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

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

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