blocks|key|1650202|text|Azure表存储似乎比SQL+Azure便宜。它也比SQL+Azure具有更高的可扩展性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1650203|如果你一直在做大量的关系数据库工作，SQL+Azure会更容易使用。如果您正在移植一个已经在使用SQL数据库的应用程序，那么将其移动到SQL+Azure将是显而易见的选择，但这是我唯一推荐它的情况。|1650204|Azure表的主要限制是缺少辅助索引。这是在PDC+'09上宣布的，目前被列为即将到来，但还没有任何时间框架宣布。(参见http://windowsazure.uservoice.com/forums/34192-windows-azure-feature-voting/suggestions/396314-support-secondary-indexes?ref=title)|offset|length|1650205|我已经看到了混合系统的提议使用，你使用表和blob存储你的大部分数据，但是使用SQL+Azure来索引，搜索和过滤。然而，我自己还没有机会尝试这个解决方案。|1650206|一旦将二级索引添加到表存储中，它本质上将是一个基于云的NoSQL系统，并且将比现在更有用。|1650207|entityMap|0|LINK|mutability|MUTABLE|url|http://windowsazure.uservoice.com/forums/34192-windows-azure-feature-voting/suggestions/396314-support-secondary-indexes?ref=title|1|http://en.wikipedia.org/wiki/NoSQL^0|0|0|1O|3M|0|0|0|R|5|1|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@$F|Y|G|Z|1|10]]|A|$]]|$1|H|3|I|5|6|7|11|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|12|8|@]|9|@$F|13|G|14|1|15]]|A|$]]|$1|L|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|M|$N|$5|O|P|Q|A|$R|S]]|T|$5|O|P|Q|A|$R|U]]]]

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 <a href="http://windowsazure.uservoice.com/forums/34192-windows-azure-feature-voting/suggestions/396314-support-secondary-indexes?ref=title" rel="noreferrer">http://windowsazure.uservoice.com/forums/34192-windows-azure-feature-voting/suggestions/396314-support-secondary-indexes?ref=title</a>)

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 <a href="http://en.wikipedia.org/wiki/NoSQL" rel="noreferrer">NoSQL</a> system and will be much more useful than it is now.

blocks|key|3058693|text|尽管名称相似，但SQL+Azure表和表存储几乎没有什么共同之处。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3058694|这里有两个可能对你有帮助的链接：|3058695|3058696|Table+Storage,+a+100x+cost+factor|unordered-list-item|offset|length|3058697|Fat+Entities+on+Table+Storage|3058698|3058699|基本上，第一个问题应该是我的应用程序真的需要扩展吗？如果不是，那么使用SQL+Azure。|3058700|entityMap|0|LINK|mutability|MUTABLE|url|http://vermorel.com/journal/2009/9/17/table-storage-or-the-100x-cost-factor.html|1|http://code.google.com/p/lokad-cloud/wiki/FatEntities^0|0|0|0|0|X|0|0|0|T|1|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|10|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|11|8|@]|9|@$H|12|I|13|1|14]]|A|$]]|$1|J|3|K|5|G|7|15|8|@]|9|@$H|16|I|17|1|18]]|A|$]]|$1|L|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1A|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|V]]|W|$5|R|S|T|A|$U|X]]]]

Despite similar names SQL Azure Tables and Table Storage have very little in common. 

Here are a two links that might help you:

<ul>
<li><a href="http://vermorel.com/journal/2009/9/17/table-storage-or-the-100x-cost-factor.html" rel="noreferrer">Table Storage, a 100x cost factor</a></li>
<li><a href="http://code.google.com/p/lokad-cloud/wiki/FatEntities" rel="noreferrer">Fat Entities on Table Storage</a></li>
</ul>

Basically, the first question should wonder about is Does my app really need to scale? If not, then go for SQL Azure.

blocks|key|3058725|text|对于那些试图在这两个选项之间做出选择的人，请确保将报告要求纳入等式中。SQL+Azure+Reporting和其他报表产品开箱即可支持SQL+Azure。如果您需要生成复杂或灵活的报告，您可能希望避免使用表存储。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3058726|entityMap|0|LINK|mutability|MUTABLE|url|http://www.microsoft.com/en-us/sqlazure/reporting.aspx^0|Z|J|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

For those trying to decide between the two options, be sure to factor reporting requirements into the equation. <a href="http://www.microsoft.com/en-us/sqlazure/reporting.aspx">SQL Azure Reporting</a> 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.

