我正处于Web应用程序的规划阶段，该应用程序将在Azure中托管，其中包含用于Web站点的ASP.NET和用于丰富用户体验的Silverlight . 我应该使用Azure Tables还是SQL Azure来存储我的应用程序数据？
Azure表存储似乎比SQL Azure便宜 . 它的可伸缩性也高于SQL Azure .
如果您已经进行了大量的关系数据库工作，SQL Azure更容易使用 . 如果您正在移植已经使用SQL数据库的应用程序，那么将其移动到SQL Azure将是明显的选择，但这是我推荐它的唯一情况 .
Azure Tables的主要限制是缺少二级索引 . 这是在PDC '09 and is currently listed as coming soon, but there hasn'宣布任何时间框架公告 . （见http://windowsazure.uservoice.com/forums/34192-windows-azure-feature-voting/suggestions/396314-support-secondary-indexes?ref=title）
我已经看到了建议使用混合系统，其中您使用表和blob存储来存储大量数据，但是使用SQL Azure进行索引，搜索和过滤 . 但是，我自己还没有机会尝试这种解决方案 .
将二级索引添加到表存储后，它将基本上是一个基于 Cloud 的NoSQL系统，并且比现在更有用 .
尽管SQL Azure表和表存储具有相似的名称，但它们的共同点很少 .
以下是两个可能对您有帮助的链接：
Table Storage, a 100x cost factor
Fat Entities on Table Storage
基本上，第一个问题应该想知道我的应用程序是否真的需要扩展？如果没有，那么去SQL Azure .
对于那些试图在两个选项之间做出决定的人，一定要将报告要求纳入等式 . SQL Azure Reporting和其他报告产品支持SQL Azure开箱即用 . 如果您需要生成复杂或灵活的报告，您可能希望避免使用表存储 .
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 .
另一个考虑因素是延迟 . 曾经有一个微软运行微型基准测试的站点使用表存储和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 Data Sync也会产生性能开销，因为它要求所有表上的触发器监视数据更改 .
我意识到这是一个老问题，但仍然是一个非常有效的问题，所以我正在添加我的回复 .
CoderDennis和其他人已经指出了一些事实 - Azure Tables更便宜，Azure Tables可以更大，更高效等 . 如果你100％肯定你会坚持使用Azure，那么请使用Tables .
但是，假设您已经决定使用Azure . 通过使用Azure表，您可以将自己锁定到Azure平台 . 这意味着编写非常特定于Azure表的代码，而不仅仅是端口到亚马逊，您将不得不重写代码的这些区域 . 另一方面，使用LINQ对SQL数据库进行编程将更容易移植到另一个 Cloud 服务 .
如果您已经决定使用 Cloud 平台，这可能不是问题 .
我建议将Azure Cache与Azure Table结合使用 . 仅表有200-300ms的延迟，偶尔会出现高峰，这可能会显着减慢响应时间/ UI交互性 . 对我来说，缓存表似乎是一个成功的组合 .
对于您的问题，我想谈谈如何决定使用逻辑选择SQL Table以及哪些需要使用Azure Table .
我们知道SQL Table是一个关系数据库引擎 . 但是如果你在一个表中有一个大数据，则SQL表不适用，因为SQL查询得到的大数据很慢 .
此时你可以选择Azure表，Azure表查询是如此之快，然后SQL表为大数据，例如，在我们的网站上，有人订阅了很多文章，我们把文章作为用户的馈送，每个用户都有一份副本文章 Headers 和描述，所以在文章表中有很多数据，如果我们使用SQL表，每个查询执行可能需要超过30秒 . 但在Azure Table中，PartitionKey和RowKey的用户文章提取速度非常快 .
从此示例中，您可能知道如何在SQL表和Azure表中进行选择 .
我想知道我们是否会在适当的时候最终得到一些“供应商独立”的 Cloud API库？
我认为您首先要定义应用程序使用漏斗的内容 . 您的数据模型是经常更改还是稳定的？你必须能够执行超快插入和读取不是那么复杂？你需要提前谷歌搜索吗？存储BLOBS？
这些是（并且不仅仅是）您必须自己提问和回答的问题，以便决定您是否更有可能在存储数据时使用NoSql或SQL方法 .
请考虑两种方法可以轻松共存，也可以使用BLOB存储进行扩展 .
10 回答
Azure表存储似乎比SQL Azure便宜 . 它的可伸缩性也高于SQL Azure .
如果您已经进行了大量的关系数据库工作，SQL Azure更容易使用 . 如果您正在移植已经使用SQL数据库的应用程序，那么将其移动到SQL Azure将是明显的选择，但这是我推荐它的唯一情况 .
Azure Tables的主要限制是缺少二级索引 . 这是在PDC '09 and is currently listed as coming soon, but there hasn'宣布任何时间框架公告 . （见http://windowsazure.uservoice.com/forums/34192-windows-azure-feature-voting/suggestions/396314-support-secondary-indexes?ref=title）
我已经看到了建议使用混合系统，其中您使用表和blob存储来存储大量数据，但是使用SQL Azure进行索引，搜索和过滤 . 但是，我自己还没有机会尝试这种解决方案 .
将二级索引添加到表存储后，它将基本上是一个基于 Cloud 的NoSQL系统，并且比现在更有用 .
尽管SQL Azure表和表存储具有相似的名称，但它们的共同点很少 .
以下是两个可能对您有帮助的链接：
Table Storage, a 100x cost factor
Fat Entities on Table Storage
基本上，第一个问题应该想知道我的应用程序是否真的需要扩展？如果没有，那么去SQL Azure .
对于那些试图在两个选项之间做出决定的人，一定要将报告要求纳入等式 . SQL Azure Reporting和其他报告产品支持SQL Azure开箱即用 . 如果您需要生成复杂或灵活的报告，您可能希望避免使用表存储 .
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 .
另一个考虑因素是延迟 . 曾经有一个微软运行微型基准测试的站点使用表存储和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 Data Sync也会产生性能开销，因为它要求所有表上的触发器监视数据更改 .
我意识到这是一个老问题，但仍然是一个非常有效的问题，所以我正在添加我的回复 .
CoderDennis和其他人已经指出了一些事实 - Azure Tables更便宜，Azure Tables可以更大，更高效等 . 如果你100％肯定你会坚持使用Azure，那么请使用Tables .
但是，假设您已经决定使用Azure . 通过使用Azure表，您可以将自己锁定到Azure平台 . 这意味着编写非常特定于Azure表的代码，而不仅仅是端口到亚马逊，您将不得不重写代码的这些区域 . 另一方面，使用LINQ对SQL数据库进行编程将更容易移植到另一个 Cloud 服务 .
如果您已经决定使用 Cloud 平台，这可能不是问题 .
我建议将Azure Cache与Azure Table结合使用 . 仅表有200-300ms的延迟，偶尔会出现高峰，这可能会显着减慢响应时间/ UI交互性 . 对我来说，缓存表似乎是一个成功的组合 .
对于您的问题，我想谈谈如何决定使用逻辑选择SQL Table以及哪些需要使用Azure Table .
我们知道SQL Table是一个关系数据库引擎 . 但是如果你在一个表中有一个大数据，则SQL表不适用，因为SQL查询得到的大数据很慢 .
此时你可以选择Azure表，Azure表查询是如此之快，然后SQL表为大数据，例如，在我们的网站上，有人订阅了很多文章，我们把文章作为用户的馈送，每个用户都有一份副本文章 Headers 和描述，所以在文章表中有很多数据，如果我们使用SQL表，每个查询执行可能需要超过30秒 . 但在Azure Table中，PartitionKey和RowKey的用户文章提取速度非常快 .
从此示例中，您可能知道如何在SQL表和Azure表中进行选择 .
我想知道我们是否会在适当的时候最终得到一些“供应商独立”的 Cloud API库？
我认为您首先要定义应用程序使用漏斗的内容 . 您的数据模型是经常更改还是稳定的？你必须能够执行超快插入和读取不是那么复杂？你需要提前谷歌搜索吗？存储BLOBS？
这些是（并且不仅仅是）您必须自己提问和回答的问题，以便决定您是否更有可能在存储数据时使用NoSql或SQL方法 .
请考虑两种方法可以轻松共存，也可以使用BLOB存储进行扩展 .