DynamoDB - UUID 并避免全表扫描答案

【问题标题】：DynamoDB - UUID and avoiding a full table scanDynamoDB - UUID 并避免全表扫描
【发布时间】：2020-07-28 18:09:58
【问题描述】：

这是我的用例：

我有一个包含 200k 个对象的 JSON Api。数据集看起来有点像这样：日期、自行车型号、生产时间（以分钟为单位）。我使用 Lambda 从 JSON Api 读取并通过 http 请求在 DynamoDB 中写入。 Lambda 函数每天运行并使用最新数据更新 DynamoDB。

然后我按日期检索数据，因为我想计算每天的平均生产时间并将其放入第二个表中。一个 Alexa 技能连接到第二个表并读出每天的平均值。

第一个问题：由于同一自行车型号每天生产多次，因此使用带有日期和自行车型号的复合主键不会给我一个唯一的键。我应该为条目创建一个 UUID 吗？还是有更好的解决方案？

第二个问题：对于计算，我每次都需要进行全表扫描，这是非常昂贵的，许多人不建议这样做。如何在不进行全表扫描的情况下解决此问题？

第三个问题：在我的用例中完全避免使用 DynamoDB 是否更好？那么哪个 AWS 数据库更适合我的用例呢？

【问题讨论】：

【解决方案1】：

是的，uuid 或任何其他唯一标识符（例如：日期+自行车型号+创建时间）作为 pk 很好。
您的平均价值日常工作似乎是某种数据分析工作，而不是真正的交易工作。我建议使用服务支持数据分析，例如 Amazon Redshift。您应该能够使用 Dynamodb 流将数据添加到此类数据库服务。或者，您可以将数据流式传输到 s3 并使用 Athena 之类的服务来获取每日平均值。

【讨论】：

【解决方案2】：

有一个简单的数据库模型可用于此任务：

如果您随后创建一个二级索引，将生产日期用作 PK 并包含生产时间，则您可以查询（不扫描）特定日期的二级索引并执行您的任何计算需要生产时间。然后，您可以在二级索引和表上独立配置所需的读/写容量。

关于您的第三个问题，我认为使用 DynamoDB 执行此任务没有任何实际好处。任何 RDS（即 MySQL）、Redshift 甚至 S3+Athena 都可以轻松处理此类用例。如果您需要实时分析，您甚至可以考虑使用 AWS Kinesis。

【讨论】：