什么时候应该使用Sql Azure，什么时候应该使用表存储？
什么时候应该使用Sql Azure，什么时候应该使用表存储？ 我在想，使用表存储的交易处理scheme，例如借方贷方帐户类的情况，并使用SQL Azure时，数据将不会用于交易的目的，例如报告。 你怎么看？
这是一个很好的问题，在Azuredevise中，解决scheme架构师必须做出的决策更加艰难和复杂。
有多种维度需要考虑：不利的一面是，SQL Azure对于千兆字节的存储来说是相对昂贵的，并不能很好地扩展和限制到150gig /数据库，而这一点非常重要，对SQL没有交易费用Azure和您的开发人员已经知道如何对其进行编码。
ATS是一个不同的动物。 具有超级可扩展性，存储成本低廉，但经常使用昂贵。 它还需要从您的节点处理大量的CPU电源。 它基本上强制您的计算节点成为小型数据库服务器，因为所有关系活动的委派都会转交给它们。
所以，在我看来，经常访问的数据不需要很大的可伸缩性，而且不是超大的应该是SQL Azure，否则Azure表服务。
您的具体示例来自金融交易的交易数据是ATS的理想场所，而元数据（账户信息，名称，地址等）非常适合SQL Azure。
伊戈尔和马克给出了很好的答案。 让我再补充一点…
使用SQL数据库（以前称为SQL Azure），您现在可以拥有高达500GB的数据库。 要超越这一点，你需要分割你的数据。 注意：最初我build议使用SQL Federated的分片，但是这个特性已经被淘汰了。
ATS确实在分区级提供交易（实体组交易）。 有关更多信息，请参阅此MSDN文章 。 这不像SQL Azure事务那样健壮，但它确实允许在单个事务中执行批处理操作。
编辑这个问题已经过了一年多了，被问及（并回答）。 一个比较点是定价。 尽pipeSQL Azure比ATS更昂贵，但SQL Azure的成本在过去一年中大幅下降。 数据库现在已经有了分层定价，从100MB的4.99美元开始，150GB增加到225美元（比去年的9.99美元/ GB的价格大幅下降，详细的定价细节在这里 。
编辑八月2014另一年后，另一个更新。 虽然networking/业务层继续存在，但他们正在被淘汰（和SQL联盟不再可用）。 新的基本版，标准版和高级版现已上市（详情请见这里 ）。
其中一些答案似乎并不完整，所以我会加2美分。
Azure Table's好点：
- 优点是能够存储大量的小数据; Azure表基于Azure Blob，但面向较小的数据
- 比Azure SQL Server便宜得多
- 只要你知道分区键和行键，数据访问就非常快。
- 如果将两个不同的“模式”放在同一个分区键中，则
Entity transactions是可能的。 - 总行大小不到980K（SQL行）
- 每个属性不到64K（SQL列）
- 它可以作为一个穷人的SQL。
天青桌的坏点：
- SQL是弱点。 不要期望在任何大的SQL表上使用它，否则你将会遇到性能问题。
- 有限的SQL是可用的，不要期望任何types的连接，除了你在Linq中实现的
- Azure Table SQL不能像存储无限数量的数据那样进行扩展
- 只要不在WHERE子句中同时指定分区键和行键，就会发生缓慢的表扫描
- 在添加更多行时，希望表扫描性能降低
- 不要指望Azue Table查询在添加更多行时速度很快
- 底线，如果您使用Azure Table来执行SQL，则不会添加大量数据。 如果你有很多数据（千兆字节），只是不打算获得高性能的SQL查询。 如果你不需要这些常规的SQLfunction，你将会省钱。
谈到事务时，情况恰恰相反：SQL Azure支持事务处理; 表存储没有。
SQL Azure基本上是在Windows Azure内运行的SQL Server，所以如果你有一个使用SQL Server的现有应用程序 ，SQL Azure提供了一个很好的迁移path 。 但是，在SQL Azure上有多大的数据库（目前为150 GB）是有限制的，因此它的扩展能力是有限的。
另一方面，表存储是非常可扩展的，但需要不同的思考方式。 这不是一个关系数据库 。 请参阅例如这篇文章的一个很好的介绍： http : //msdn.microsoft.com/en-us/magazine/ff796231.aspx
真正的答案是“尽量不要使用Azure表存储”。 每当你从一个关系数据库转移到一个没有数据库的数据库，你当然需要改变你对存储架构的看法。 但是，与ATS的问题走的方式，超越只需要“思维方式不同”。 正如其他人所指出的那样，它不仅仅是一个“无SQL”数据存储，它是一个特别发育迟缓，function差，function非常低的No-SQL存储实例。 这不是关于安非他明类兴奋剂“需要不同思考”的问题; 这是ATS不给你所需的工具来完成你的工作 – 其他非SQL数据存储所提供的工具。
关于ATS的唯一好处是，您可以非常快速地将大量的数据join其中，并以最低的存储费用。 但是，除非您足够幸运地拥有与分区键/行键存储模型相匹配的用例，否则基本上不会希望再次获取这些数据。 如果你不这样做 – 而且我怀疑只有很less的人会这样做 – 你将会进行大量的分区扫描，并自己处理数据。
除此之外，Azure Table Storage在开发方面似乎处于死胡同。 如果您在Azure反馈论坛（ http://feedback.windowsazure.com/forums/217298-storage/suggestions/396314-support-secondary-indexes ）上查看“支持二级索引”请求，则可以看到对二级指标早在2011年就已经答应了，但是还没有取得进展。 对表格存储的其他要求也没有任何进展。
现在，我知道Scott Guthrie是一个高素质的人，所以我希望Table Storage的所有这些停滞都是Azure修复它的前奏，并且提供了一些非常酷的东西。 这是我的希望（尽pipe我没有这方面的证据）。 但是现在，除非您没有select，否则我强烈build议您不要使用Azure Table Storage。 使用Azure SQL; 使用你自己的MongoDB实例或其他一些No-SQL DB; 或使用Amazon DynamoDB。 但是不要使用Azure表存储。
