我应该何时使用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确实在分区级别(实体组事务)提供事务.有关更多信息,请参阅此MSDN文章.这不像SQL Azure事务那样健壮,但它确实允许在单个事务中进行批处理操作.

编辑自问这个问题(并回答)以来已经过去了一年多.一个比较点是定价.虽然SQL Azure仍然比ATS更昂贵,但SQL Azure的成本在过去一年中大幅下降.数据库现在已经分级定价,起价为$ 4.99 100MB,增加至$ 225 150GB(从$ 9.99加入/ GB的价格比去年大幅下降.全部定价细节都在这里.

编辑2014年8月另一年后,又一次更新.虽然Web /业务层继续存在,但它们正在落伍(并且SQL Federations不再可用).现在可以使用新的Basic,Standard和Premium层(有关详细信息,请参见此处).

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 表存储”。每当您从关系数据库迁移到非 SQL 数据库时，您当然必须改变对存储架构的看法。但 ATS 的问题远不止需要“以不同的方式思考”。正如其他人指出的那样，它不仅仅是一个“No-SQL”数据存储，它还是一个特别发育不良、有缺陷且功能非常低的 No-SQL 存储实例。这不是需要“以不同的方式思考”ATS 的问题；而是需要“以不同的方式思考”ATS 的问题。这是 ATS 没有为您提供完成工作所需的工具的问题 - 其他无 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 表存储。