DynamoDB表的设计方案

Question

我是DynamoDB的新手，在阅读了几个文档之后，我不确定哪种方法是设计表的最佳方法。考虑到我们有一些JobOffers，我们应该支持以下数据访问：

(newest/oldest/wage)

• get
• 获得特定的JobOffer
• 从特定公司获得按不同标准排序的所有JobOffers从特定的公司中筛选出按不同标准排序的特定城市
• all JobOffers (不管哪个公司！！)按不同的标准(newest/oldest/wage)
• get JobOffers排序(不管哪个公司！)按不同标准排序的特定城市筛选(newest/oldest/wage)

因为我们需要支持排序，我的理解是我们应该使用查询而不是扫描。为了使用查询，我们需要使用主键。因为我们需要支持这样的搜索，比如“在没有任何筛选器的情况下获取所有的JobOffers”，这将是分区密钥的一个很好的候选？

作为一种解决办法，我考虑使用一个新的属性" country“，它可以用作分区键，但是由于所有JobOffers都是在一个国家指定的，所以所有这些项都属于同一个分区，所以在我们支持来自不同国家的JobOffers之前，它可能有点多余。

对于如何为这样的场景设计JobOffer表(有PK和GSI/LSI)，有什么建议吗？

Answer 1

Dynamodb表的设计最好使用一种访问方法--也就是说，您将如何访问此处的数据。你有信息X你需要Y。

还请记住，dynamo不是sql，并且不限制每个条目必须相同--将每个条目看作文档，其PK/SK几乎可以作为文件系统中的目录/项结构。

例如：

你有用户数据。您有如下内容：“阿凡达数据”(图像名称、图像大小、图像类型)、登录数据(盐分/胡椒散列、电子邮件地址、用户名)、邮政历史记录(帖子标题、标识符、内容、回复)。每个用户将只有一个阿凡达项目和一个登录项目，但有许多邮政项目

您知道，从用户页面，您将始终有用户ID. 100%的时间。这应该是你的PK -你的哈希密钥，PartitionKey。然后，您有您需要的其他东西，通知您的排序键/范围键。

PK
USER#123456
    SK:
    AVATAR - Attributes: (image name, image size, image type)
PK
USER#123456
    SK:
    LOGIN - Attributes: (salt/pepper hashes, email address, username)
PK
USER#123456
    SK:
    POST#123 - Attributes: (post title, identifier, content, replies)
PK
USER#123456
    SK:
    POST#125 - Attributes: (post title, identifier, content, replies)
PK
USER#123456
    SK:
    POST#193 - Attributes: (post title, identifier, content, replies)

通过这种方式，您可以使用用户ID进行查询，并将所有用户数据取回。或者，如果您在一个只显示其post历史记录的页面上，您可以对用户ID # SK进行查询，以POST开头，并返回所有的t后继帖子。

您可以输入一个倒置索引(SK -> PK，反之亦然)，然后对POST#193进行查询并返回用户ID。

这里的想法是，你有X位信息，你需要制作你的发电机才能尽可能多地检索到这些信息，然后在你的SKs上使用前缀，你可以缩小一些字段。

注释！有时这意味着重复信息！在两组键下可能有相同的信息。当你开始进入非常复杂的关系时，这是可以的，也是一种期待。您可以在索引中稍微减轻它，但是您应该尽可能避免它们，因为它们确实在数据传播方面引入了一些滞后(它很小，但它可以加起来)。

所以你有你想买发电机的东西清单。你要怎么把它们绑在一起？你有哪些数据可以用？

您可以使用公司PK标识符和反向索引来完成前3项操作。这将使您能够查找并找到所有公司的工作，或者使用反向索引--所有特定的工作。或者，如果您在查找某一特定职务时总是能够了解该公司，那么它将使用一般的第一个索引。

Company# - Job# -数据数据

然后，您自己进行排序，或者向Job#键中添加某种排序值--排序键毕竟是固有的排序。Company# - Job#1234#UNITED_STATES

当然，这种方法一次只能起一种作用。您可以创建多个索引，但是--数据同步滞后是一种真正的可能性。

但是，不管是什么公司，如何做到这一点？好吧，您可以使用可搜索属性(例如，Country)作为PK的另一个索引，然后您可以查询该属性。

或者你有另一组数据可以把这一切联系在一起？你还有别的东西可以做到吗？

如果没有，您可能只有两个项目在您的发电机：

Company#1234 - Job#321 - details Company#1234 - Country#United_states - job#321，job#456，job#1234 Company#1234 - Country#England - job#992，job#123，job#19231

这里的反向索引也适用--您可以对PK: Contry#UnitedStates进行查询，然后返回：

Country#United_states - Company#1234 - job#321，作业#456，job31234 Country#United_states - Company#4556 Country#United_States - Comapny#8322

然而，这不是一个关系数据库！因此，要么您必须做两件事之一-使用t软管job#s，然后查询该公司，并获得过滤器的工作，你想要什么(坏-试图避免多个查询！)或者每个job#都是country sk上的一个属性，它以地图格式{job title, job#, country, company, salary}包含相关数据的副本。然后，当他们单击该作业以进入详细信息时，它直接调用作业查询，获取要显示的详细信息，并显示它的优点。

再说一次，这一切都归结为访问模式。你有什么，怎么安排它，让你快速得到你想要的东西。