如何设计关键架构以使每个应用程序只有一个DynamoDB表？ [英] How to design key schema to have only one DynamoDB table per application?

问题描述

根据DynamoDB文档： https：/ /docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-general-nosql-design.html

According to DynamoDB doc: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-general-nosql-design.html

您应保持DynamoDB应用程序中的表尽可能少。大多数设计良好的应用程序只需要一个表。

经验，由于分区键设计，您总是必须做相反的事情。

But according to my experience you always have to do the opposite thing due to partition key design.

让我们考虑下一种情况。我们有几个用户角色，例如 admin， manager， worker。管理员通常的工作流程是处理CRUD管理员数据，其中读取操作不是要获取一个管理员，而是要获取所有管理员列表。经理也一样-他CRUD工人数据。
在这两种情况下，我们只有两种密钥使用情况：

Let's consider the next situation. We have several user roles, for example, "admin", "manager", "worker". Usual workflow of an admin is to CRUD manager data, where read operation is to get not one manager but all manager list. The same is for the manager - he CRUDs worker data. We have only two scenarios of key usage for both cases:

• 获取所有项的列表（项目密钥不问题）


• 使用其完整键来处理特定项目。

自然地，我们应该拥有统一分布的分区键（如文档所强调），因此我们无法为其选择用户角色，而应使用用户ID。由于我们已经有了一些随机ID作为分区键，因此根本不需要排序键，因为它根本无法工作-我们已经仅通过使用分区键部分就可以访问一个用户。在这一点上，我们意识到用户ID对于CUD操作来说就像是一个咒语，但是对于每个R操作，我们需要扫描所有表，然后按用户角色过滤结果，这是无效的。如何改善呢？很自然-每种用户类型都有自己的表格！然后，我们将通过admin API扫描管理器列表，并从管理器之一扫描工作者列表。

Naturally we should have uniformly distributed partition key (as the doc emphasises) so we can't select user role for it and should use user id. Since we already have as partition key some random id, we don't need sort key at all since it simply doesn't work - we already access exectly one user by only using the partition key part. At this point we realize that user id is working like a charm for CUD operations but for every R operation we need to scan all the table and then filter the result by user role which is ineffective. How can this be improved? Very naturally - let's just have own table for each user type! Then we will scan for manager list from admin API and for worker list from the manager one.

我使用DynamoDB差不多一年了，但仍然无法使用。对我来说，现实是在现实生活中，排序键是您永远无法使用的（我唯一的真实案例就是同时访问属于不同类型的两个用户的协议之类的项目，因此主键是{partion： managerId，sort： userId}，辅助全局索引是{partition： userId，sort： managerId}这样我就可以有效地查询所有特定的经理协议列表或所有特定用户协议列表仅提供查询的相应管理者或用户ID，此方法在文档中进行了讨论： https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-adjacency-graphs.html ）。

I use DynamoDB almost for a year and still can't get it. For me the reality is that for real life scenarios sort key is something that you can never use (the only real case for it I had was to access items like "agreements" that belong to the two users of different types the same time, so the primary key was { partion: "managerId", sort: "userId" } and secondary global index was { partition: "userId", sort: "managerId" } so I could effectively query for all particualar manager agreement list or all particular user agreement list providing only corresponding manger or user id for the query. The approach is discussed in doc here: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-adjacency-graphs.html).

我觉得我根本不了解这个概念。对于所提供的示例，对于两种用户类型都仅使用一个 DynamoDB表的键模式的有效方法是什么？

I feel that I don't understand the concept at all. What can be an effective way of key schema for provided example to use only one DynamoDB table for both user types?

推荐答案

在这种情况下，您似乎需要的是全球二级索引（ https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html ），其中分区键是用户角色。这样，您可以通过 UserRoleIndex 查询具有特定角色的所有用户，并借助用户ID上的排序键，在该角色中选出一个特定用户

It sounds like what you need in this case is a Global Secondary Index (https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html) where the partition key is the user role. That way, you can query all users with a particular role through that UserRoleIndex and, with the help of a sort key on the user ID, single out one particular user within that role.

或者，如果您从头开始创建一个新表，则可能甚至不需要索引（除非您不知道用户的角色，删除它们）。您可以使用复合主键（ https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.CoreComponents.html#HowItWorks.CoreComponents.PrimaryKey ），其中分区键和排序键与

Alternatively, if you are starting from scratch with a new table, you might not even need an index (unless you don't know the role of a user when you delete them). You can use a "composite primary key" (https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.CoreComponents.html#HowItWorks.CoreComponents.PrimaryKey) where the partition key and the sort key would be the same as in the index I am suggesting above.

使用您在问题中使用的相同符号，我建议使用 {partition： userRole，sort ： userId} 。

Using the same notation that you used in your question, I would recommend { partition: "userRole", sort: "userId" }.

DynamoDB有时可能很难理解，而且在某些情况下，传统的SQL数据库显然更有意义。 AWS re：Invent 2018的这段视频非常适合理解两者之间的区别： https://www.youtube.com/watch?v=HaEPXoXVf2k&feature=youtu.be 。

DynamoDB can be hard to understand sometimes and there definitively are cases where a traditional SQL database makes more sense. This video from AWS re:Invent 2018 is great to understand the difference between the two: https://www.youtube.com/watch?v=HaEPXoXVf2k&feature=youtu.be.

不过，在您的情况下，看起来您的访问模式非常清晰，因此DDB会为您工作。

In your case, though, it looks like you have a very clear access pattern, so DDB would work for you.

这篇关于如何设计关键架构以使每个应用程序只有一个DynamoDB表？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！