用于Web应用程序的Azure表存储设计

Question

我正在评估我正在构建的应用程序使用Azure表存储,我想得到一些建议...

1. 这是否适用于应用程序,或者
2. 如果我应该坚持SQL,和
3. 如果我选择ATS,那么对于存储设计来说,这将是一个很好的方法.

该应用程序是一个针对个人用户的任务管理Web应用程序.这是一个非常简单的应用程序.它有以下实体......

• 帐户(每个用户都有一个帐户.)
• 任务(显然用户创建任务.)
• TaskList(用户可以将他们的任务组织到列表中.)
• 文件夹(用户可以将其列表组织到文件夹中.)
• 标记(用户可以为任务分配标记.)

我们还将构建一些我需要考虑的功能/要求......

• 我们最终将为不同的帐户提供相互共享列表的功能.
• 用户需要能够以各种方式过滤他们的任务.例如...
  • 特定列表的任务
  • 标有"A"和"B"的特定列表的任务
  • 明天到期的任务.
  • 在所有列表中标记为"A"的任务.
  • 我分享的任务.
  • 任务说明中包含"hello"的任务.
  • 等等.
• 我们的应用程序是AJAX-heavy,对任务进行非常小的更改时会发生更新.因此,有很多小的请求和更新正在进行中.例如...
  • 内联编辑
  • 点击完成
  • 更改截止日期
  • 等等...

由于CRUD工作繁重,而且我们确实有一个简单实体列表,因此使用ATS是可行的.但是,我担心更新的交易成本,以及我所描述的查询/过滤是否能得到有效支持.

我们想象数字从小开始(〜数百个账户,每个账户数百或数千个任务),但我们显然希望增加我们的账户.

如果我们选择ATS,最好是......

• 每个实体一个表(帐户,任务,任务列表等)
• 每个客户的表集(JohnDoe_Tasks,JohnDoe_TaskLists等)
• 其他想法？

我知道这是一个很长的帖子,但如果有人对方向有任何想法或想法,我将不胜感激!

Answer 1

Azure表存储非常适合任务应用程序.只要您很好地设置分区键和行键,就可以在大量并发用户的情况下获得快速一致的性能.

对于任务共享,ATS提供乐观并发以支持多个用户并行访问相同数据.当多个帐户同时编辑相同的数据时,您可以使用乐观并发来警告用户,并防止他们意外地覆盖彼此的其他更改.

至于费用,您可以根据帐户数量以及您希望这些帐户的活跃程度估算您的交易费用.因此,如果您预计有300个帐户,并且每个帐户每天进行100次编辑,那么您每天将有30,000笔交易,(每10K交易额为0.01美元)每天将花费约0.03美元,或略低于每月1美元.即使这个估计减少10倍,每月的交易成本仍然低于一个体面的餐厅的汉堡包.

对于设计,要考虑的主要方面是如何键入表格.在设计ATS应用程序之前,我建议您阅读ATS白皮书,特别是有关分区的部分.该应用程序的一个合理设计是每个实体类型使用一个表(帐户,任务等),然后按帐户名称进行分区,并使用行键的任务的某些独特功能.对于这两种密钥类型,请务必考虑对未来查询的影响.例如,通过将可能一起更新的实体分组到同一个分区中,您可以使用实体组事务在单个事务中更新多达100个实体 - 这不仅可以提高速度,还可以节省交易成本.对于密钥的另一个含义,如果用户倾向于一次查看单个文件夹,则可以使用行键来存储文件夹(例如rowkey ="folder; unique task id"),并且具有非常高效的查询在一个文件夹上.

总的来说,ATS将很好地支持您的任务应用程序,并允许它扩展到大量用户.我认为主要的问题是,你需要云量级的缩放吗？如果你这样做,ATS是一个很好的解决方案; 如果不这样做,您可能会发现调整到新范例在设计和实施上花费的时间比您获得的好处要多.