Azure表存储 - 实体设计最佳实践问题

时间:2011-04-14 11:16:54

标签: azure azure-sql-database azure-storage azure-table-storage

我正在编写一个“概念验证”应用程序,以研究在必要的重写整个应用程序期间将定制的ASP.NET电子商务系统转移到Windows Azure的可能性。

我很想看看使用Azure表存储作为SQL Azure的替代方案,因为随着应用程序的进一步成熟,存储的实体可能随着时间的推移而改变其架构(属性),并且我不需要进行无休止的数据库架构更改。此外,我们可以在应用程序代码中构建参考完整性 - 因此考虑Azure表存储的情况非常强烈。

我目前唯一可以看到的潜在问题是我们会做一些简单的报告 - 即两个日期之间的销售价值,特定产品的销售数量等。 我知道Table Storage不支持聚合类型函数,我相信我们可以通过巧妙地使用分区,多个实体类型来存储相同数据的子集以及可能的预聚合来实现我们想要的目标,但我不是100%肯定如何去吧。

有没有人知道有关Azure表存储设计原则的任何深入文档,以便我们正确有效地使用Tables,PartitionKeys和实体设计等。

周围有一些简单的文档,目前的书籍往往不会深入探讨这个主题。

仅供参考 - 电子商务网站拥有约25,000名客户,每年约需100,000份订单。

4 个答案:

答案 0 :(得分:11)

答案 1 :(得分:4)

我认为在将您的应用移植到Table Storage时,我认为有三个潜在的问题。

  1. 缺乏报告 - 包括汇总功能 - 您已经确定
  2. 交易支持的有限性 - 每年有100,000个订单我认为你最终会错过这种支持。
  3. 成本问题 - 每百万操作1美元只需很少的成本,但如果您获得大量页面浏览量,则需要考虑这一点。
  4. 老实说,我认为是一种混合方法 - 对于关键数据,SQL Azure可能是EF或NH,大型对象存储在Table / Blob中?

    足够我的意见!对于“深入”:

答案 2 :(得分:0)

如果您已开始查看表格等Azure存储,那么查看市场上的其他NOSQL产品(尤其是文档数据库)并不会有任何损害。这将使您深入了解NOSQL空间以及如何设计这些存储的解决方案。 您还可以考虑SQL DB + NOSQL解决方案的混合方法。系统的某些部分可能非常适合Azure表存储模型。 诸如Azure表之类的NOSQL解决方案有其自身的挑战,例如

  • 数据的架构更改。查看herehere
  • 交易支持
  • ACID限制。查看here

答案 3 :(得分:0)

我见过的所有桌面设计论文都非常专注于可扩展性和搜索性能这两个主题。我没有看到任何与报告或BI的设计考虑有关的事情。

现在,可以通过rest API和azure SDK访问azure表。根据您需要的报告,您可以轻松地提取所需的信息。如果您的报告要求非常复杂,那么SQL Azure和SQL Azure SQL Reporting服务可能是更好的选择吗?

相关问题