Web应用程序的Azure表存储设计
我正在评估 Azure 表存储在我正在构建的应用程序中的使用情况,我想获得一些建议...
- 这对于应用程序来说是否是一个好主意,或者
- 我是否应该坚持使用 SQL,以及
- 如果我确实选择 ATS,这将是一个很好的存储设计方法。
该应用程序是一个任务管理 Web 应用程序,针对个人用户。这确实是一个非常简单的应用程序。它具有以下实体...
- 帐户(每个用户都有一个帐户。)
- 任务(显然,用户创建任务。)
- 任务列表(用户可以将他们的任务组织到列表中。) 文件
- 夹(用户可以将他们的列表组织到文件夹中。)
- 标签(用户可以为任务分配标签。)
我们还将构建一些我需要考虑的功能/要求...
- 我们最终将为不同帐户提供相互共享列表的功能。
- 用户需要能够以多种方式过滤他们的任务。例如...
- 特定列表的任务
- 标有“A”和“B”的特定列表的任务
- 明天到期的任务。
- 所有列表中标记为“A”的任务。
- 我共享的任务。
- 任务注释中包含“hello”的任务。
- 等等
- 我们的应用程序大量使用 AJAX,对任务进行非常小的更改就会发生更新。因此,有很多小请求和更新正在进行。例如...
- 内嵌编辑
- 点击完成
- 更改截止日期
- 等等...
由于 CRUD 工作繁重,而且我们确实有一个简单实体列表,因此使用 ATS 是可行的。但是,我担心更新的交易成本,以及是否可以有效支持我描述的查询/过滤。
我们想象数量开始时很小(〜数百个帐户,〜每个帐户数百或数千个任务),但我们显然希望增加我们的帐户。
如果我们确实采用 ATS,那么最好...
- 每个实体一张表(帐户、任务、任务列表等)
- 每个客户一组表(JohnDoe_Tasks、JohnDoe_TaskLists 等)
- 其他想法?
我知道这是一篇很长的文章,但如果有人对这个方向有任何想法或想法,我将不胜感激!
I am evaluating the use of Azure Table Storage for an application I am building, and I would like to get some advice on...
- whether or not this is a good idea for the application, or
- if I should stick with SQL, and
- if I do go with ATS, what would be a good approach to the design of the storage.
The application is a task-management web application, targeted to individual users. It is really a very simple application. It has the following entities...
- Account (each user has an account.)
- Task (users create tasks, obviously.)
- TaskList (users can organize their tasks into lists.)
- Folder (users can organize their lists into folders.)
- Tag (users can assign tags to tasks.)
There are a few features / requirements that we will also be building which I need to account for...
- We eventually will provide features for different accounts to share lists with each other.
- Users need to be able to filter their tasks in a variety of ways. For example...
- Tasks for a specific list
- Tasks for a specific list which are tagged with "A" and "B"
- Tasks that are due tomorrow.
- Tasks that are tagged "A" across all lists.
- Tasks that I have shared.
- Tasks that contain "hello" in the note for the task.
- Etc.
- Our application is AJAX-heavy with updates occurring for very small changes to a task. So, there is a lot of small requests and updates going on. For example...
- Inline editing
- Click to complete
- Change due date
- Etc...
Because of the heavy CRUD work, and the fact that we really have a list of simple entities, it would be feasible to go with ATS. But, I am concerned about the transaction cost for updates, and also whether or not the querying / filtering I described could be supported effectively.
We imagine numbers starting small (~hundreds of accounts, ~hundreds or thousands of tasks per account), but we obviously hope to grow our accounts.
If we do go with ATS, would it be better to have...
- One table per entity (Accounts, Tasks, TaskLists, etc.)
- Sets of tables per customer (JohnDoe_Tasks, JohnDoe_TaskLists, etc.)
- Other thoughts?
I know this is a long post, but if anyone has any thoughts or ideas on the direction, I would greatly appreciate it!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
Azure 表存储非常适合任务应用程序。只要您正确设置分区键和行键,您就可以在大量并发用户的情况下获得快速且一致的性能。
对于任务共享,ATS 提供乐观并发来支持多个用户并行访问相同的数据。当多个帐户同时编辑相同数据时,您可以使用乐观并发来警告用户,并防止他们意外覆盖彼此的更改。
至于成本,您可以根据账户数量以及您期望这些账户的活跃程度来估算交易成本。因此,如果您预计有 300 个帐户,并且每个帐户每天进行 100 次编辑,那么您每天将有 30K 笔交易,这(位于 每 10K 笔交易 0.01 美元)每天的费用约为 0.03 美元,或者每月略低于 1 美元。即使这个估计有 10 倍的偏差,每月的交易成本仍然低于在一家像样的餐厅吃一个汉堡。
对于设计,要考虑的主要方面是如何为表设置键。在设计 ATS 应用程序之前,我建议您阅读 ATS 白皮书,特别是关于分区的部分。应用程序的一种合理设计是为每种实体类型(帐户、任务等)使用一个表,然后按帐户名称进行分区,并使用任务的某些独特功能作为行键。对于这两种键类型,请务必考虑对未来查询的影响。例如,通过将可能一起更新的实体分组到同一分区中,您可以使用实体组事务在单个事务中更新最多 100 个实体 - 这不仅提高了速度,还节省了事务成本。对于键的另一个含义,如果用户倾向于一次查看单个文件夹,您可以使用行键来存储文件夹(例如 rowkey="folder;unique task id"),并进行非常有效的查询一次在一个文件夹上。
总体而言,ATS 将很好地支持您的任务应用程序,并允许其扩展到大量用户。我认为主要问题是,您是否需要云规模的扩展?如果您这样做,ATS 是一个很好的解决方案;如果不这样做,您可能会发现适应新范例在设计和实施方面花费的时间比您获得的好处要多。
Azure Table Storage is well suited to a task application. As long as you setup your partition keys and row keys well, you can expect fast and consistent performance with a huge number of simultaneous users.
For task sharing, ATS provides optimistic concurrency to support multiple users accessing the same data in parallel. You can use optimistic concurrency to warn users when more than one account is editing the same data at the same time, and prevent them from accidentally overwriting each-other's changes.
As to the costs, you can estimate your transaction costs based on the number of accounts, and how active you expect those accounts to be. So, if you expect 300 accounts, and each account makes 100 edits a day, you'll have 30K transactions a day, which (at $.01 per 10K transactions) will cost about $.03 a day, or a little less than $1 a month. Even if this estimate is off by 10X, the transaction cost per month is still less than a hamburger at a decent restaurant.
For the design, the main aspect to think about is how to key your tables. Before designing your application for ATS, I'd recommend reading the ATS white paper, particularly the section on partitioning. One reasonable design for the application would be to use one table per entity type (Accounts, Tasks, etc), then partition by the account name, and use some unique feature of the tasks for the row key. For both key types, be sure to consider the implications on future queries. For example, by grouping entities that are likely to be updated together into the same partition, you can use Entity Group Transactions to update up to 100 entities in a single transaction -- this not only increases speed, but saves on transaction costs as well. For another implication of your keys, if users will tend to be looking at a single folder at a time, you could use the row key to store the folder (e.g. rowkey="folder;unique task id"), and have very efficient queries on a folder at a time.
Overall, ATS will support your task application well, and allow it to scale to a huge number of users. I think the main question is, do you need cloud magnitude of scaling? If you do, ATS is a great solution; if you don't, you may find that adjusting to a new paradigm costs more time in design and implementation than the benefits you receive.
你问的是一个相当大的问题,所以如果我没有给你一个确切的答案,请原谅我。简短的答案是:当然,继续使用 ATS :)
在这种情况下你最关心的是速度。正如您所指出的,您期望进行大量 CRUD 操作。 ATS 不支持开箱即用的交易,但您可以使用 CQRS 结构来构建自己以摆脱此类挑战。
与使用 SQL 到 ATS 的最大区别是缺乏关系和一般查询的可能性,因为 ATS 是一种“NoSQL”方法。这意味着您必须以支持查询操作的方式构建表,这不是一项简单的任务。
如果您意识到这一点,我认为执行您所描述的操作不会有任何问题。
很想看到最终结果!
What your are asking is a rather big question, so forgive me if I don't give you an exact answer.. The short answer would be: Sure, go ahead with ATS :)
Your biggest concern in this scenario would be about speed. As you've pointed out, you are expecting a lot of CRUD operations. Out of the box, ATS doesn't support tranactions, but you can architect yourself out of such a challenge by using the CQRS structure.
The big difference from using a SQL to ATS is your lack of relations and general query possibilities, since ATS is a "NoSQL" approach. This means you have to structure your tables in a way that supports your query operations, which is not a simple task..
If you are aware of this, I don't see any trouble doing what your'e describing.
Would love to see the end result!