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

Question

我正在评估我正在构建的应用程序中 Azure 表存储的使用情况，我想获得一些关于...的建议

1. 这对于应用程序是否是一个好主意，或者
2. 如果我应该坚持使用 SQL，并且
3. 如果我确实使用 ATS，那么存储设计的好方法是什么。

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

• 帐户（每个用户都有一个帐户。）
• 任务（显然是用户创建任务。）
• TaskList（用户可以将他们的任务组织成列表。）
• 文件夹（用户可以将他们的列表组织到文件夹中。）
• 标签（用户可以为任务分配标签。）

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

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

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

我们想象数字从小开始（〜数百个帐户，每个帐户〜数百或数千个任务），但我们显然希望增加我们的帐户。

如果我们确实使用 ATS，是否会更好...

• 每个实体一个表（帐户、任务、任务列表等）
• 每个客户的表集（JohnDoe_Tasks、JohnDoe_TaskLists 等）
• 其他想法？

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

Answer 1

Azure 表存储非常适合任务应用程序。只要您设置好分区键和行键，就可以在大量同时使用的用户下获得快速且一致的性能。

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

至于成本，您可以根据帐户数量以及您期望这些帐户的活跃程度来估算交易成本。因此，如果您预计有 300 个帐户，并且每个帐户每天进行 100 次编辑，那么您每天将有 30K 笔交易，（$.01 per 10K transactions）每天的费用约为 0.03 美元，或者每月不到 1 美元.即使这个估计值相差 10 倍，每月的交易成本仍然低于一家像样餐厅的汉堡包。

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

总体而言，ATS 将很好地支持您的任务应用程序，并允许它扩展到大量用户。我认为主要问题是，您是否需要云规模的扩展？如果您这样做，ATS 是一个很好的解决方案；如果不这样做，您可能会发现适应新范式所花费的设计和实施时间比您获得的收益要多。

Answer 2

你的问题是一个相当大的问题，如果我没有给你一个确切的答案，请原谅我。简短的回答是：当然，继续使用 ATS :)

在这种情况下，您最关心的是速度。正如您所指出的，您期待大量的 CRUD 操作。开箱即用的 ATS 不支持交易，但您可以通过使用 CQRS 结构来构建自己的架构以应对此类挑战。

使用 SQL 与 ATS 的最大区别在于您缺乏关系和一般查询的可能性，因为 ATS 是一种“NoSQL”方法。这意味着您必须以支持查询操作的方式构建表，这不是一项简单的任务..

如果您知道这一点，我认为按照您的描述进行操作没有任何问题。

希望看到最终结果！