amazon-web-services - 这是设计此 DynamoDB 表的合理方式吗？备择方案？

Question

我们的团队已经开始使用 AWS，我们的一个项目需要在表格中存储各种建议的批准状态。

有很多东西可以识别一个推荐，假设它们是 : State, ApplicationDate, LocationID, and Phase。然后是推荐对应的一堆属性（title、volume等）

用例通常需要获取给定的所有条目，State并且ApplicationDate（然后我们将查看与其对应的所有 LocationId 和 Phase 项目）以从 UI 中查看。针对给定的项目一次一个地添加到表中Station, ApplicationDate, LocationId, Phase并经常更新。

一位具有更多 AWS 经验的开发人员提到我们可能应该将State+ApplicationDate其用作分区键和LocationId+Phase排序键。这两部分结合起来将成为主键。我通常理解这一点，但是如果我们开始为同一个主键获得多个建议，那将如何工作？我想我们要么只覆盖以前的内容就可以了，要么我们必须添加一些其他属性，以便我们可以State+ApplicationDate/LocationId+Phase多次编写建议并在需要时获取所有以前的值......但这需要添加一些东西到主键对吗？这就像为排序键添加某种独特的值吗？或者比如说我们需要做status，想在不同的status记录不同的值，是不是只需要在sort key中加上status就可以了？

这听起来像是一种合理的方法，还是我应该探索不同的 NAWS 产品来存储这些数据？

标签： amazon-web-servicesamazon-dynamodb

Answer 1

使用基于时间的 id 属性，例如 ULID 或 KSID。这将提供随机性以避免覆盖数据，但在用作排序键的一部分时还提供基于时间的数据排序

由于 id 值是随机的，因此您需要将其添加到执行列表操作的表或索引的排序键中，并为可以精确指定的已知值保留 pk。

听起来“状态”是一个可以改变的值。您无法更新表中项目的键属性，因此如果需要列出数据，则更常见的是在 GSI 的键中使用这些属性。

鉴于上述情况，另一种设计是使用 LocationId 作为 pk，随机 id 值作为 sk，以及一个 GSI，其中 GSI 具有“State”作为 pk，随机 id 作为 sk。或者，如果您想按 State -> Phase -> date 列出项目，则 GSI sk 可以是 Phase 和 id 属性的串联。上述模式为您提供了另一种列表机制，使用 LocationId + 推荐创建时间的时间戳。