Azure表还是SQL Azure?

Azure表存储似乎比SQL Azure便宜。它也比SQL Azure具有更高的可扩展性。

如果您一直在做大量的关系数据库工作,那么使用SQLAzure更容易。如果您正在移植一个已经在使用SQL数据库的应用程序,那么将其移动到SQL Azure将是一个显而易见的选择,但这是我唯一推荐的情况。

对Azure表的主要限制是缺少辅助索引。这是在pdc'09上宣布的,目前列为即将发布,但还没有任何时间范围的公告。(见 http://windowsazure.uservoice.com/forums/34192-windows-azure-feature-voting/suggestions/396314-support-secondary-indexes?ref=title )

我已经看到了一个混合系统的提议使用,在这个混合系统中,您将表和blob存储用于大量数据,但将SQLAzure用于索引、搜索和筛选。然而,我自己还没有机会尝试这个解决方案。

一旦将辅助索引添加到表存储中,它基本上将是基于云的 NoSQL 系统,将比现在更有用。

尽管名称相似,但SQL Azure表和表存储几乎没有共同点。

下面有两个链接可以帮助您:

• Table Storage, a 100x cost factor
• Fat Entities on Table Storage

基本上,第一个问题应该是 我的应用程序真的需要缩放吗? 如果没有,那么使用SQL Azure。

对于那些试图在这两个选项之间做出决定的人,一定要将报告要求考虑到等式中。 SQL Azure Reporting 其他报表产品也支持现成的SQL Azure。如果需要生成复杂或灵活的报告,您可能希望避免表存储。

与SQLAzure相比,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 对于一些初步的指导。

另一个考虑因素是延迟。曾经有一个站点,微软使用Microsoft运行,它使用表存储和SQLAzure对不同对象大小的吞吐量和延迟进行微基准测试。因为那个网站已经不可用了,我将根据我的记忆给你一个粗略的近似值。表存储的吞吐量往往比SQLAzure高得多。SQL Azure的延迟往往较低(高达1/5)。

已经提到表存储很容易扩展。但是,SQL Azure也可以使用 Federations . 注意联邦政府(有效地 sharding )给应用程序增加了很多复杂性。我也不确定联合会对性能有多大的影响,但我认为会有一些开销。

如果业务连续性是一个优先事项,请考虑使用Azure存储 you get cheap geo-replication 默认情况下。使用SQL Azure,您可以完成类似的任务,但需要付出更多的努力 SQL Data Sync . 注意,SQL数据同步也会带来性能开销,因为它需要所有表上的触发器来监视数据更改。

我意识到这是一个老问题,但仍然是一个非常有效的问题,所以我要添加我的回复。

coderdennis和其他人已经指出了一些事实-Azure表更便宜,并且Azure表可以更大、更高效等。如果你100%确信你会坚持使用Azure,那么就使用表。

但是,这假设您已经决定使用Azure。通过使用Azure表,您将自己锁定到Azure平台中。这意味着要编写特定于Azure表的代码,而不仅仅是要移植到Amazon,您必须重写代码中的那些区域。另一方面,使用LINQ为SQL数据库编程将更容易地移植到另一个云服务。

如果您已经决定使用云平台,这可能不是问题。

我建议结合使用Azure表来查看Azure缓存。单表就有200-300ms的延迟,偶尔会出现更高的峰值,这可以显著降低响应时间/ui交互。对我来说,cache+table似乎是一个成功的组合。

对于您的问题,我想谈谈如何用逻辑来决定选择SQL表,以及哪些需要使用Azure表。

正如我们所知,SQL表是一个关系数据库引擎。但是,如果一个表中有一个大数据,那么SQL表就不适用,因为SQL查询获取大数据的速度很慢。

此时您可以选择azure表,azure表查询速度比sql表快,比如在我们的网站上,有人订阅了很多文章,我们把文章作为feed给用户,每个用户都有文章标题和描述的副本,所以在文章表中有很多数据,如果我们使用sql表,每个查询执行可能需要30多秒。但在Azure表中,让用户按分区键获取文章提要,rowkey速度很快。

从这个例子中,您可能知道如何在SQL表和Azure表中进行选择。

我想知道我们是否会在适当的时候最终得到一些“独立于供应商”的云API库?

我认为您必须首先定义应用程序使用漏斗是什么。您的数据模型会经常发生变化还是稳定的变化?您必须能够执行超高速插入,而且读取也不那么复杂?你需要像谷歌一样的高级搜索吗?储存斑点?

这些问题(不仅如此)是您为了决定是否更可能在存储数据时使用NoSQL或SQL方法而必须自问自答的。

请考虑这两种方法都可以很容易地共存,并且也可以扩展到BLOB存储。