blocks|key|3058892|text|Azure表比SQL+Azure更便宜，更简单，可伸缩性更好。SQL+Azure是一个托管的SQL环境，本质上是多租户的，所以你应该分析你的性能需求是否适合SQL+Azure。SQL+Azure的高级版本已经发布，并在撰写本文时处于预览中(请参阅HERE)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3058893|我认为在SQL+Azure和Azure表之间做出决定的决定性因素如下：|3058894|3058895|您是否需要进行复杂的连接和使用辅助索引？如果是，则SQL+Azure是最佳选择。|unordered-list-item|3058896|是否需要存储过程？如果是，则返回SQL+Azure。|3058897|您是否需要自动伸缩功能？Azure表是最佳选择。Azure表中的|3058898|行大小不能超过4MB。如果您需要在一行中存储大数据，最好将其存储在blob存储中，并在表行中引用blob的URI。|3058899|您需要存储大量的半结构化数据吗？如果是，则Azure表为advantageous.|3058900|3058901|虽然Azure表在简单性和成本方面非常有益，但也有一些需要考虑的限制。请参阅HERE获取一些初始指导。|3058902|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/windowsazure/dn369873.aspx|1|http://msdn.microsoft.com/en-us/library/windowsazure/dd179338.aspx^0|3F|4|0|0|0|0|0|0|0|0|0|0|12|4|1|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@$A|15|B|16|1|17]]|C|$]]|$1|D|3|E|5|6|7|18|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|19|8|@]|9|@]|C|$]]|$1|G|3|H|5|I|7|1A|8|@]|9|@]|C|$]]|$1|J|3|K|5|I|7|1B|8|@]|9|@]|C|$]]|$1|L|3|M|5|I|7|1C|8|@]|9|@]|C|$]]|$1|N|3|O|5|I|7|1D|8|@]|9|@]|C|$]]|$1|P|3|Q|5|I|7|1E|8|@]|9|@]|C|$]]|$1|R|3|-4|5|6|7|1F|8|@]|9|@]|C|$]]|$1|S|3|T|5|6|7|1G|8|@]|9|@$A|1H|B|1I|1|1J]]|C|$]]|$1|U|3|-4|5|6|7|1K|8|@]|9|@]|C|$]]]|V|$W|$5|X|Y|Z|C|$10|11]]|12|$5|X|Y|Z|C|$10|13]]]]

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 <a href="http://msdn.microsoft.com/en-us/library/windowsazure/dn369873.aspx" rel="nofollow">HERE</a>).

I think the decisive factors to decide between SQL Azure and Azure tables are the following:

<ul>
<li>Do you need to do complex joins and use secondary indexes? If yes, SQL Azure is the best option.</li>
<li>Do you need stored procedures? If yes, SQL Azure.</li>
<li>Do you need auto-scaling capabilities? Azure tables is the best option.</li>
<li>Rows within an Azure table cannot exceed 4MB in size. If you need to store large data within a row, it is better to store it in blob storage and reference the blob's URI in the table row.</li>
<li>Do you need to store massive amounts of semi-structured data? If yes, Azure tables are advantageous.</li>
</ul>

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 <a href="http://msdn.microsoft.com/en-us/library/windowsazure/dd179338.aspx" rel="nofollow">HERE</a> for some initial guidance.

blocks|key|1650273|text|另一个考虑因素是延迟。微软曾经有一个网站，通过表存储和SQL+Azure对不同对象大小的吞吐量和延迟进行微基准测试。由于该网站不再可用，我将根据我的记忆给您一个粗略的近似。表存储往往比SQL+Azure具有更高的吞吐量。SQL+Azure往往具有更低的延迟(高达1/5)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1650274|前面已经提到过，表存储很容易扩展。但是，SQL+Azure也可以使用Federations进行扩展。请注意，联合(实际上是sharding)会给您的应用程序增加很多复杂性。我也不确定联合对性能有多大影响，但我想会有一些开销。|offset|length|1650275|如果业务连续性是一个优先事项，那么默认情况下可以考虑使用Azure+Storage+you+get+cheap+geo-replication。使用SQL+Azure，您可以使用SQL+Data+Sync完成类似的任务，但需要付出更多的努力。请注意，SQL数据同步还会产生性能开销，因为它需要所有表上的触发器来监视数据更改。|1650276|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/windowsazure/hh597452.aspx|1|http://en.wikipedia.org/wiki/Shard_%2528database_architecture%2529|2|http://blogs.msdn.com/b/windowsazurestorage/archive/2011/09/15/introducing-geo-replication-for-windows-azure-storage.aspx|3|http://msdn.microsoft.com/en-us/library/hh667320^0|0|Y|B|0|1P|8|1|0|16|T|2|2H|D|3|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]|$D|10|E|11|1|12]]|A|$]]|$1|F|3|G|5|6|7|13|8|@]|9|@$D|14|E|15|1|16]|$D|17|E|18|1|19]]|A|$]]|$1|H|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]|P|$5|K|L|M|A|$N|Q]]|R|$5|K|L|M|A|$N|S]]|T|$5|K|L|M|A|$N|U]]]]

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 <a href="http://msdn.microsoft.com/en-us/library/windowsazure/hh597452.aspx" rel="nofollow">Federations</a>. Note that Federations (effectively <a href="http://en.wikipedia.org/wiki/Shard_%28database_architecture%29" rel="nofollow">sharding</a>) 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 <a href="http://blogs.msdn.com/b/windowsazurestorage/archive/2011/09/15/introducing-geo-replication-for-windows-azure-storage.aspx" rel="nofollow">you get cheap geo-replication</a> by default. With SQL Azure, you can accomplish something similar but with more effort with <a href="http://msdn.microsoft.com/en-us/library/hh667320" rel="nofollow">SQL Data Sync</a>. Note that SQL Data Sync also incurs performance overhead since it requires triggers on all of your tables to watch for data changes.

