Azure 表还是 SQL Azure？
我正处于 Web 应用程序的规划阶段，该应用程序将托管在 Azure 中，并使用用于网站的 ASP.NET 和网站内的 Silverlight 来提供丰富的用户体验。我应该使用 Azure 表还是 SQL Azure 来存储应用程序数据？
I am at the planning stage of a web application that will be hosted in Azure with ASP.NET for the web site and Silverlight within the site for a rich user experience. Should I use Azure Tables or SQL Azure for storing my application data?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
Azure 表存储似乎比 SQL Azure 便宜。它还比 SQL Azure 具有更高的可扩展性。
如果您一直在进行大量关系数据库工作，那么 SQL Azure 会更容易使用。如果您要移植已经在使用 SQL 数据库的应用程序，那么将其移动到 SQL Azure 将是显而易见的选择，但这是我推荐它的唯一情况。
Azure 表的主要限制是缺乏二级索引。这是在 PDC '09 上宣布的，目前被列为即将推出，但尚未公布任何时间表。 （请参阅http ://windowsazure.uservoice.com/forums/34192-windows-azure-feature-voting/suggestions/396314-support-secondary-indexes?ref=title）
我已经看到了混合系统的使用建议您使用表和 blob 存储来存储大量数据，但使用 SQL Azure 来进行索引、搜索和筛选。但是，我自己还没有机会尝试该解决方案。
一旦二级索引添加到表存储中，它本质上将是一个基于云的 NoSQL 系统，并且将比现在有用得多。
Azure Table Storage appears to be less expensive than SQL Azure. It is also more highly scalable than SQL Azure.
SQL Azure is easier to work with if you've been doing a lot of relational database work. If you were porting an application that was already using a SQL database, then moving it to SQL Azure would be the obvious choice, but that's the only situation where I would recommend it.
The main limitation on Azure Tables is the lack of secondary indexes. This was announced at PDC '09 and is currently listed as coming soon, but there hasn't been any time-frame announcement. (See http://windowsazure.uservoice.com/forums/34192-windows-azure-feature-voting/suggestions/396314-support-secondary-indexes?ref=title)
I've seen the proposed use of a hybrid system where you use table and blob storage for the bulk of your data, but use SQL Azure for indexes, searching and filtering. However, I haven't had a chance to try that solution yet myself.
Once the secondary indexes are added to table storage, it will essentially be a cloud based NoSQL system and will be much more useful than it is now.
尽管名称相似，SQL Azure 表和表存储却没有什么共同点。
以下两个链接可能会对您有所帮助：
，第一个问题应该是我的应用程序真的需要扩展吗？如果不需要，那么就选择 SQL Azure。
Despite similar names SQL Azure Tables and Table Storage have very little in common.
Here are a two links that might help you:
Basically, the first question should wonder about is Does my app really need to scale? If not, then go for SQL Azure.
对于那些试图在这两个选项之间做出决定的人，请务必将报告要求纳入考虑范围。 SQL Azure 报告和其他报告产品支持 SQL Azure 开箱即用。如果您需要生成复杂或灵活的报告，您可能希望避免表存储。
For those trying to decide between the two options, be sure to factor reporting requirements into the equation. SQL Azure Reporting and other reporting products support SQL Azure out of the box. If you need to generate complex or flexible reports, you'll probably want to avoid Table Storage.
Azure 表比 SQL Azure 更便宜、更简单并且可扩展性更好。 SQL Azure 是一个托管 SQL 环境，本质上是多租户，因此您应该分析您的性能要求是否适合 SQL Azure。 SQL Azure 的高级版本已经发布，并且在撰写本文时处于预览状态（请参阅
我认为在 SQL Azure 和 Azure 表之间做出决定的决定性因素如下：
尽管 Azure 表在简单性和成本方面非常有利，但仍需要考虑一些限制。请参阅此处获取一些初步指导。
Azure tables are cheaper, simpler and scale better than SQL Azure. SQL Azure is a managed SQL environment, multi-tenant in nature, so you should analyze if your performance requirements are fit for SQL Azure. A premium version of SQL Azure has been announced and is in preview as of this writing (see HERE).
I think the decisive factors to decide between SQL Azure and Azure tables are the following:
Although Azure tables are tremendously beneficial in terms of simplicity and cost, there are some limitations that need to be taken into account. Please see HERE for some initial guidance.
另一项考虑因素是延迟。 Microsoft 曾经在一个网站上运行过微基准测试，针对表存储和 SQL Azure 的各种对象大小的吞吐量和延迟进行了测试。由于该网站已不再可用，我将根据我的记忆向您提供一个粗略的近似值。表存储的吞吐量往往比 SQL Azure 高得多。 SQL Azure 的延迟往往较低（高达 1/5）。
已经提到表存储很容易扩展。不过，SQL Azure 也可以通过联合进行扩展。请注意，联合（实际上是分片）给您的应用程序增加了很多复杂性。我也不确定联邦对性能的影响有多大，但我想会有一些开销。
如果优先考虑业务连续性，请考虑使用 Azure 存储 默认情况下您会获得廉价的异地复制。借助 SQL Azure，您可以通过 SQL 数据同步 完成类似的任务，但需要付出更多努力。请注意，SQL 数据同步也会产生性能开销，因为它需要所有表上的触发器来监视数据更改。
One other consideration is latency. There used to be a site that Microsoft ran with microbenchmarks on throughput and latency of various object sizes with table store and SQL Azure. Since that site's no longer available, I'll just give you a rough approximation from what I recall. Table store tends to have much higher throughput than SQL Azure. SQL Azure tends to have lower latency (by as much as 1/5th).
It's already been mentioned that table store is easy to scale. However, SQL Azure can scale as well with Federations. Note that Federations (effectively sharding) adds a lot of complexity to your application. I'm also not sure how much Federations affects performance, but I imagine there's some overhead.
If business continuity is a priority, consider that with Azure Storage you get cheap geo-replication by default. With SQL Azure, you can accomplish something similar but with more effort with SQL Data Sync. Note that SQL Data Sync also incurs performance overhead since it requires triggers on all of your tables to watch for data changes.
我意识到这是一个老问题，但仍然是一个非常有效的问题，所以我添加了我的答复。
CoderDennis 和其他人指出了一些事实 - Azure 表更便宜，Azure 表可以更大、更高效等。如果你 100% 确定你会坚持使用 Azure，那就选择表。
然而，这假设您已经决定使用 Azure。通过使用 Azure Tables，您将自己锁定在 Azure 平台中。这意味着编写专门针对 Azure 表的代码，不仅要移植到 Amazon，而且还必须重写代码的这些区域。另一方面，使用 LINQ 对 SQL 数据库进行编程将更容易地移植到另一个云服务。
如果您已经决定使用云平台，这可能不是问题。
I realize this is an old question, but still a very valid one, so I'm adding my reply to it.
CoderDennis and others have pointed out some of the facts - Azure Tables is cheaper, and Azure Tables can be much larger, more efficient etc. If you are 100% sure you will stick with Azure, go with Tables.
However this assumes you have already decided on Azure. By using Azure Tables, you are locking yourself into the Azure platform. It means writing code very specific to Azure Tables that is not just going to port over to Amazon, you will have to rewrite those areas of your code. On the other hand programming for a SQL database with LINQ will port over much more easily to another cloud service.
This may not be an issue if you've already decided on your cloud platform.
我建议结合使用 Azure 缓存和 Azure 表。仅表就有 200-300 毫秒的延迟，偶尔会出现更高的峰值，这会显着减慢响应时间/UI 交互性。对我来说，缓存+表似乎是一个成功的组合。
I suggest looking at Azure Cache in combination with Azure Table. Table alone has 200-300ms latencies, with occasional spikes higher, which can significantly slow down response times / UI interactivity. Cache + Table seems to be a winning combination, for me.
对于你的问题，我想谈谈如何用逻辑来决定选择SQL表以及哪些需要使用Azure表。
我们知道SQL Table是一个关系数据库引擎。但如果一张表中有大数据，则 SQL 表不适用，因为 SQL 查询获取大数据很慢。
这时候你可以选择Azure Table，Azure Table的查询速度比大数据的SQL Table快，比如我们的网站，有人订阅了很多文章，我们把文章作为feed给用户，每个用户都有一份文章标题和描述，所以文章表中有大量数据，如果我们使用SQL Table，每个查询执行可能需要30秒以上。但在 Azure Table 中，通过 PartitionKey 和 RowKey 获取用户文章提要非常快。
从这个例子中您可能知道如何在 SQL 表和 Azure 表之间进行选择。
For your question, I want to talk about how to decide with logic choose SQL Table and which need to use Azure Table.
As we know SQL Table is a relational database engine. but if you have a big data in one table the SQL Table is not applicable, because SQL query get big data is slow.
At this time you can choose Azure Table, the Azure Table query is so fast then SQL Table for big data, for example, in our website, someone subscribed many articles, we make the article as feed to user, every user have a copy of article title and description, so in the article table there are lots of data, if we use SQL Table, each query execution maybe take more than 30 seconds. But in Azure Table get users article feed by PartitionKey and RowKey is so fast.
From this example you may know how to choose between in SQL Table and Azure Table.
我想知道我们是否会在适当的时候最终得到一些“独立于供应商”的云 API 库？
I wonder whether we are going to end up with some "vendor independent" cloud api libraries in due course?
我认为您必须首先定义您的应用程序使用渠道是什么。您的数据模型会频繁更改还是稳定的？你必须能够执行超快的插入和读取不是那么复杂吗？您需要像谷歌这样的高级搜索吗？存储 BLOBS？
这些是您必须问自己并回答的问题（而且不仅仅是），以便决定是否更有可能使用 NoSql 或 SQL 方法来存储数据。
请注意，这两种方法可以轻松共存，并且还可以通过 BLOB 存储进行扩展。
I think that you have first to define what your application usage funnels are. Will your data model be subjected to frequent changes or it is a stable one? You have to be able to perform ultra fast inserts and reads are not so complicated? Do you need advance google like search? Storing BLOBS?
Those are the questions (and not only) that you have to ask and answer yourself in order to decide if you are more likely going to use NoSql or SQL approach in storing your data.
Please consider that both approaches can easily coexist and can be extended with BLOB storage as well.
Azure 表和 SQL Azure 都是两种不同的野兽。两者都适用于不同的场景，azure 表的一个缺点是您无法从 azure 迁移到任何其他平台，除非您在代码中编写可以处理此类转换的提供程序。
Both Azure Tables and SQL Azure are two different beasts.Both are meant for different scenarios, one con to azure table is that you cannot move from azure to any other platform, unless you write providers in your code that can handle such shifts.