微软Azure存储 vs. Azure SQL数据库

Question

我看到几个月前有类似的问题，但它并没有很好地解决我的情况。 这就是我的问题...

我正在从头开始构建一个基于Web的.NET应用程序，有潜力成为高流量站点（每月几十万次页面浏览），并且强烈考虑使用Microsoft Azure进行托管。 我还没有构建任何内容，仍然在研究不同的选项。

该应用程序本质上是一个标准的CRUD应用程序，作用于许多不同类型的实体（例如用户，订单，项目等）。 可能会有一些后台进程运行和某些数据排队（用于非实时更新，例如获得SO徽章），但与用户的大多数交互都将是您典型的CRUD类型的操作。

关于Azure，我已经阅读了许多有关使用Microsoft Azure Storage存储事务数据的文章，并且强烈考虑使用它，而不是使用Azure SQL DB。 但是，我还没有看到或阅读过有关真实人员和/或真实公司使用Microsoft Azure Storage的成功故事。 因此，我想向SO社区寻求帮助，看看是否有人使用Microsoft Azure Storage的经验，您的运气如何，我应该注意哪些陷阱，以及您想出的任何最佳实践。

我已经阅读了许多Microsoft Azure MSDN部分和Microsoft的编程Microsoft Azure Table API文档。 我正在寻求实际建议，学到的教训，最佳实践等。 预先感谢！

- David Hoerster

Answer 1

Windows Azure存储与任何NoSQL存储一样，适用于高规模场景 （每个用户处理数百万条记录）。但是，经典的CRUD方法有点难以扩展或适应这种情况。

我建议您开始使用CQRS架构风格。以下是一些可能会帮助您入门的参考资料：

• Windows Azure的开源Lokad.CQRS项目（包含模式和指南）
• MSDN上关于Azure高效架构的讨论

- Rinat Abdullin

---

谢谢提供信息。我已经快速浏览了您提供的一些信息（我会在本周末更深入地研究）。有一个问题 - 在您工作的项目/产品中，您是否将SQL Azure与Azure Storage结合使用，还是只使用了Azure Storage？看起来您链接的一些文档显示SQL Azure与Azure Storage一起使用。如果您使用了SQL Azure，那么它是用于CQRS的命令端，然后移动到Azure存储中的吗？再次感谢。 - David Hoerster

这是一些很好的信息，让我朝着正确的方向前进。谢谢！ - David Hoerster

我们在命令端使用SQL Azure和Azure存储。 SQL Azure用于关系数据，Azure存储用于Blob、队列和视图数据。理论上，SQL Azure可以被事件溯源所取代，但我们还没有达到那个阶段。 - Rinat Abdullin

好的回答！我还想补充一点，决策的一部分是心理因素...当存在大量关于标准SQL依赖3层架构的社区资料时，跳出既定模式会更加困难。当我选择Azure Tables路线时，我感觉自己在冒险，但回顾过去并结合CQRS方法的性能优势和价格，现在我完全感到舒适了。 - Sentinel

Answer 2

根据您所讨论的数据类型而定-通常会高估事务数据要求。很多数据实际上可以适应于1 GB的SQL Azure（我们是SAAS提供商，几乎20个客户的事务数据都可以适应这么大的空间）。此外，由于某种奇怪的原因，我发现SQL Azure空间消耗似乎比我在本地看到的数据库大小略小（可能与他们如何处理日志有关，不确定）。现在50 GB是极限，说实话，非常巨大。

然而，对于此，您还需要考虑什么会增加空间使用-存储图像，视频或其他大型对象在数据库中可能会导致空间消耗显着增加。最好将这些类型的对象保留在Windows Azure中。

简而言之-将事务数据保留在SQL Azure中，并将非关系数据保留在Windows Azure中。使用SQL Azure也将使您的开发人员更加高效，因为在编程方面它非常熟悉。将Windows Azure视为类似于Windows本地文件存储的方式，并带有一些附加优势（支持基本表结构）。

- Roopesh Shenoy

---

谢谢你的观点。当您使用Windows Azure存储非事务性数据时，您是否使用表存储和Blob的组合？您是否完全不使用驱动器？谢谢！ - David Hoerster

我们使用前两个 - 驱动器还很新，尚未找到一个很好的使用它们的地方。上面漏掉了，但 Azure 表格非常适合编写日志，特别是使用日志。 Blobs 适用于图像、视频和其他大型文件。 驱动器是当您需要类似本地硬盘的东西时使用的。然而，这些是特定于实例的（意味着一次只有一个实例可以写入驱动器），不像 Azure 存储可以被多个实例同时访问。 - Roopesh Shenoy

Answer 3

另一个需要考虑的因素是您将从商店发送/接收的交易数量。 SQL Azure 的好处在于它是每月固定成本，如果您在同一数据中心内执行查询（即从位于与 SQL Azure 数据库相同数据中心的 Windows Azure Web 角色），那么就不会有额外费用。

尽管与 Windows Azure 商店的交易成本相当低，但如果您进行足够多的交易，则可能会累加。

- Voclare

Answer 4

另一个获取信息的地方是走出Windows Azure选项，看看AWS的。S3和SimpleDB选项已经经过了更长时间的验证，并且在网络上有许多额外的成功案例。然而，S3和SimpleDB在功能上与Windows Azure存储表和Blob存储非常相似。如果您考虑到真正的大数据，这些结构就是为此而设计的，请务必查看AWS选项。即使只是作为围绕大数据构建现有解决方案的参考点。

至于SQL Azure，它非常适合处理大量交易，降低交易成本，并基于关系数据维护关系和一般完整性。但是，如果您将拥有海量数据，请直接瞄准大数据结构，例如Windows Azure Table或Amazon的SimpleDB。

- Adron

Answer 5

在决定使用Azure存储或SQL存储之前，您还应该检查数据使用模式。 由于Azure存储提供NoSQL解决方案，它们更适用于非报告基础要求。 在这里，“报告”并不意味着报告，而是指Azure存储的查询功能受到限制或未针对各种查询场景进行优化。 使用CQRS架构，CRUD和Reporting操作被解耦，因此可以混合匹配Azure存储和Azure SQL。

- Chandermani

---

谢谢。这也有所帮助。我正在考虑在表存储和 SQL Azure 之间进行混合使用。我不太确定应该在 SQL Azure 中保留多少数据 - 您的经验是否基本上在 SQL Azure 和 Azure 存储之间有数据重复？ - David Hoerster

这不是关于存储多少数据的问题，而是如何存储。例如，如果您正在实现用户身份验证\授权方案，所有数据访问模式都将围绕特定用户展开，并且NoSQL在这里表现最佳。但是，在同一个方案中，如果我们想要一个管理员界面来管理用户，其中涉及显示用户列表、过滤器等，则最适合使用数据的关系格式。在这种情况下，您需要在NoSQL和SQL存储中保留用户数据的副本，但仅信任NoSQL数据库执行任何业务验证。我们需要一些机制来同步用户数据存储（单向）。 - Chandermani

因此，您需要考虑这种复杂性是否适用于您的应用程序。 - Chandermani