DynamoDB中分区键的优化答案

【问题标题】：Optimization of Partition Key in DynamoDBDynamoDB中分区键的优化
【发布时间】：2016-04-27 13:15:49
【问题描述】：

我在 DynamoDB 中有 Messages 表。它有四列发件人，时间戳，消息，收件人。我想知道，与其使用四列中的任何一列创建分区键，为什么不创建另一个列用于连接发送者&时间戳&接收者的分区目的。

因此，此列将包含 JohnSmithID1461754484307SallyMcDonaldID 之类的数据。

通过这样做，当搜索来自特定发件人和收件人组合的消息时，我可以通过使用类似查询的这一列进行查询（以 & 结尾）。还有其他几种方法可以利用这个专栏。

问题 1。我尝试使用一列而不是将查询分散到几列中是否过于复杂？

问题 2. 采用此方向是否有明显的性能优势？

问题 3. 这种设计模式是否仅在我出于数据大小目的而消除列 SenderId 和 RecipientID 时才值得？（我需要时间戳列作为排序键）

【问题讨论】：

【解决方案1】：

我认为您必须再次阅读how DynamoDB partition keys work。您无法对分区键执行诸如“开始于”或“结束于”之类的查询，因为您必须为查询提供完整的分区键。您只能在排序键上提供这样的条件（但请注意，有一个begins_with 函数，但没有 ends_with 函数）。

您的想法可能基于使用扫描而不是查询，但是（关于问题 2。）这将导致更多的使用容量和糟糕的性能，因为 DynamoDB 必须查看表中的每个项目。如果您想拥有更多的查询灵活性，您可以定义一个或多个secondary indexes。

您可以自己回答问题 3：DynamoDB 卷非常昂贵，但我们谈论的是每个条目可能存在 20 字节的差异。如果您的表中最终可能有 >10.000.000 个条目，这可能会成为一个问题，否则请忽略它。

【讨论】：

【解决方案2】：

您的特定示例将不起作用，因为查询时您不能在分区键上设置条件。您只能在排序键上具有这样的条件。

不过，这种结构有时可能会派上用场。例如，如果您有三个要查询的属性。 DynamoDB 最多允许两个（分区键 + 排序键），因此在这种情况下，其中一个可能是两个或多个属性的组合。

【讨论】：

先生，您是说如果我想使用三个过滤器参数进行查询，我不会因为要使用 dynamodb 表进行查询，尽管在所有三个相应的列中都放置了二级索引？
@shle2821我说的是一个场景，当您需要查询可以由三个或更多属性的组合定义的项目时。 DynamoDB 允许使用最多两个属性（分区键 + 排序键）形成主键。更多信息here
感谢您的信息。那么，让我问你这个问题。在单独保留主键的同时，我根据 senderID&timestamp&recipientID 创建了一个排序键？因此用户的设备会将这三个属性连接在一起并发送到 DynamoDB。因为它是一个排序键，所以我可以用“begin with”、“end with”等进行查询。您如何看待这种设计模式？
@shle2821，您的问题中有一些术语不太正确。我建议您查看他们文档中的Primary Key 页面。基本上，它们支持 2 种主键 - Partition Key 和 Partition Key + Sort Key 回到您的问题：当您需要一次基于 3 个或更多不同属性进行查询时，这种设计非常适合。在您的特定示例中，我认为设置多个全球二级索引会更合适。