blocks|key|1650312|text|我意识到这是一个老问题，但仍然是一个非常有效的问题，所以我在此补充我的回答。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1650313|CoderDennis和其他人已经指出了一些事实-+Azure表更便宜，Azure表可以更大，更高效等等。如果你100%25确定你会坚持使用Azure，那就用表吧。|1650314|然而，这假设你已经决定使用Azure。通过使用Azure表，您将自己锁定在Azure平台中。这意味着编写非常特定于Azure表的代码，而不仅仅是移植到Amazon，您将不得不重写代码的这些部分。另一方面，使用LINQ为SQL数据库编程将更容易移植到另一个云服务。|1650315|如果你已经决定了你的云平台，这可能不是问题。|1650316|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

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.

blocks|key|1089382|text|我建议将Azure+Cache与Azure+Table结合使用。单单Table就有200-300ms的延迟，偶尔会出现更高的峰值，这会显著降低响应时间/+UI交互性。对我来说，Cache+%2B+Table似乎是一个成功的组合。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1089383|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|344006|text|对于你的问题，我想谈谈如何用逻辑决定选择SQL表，以及哪些需要使用Azure表。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|344007|众所周知，SQL表是一个关系数据库引擎。但是如果你在一个表中有一个大数据，那么SQL表就不适用了，因为SQL查询获取大数据的速度很慢。|344008|此时你可以选择Azure+Table，Azure+Table的查询速度比大数据的SQL+Table快，例如，在我们的网站上，有人订阅了很多文章，我们把文章作为feed提供给用户，每个用户都有一份文章标题和描述的副本，所以在文章表中有很多数据，如果我们使用SQL+Table，每次查询执行可能需要30秒以上。但是在Azure+Table中，通过PartitionKey和RowKey获取用户的文章提要是如此之快。|344009|从这个例子中，你可以知道如何在SQL表和Azure表之间进行选择。|344010|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

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.

blocks|key|1089394|text|我想知道我们是否会在适当的时候拥有一些“独立于供应商”的云api库？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1089395|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I wonder whether we are going to end up with some "vendor independent" cloud api libraries in due course?

blocks|key|1650551|text|我认为你必须首先定义你的应用程序使用漏斗是什么。您的数据模型是频繁更改还是稳定的？你必须能够执行超快的插入和读取，不是很复杂吗？你需要像搜索这样的高级谷歌吗？存储BLOBS？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1650552|为了决定您更有可能使用NoSql还是SQL方法来存储数据，您必须自己提出和回答这些问题(而且不仅仅是这些问题)。|1650553|请考虑到，这两种方法可以很容易地共存，并且也可以使用BLOB存储进行扩展。|1650554|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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.

blocks|key|1650590|text|Azure表和SQL+Azure是两个不同的beasts.Both，用于不同的场景，azure表的一个缺点是您不能从azure迁移到任何其他平台，除非您在代码中编写可以处理此类迁移的提供程序。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1650591|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

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?

Azure Tables or SQL Azure?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我正处于web应用程序的规划阶段，该应用程序将托管在Azure中，其中ASP.NET用于网站，Silverlight在网站中用于丰富的用户体验。我应该使用Azure表还是SQL Azure来存储我的应用程序数据？

问Azure表还是SQL Azure？
EN

回答 11

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Azure表还是SQL Azure？EN

回答 11

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Azure表还是SQL Azure？
EN