我应该何时使用Sql Azure，何时应该使用表存储？

Question

我应该何时使用Sql Azure，何时应该使用表存储？ 我在想，将表存储用于事务处理方案，例如借记信用帐户类型的方案，并在数据不会用于交易目的时使用Sql Azure，例如报告。 你怎么看？

Answer 1

这是一个很好的问题，也是解决架构师在设计Azure时必须做出的更难和更难的决定之一。

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

ATS是一种不同的动物。它具有超大的可扩展性，存储起来很便宜，但经常访问会变得很昂贵。它还需要来自节点的大量CPU功率才能进行操作。它基本上会强制您的计算节点成为mini-db服务器，因为所有关系活动的委托都会转交给它们。

因此，在我看来，经常访问的数据不需要巨大的可伸缩性，而且规模不是很大，应该用于SQL Azure，否则就是Azure Table Services。

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

Answer 2

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

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

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

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

2014年8月编辑另一年后，另一次更新。虽然Web /业务层继续存在，但它们正在落伍（并且SQL Federations不再可用）。现在可以使用新的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表存储”。无论何时从关系数据库迁移到无数据库，您都必须改变对存储体系结构的看法。但ATS的问题不仅仅是需要“以不同的方式思考”。正如其他人所指出的那样，它不仅仅是一个“No-SQL”数据存储，它是No-SQL存储的一个特别发育迟缓，残缺且非常低功能的实例。这不是需要对ATS“有所不同”的问题;这是一个ATS没有给你工作所需工具的问题 - 其他no-sql数据存储做给你的工具。

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

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

现在，我知道Scott Guthrie是一个优秀的人，所以我希望桌面存储方面的所有这些停滞都是Azure修复它并提出一些非常酷的前言。这是我的希望（虽然我没有证据证明是这种情况）。但是现在，除非你没有选择，否则我强烈建议不要使用Azure Table Storage。使用Azure SQL;使用您自己的MongoDB实例或其他一些No-SQL DB;或使用Amazon DynamoDB。但是不要使用Azure表存储。