SQL Azure 和 Azure 表存储如何比较？
目前，我有一个在本地计算机上的 IIS 中运行的原型，并使用 SQL Server Express 2005 在三个 SQL 表中存储数据。我使用最多使用这三个表中的两个的事务来运行查询。
现在我需要将我的原型移至 Windows Azure，但无法决定选择哪个 - SQL Azure 还是 Azure 表存储。
他们如何比较？我如何决定选择哪一个？
Currently I have a prototype that runs in IIS on my local machine and uses SQL Server Express 2005 for storing data in three SQL tables. I run queries with transactions that employ up to two of those three tables.
Now I need to move my prototype to Windows Azure and can't decide which to choose - SQL Azure or Azure Table Storage.
How do they compare? How do I decide which to choose?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Windows Azure 的 SQL 数据库是一个关系数据库，具有您期望从关系数据库获得的所有功能（多个索引、存储过程、强大的查询等）。 Azure 表存储是一种非关系型、大规模可扩展（每个帐户高达 100TB）的存储设施，其中实体通过分区键（实体的托管）和行键进行定位。
如果您想要一个非常简单的存储机制，不需要复杂的关系操作，Azure 表存储将非常适合。
编辑 2012 年 6 月 7 日：更新了春季发布定价
成本也有差异。 SQL 数据库起价为 4.99 美元/100MB，可分层扩展（5GB 约为 26 美元，50GB 为 125 美元，150GB 为 225 美元），但没有交易成本。 Azure 表存储的运行价格为 0.125 美元/GB（或 0.09/GB，无异地复制），随着数量的增加，每 GB 价格下降，但交易成本为 0.01 美元/100,000 美元（对于小容量系统来说是标称值，但对于非常大的系统来说可能会很重要）高容量系统）。完整的定价详情位于此处。
MSDN 杂志上有一篇最近的文章，其中详细介绍了有关使用的信息 值得
如果您打算直接迁移现有的内容，SQL 数据库将与 SQL Server Express 2005 中的内容非常匹配。但是，由于此时它只是一个原型，因此 重新评估您的需求。
Windows Azure's SQL Database is a relational database, with all the things you'd expect from a relational database (multiple indexes, stored procedures, powerful queries, etc.). Azure Table Storage is a non-relational, massively scalable (up to 100TB per account) storage facility, where entities are located by partition key (a colocation of entities) and row key.
If you want to have a very simple storage mechanism that doesn't require sophisticated relational operations, Azure Table Storage will work quite nicely.
EDIT June 7, 2012: Updated with Spring Release pricing
There are cost differences too. SQL Database starts at $4.99 for 100MB, scaling up on a tiered scale (about $26 for 5GB, $125 for 50GB, $225 FOR 150GB) but has no transactional costs. Azure Table Storage runs $0.125 / GB (or 0.09 / GB without geo-replication), dropping in per-GB price as quantity goes up, but has a $0.01 / 100,000 transaction cost (nominal for low volume systems, but could be significant with very high volume systems). Full pricing details are here.
There's a fairly recent article in MSDN Magazine that goes into greater detail regarding use cases, differences, etc.
If you're going for a straightforward migration of what you have in place today, SQL Database will closely match what you have in SQL Server Express 2005. However, since it's only a prototype at this point, it's worth re-evaluating your needs.
“我该如何决定选择哪个？”
好问题。
你必须弄清楚你关心什么，并相互评估各个选项。
我认为主要区别在于 SQL Azure 的可扩展性低于表存储。如果您预计会有大量访问者，您的数据库可能无法跟上，并成为阻止您进一步扩展的瓶颈 - 在云中，您可以不断添加前端服务器，直到您的信用卡耗尽，但是一旦您使用了“大”数据库服务器，您就无处可去。
（但这并不是真的 - 您还可以找到一种跨多个数据库服务器对应用程序进行分区的方法）。
因此，如果您关心可扩展性，您可能需要使用表存储 - 它没有与 SQL Azure 相同的可扩展性限制。
然而，这种可扩展性的成本也是您可能还关心的事情 - 您基本上必须从头开始构建应用程序才能使用表存储，并且必须重新创建从关系数据库免费获得的许多内容。例如，交易并不真正按照您期望的方式进行。
因此，如果它只是一个原型，并且您没有明确打算成为下一个 Facebook，那么我会继续使用 SQL Azure，直到可扩展性难题成为现实。
"How do I decide which to choose?"
Good question.
You have to work out what you care about, and evaluate the options against each other.
The key difference in my view is that SQL Azure is less scalable than table storage. if you're expecting huge numbers of visitors, your database may not be able to keep up, and become the bottleneck that stops you from scaling any further - in the Cloud, you can keep adding front-end servers until your credit card bleeds, but once you've gone to a "big" database server, you have nowhere else to go.
(Except that's not really true - you can also find a way of partitioning your application across multiple database servers).
So, if you care about scalability, you may want to go to table storage - it doesn't have the same scalability limits as SQL Azure.
However, the cost of that scalability is stuff you might also care about - you basically have to architect your application from scratch to work with table storage, and you have to recreate a lot of stuff you get for free from a relational database. Transactions don't really work the way you might expect, for instance.
So, if it's only a prototype, and you're not explicitly intending to become the next Facebook, I'd stay with SQL Azure until the scalability pain becomes real.