我对DynamoDB很陌生，但我正在努力熟悉AWS及其服务。
对于我的用例，我想在DynamoDB中存储基于应用程序的事件，主要使用BI来可视化数据，但是很可能我最终也会做一些CRUD操作。
数据我想存储用户id,一个eventName,不同的事件会有不同的属性,我想商店。
因此，一个用户可以有多个具有相同名称的事件，每个事件可以有多个动态属性。我们也可以有无数不同的事件名称。
示例事件:
const event = {用户标识:标识,eventName:"some_event",数据:{//任何属性｝}
对于Dynamodb和设计它的设置，了解您的访问模式对于您将来计划如何访问数据是最重要的。任何文档在dynamo中唯一需要的是它的分区(哈希)键(也就是pk)——甚至它的排序(范围)键(也就是sk)也是可选的。所有的属性都是完全可选的，如果你愿意，可以100%不同于其他条目。
然而，因为这不是一个sql数据库，一旦你得到了大量的数据集，试图过滤扫描，并试图通过不属于你的PK/SK组合的信息来查找数据是非常昂贵和耗时的。您希望以这样一种方式设计数据存储，使您能够通过单个查询获取所需的任何内容，并且要求知道的PK和至少部分SK。
所以，在你的事件中问问你自己——你打算如何查找这些数据?总是用userId吗?如果你总是会有您的用户ID查找的数据然后罚款sk.但是如果你可能需要查找数据在某种程度上,一些方法以外的其他用户ID必须要么索引或其他一些重复的数据(这是好请意识到发电机拥有相同的数据复制到多个文档是好的——写更容易,通常比复杂的读取便宜。)如果你的"某些事件"是你计划如何组织你的数据，那么这可能是你的SK的一部分-也许你的PK是你的userID，你的SK是每个事件名称与ISO8601日期之后(说Login#2021-02-28-12:45:55.55T00:00) -然后你将能够通过查询userID的PK和SK以Login开头查找给定userID的所有登录
，但假设您想要查找x到y之间每个用户的每次登录。您需要执行以下两种策略中的一种—创建索引，或者通过包含一个文档(其PK为Login, SK为userID#ISO8601 Date)来复制数据。有好有坏。
优点-使用反向索引翻转pk和sk的责任要容易得多。缺点-数据复制到索引的延迟，所以你可能会错过最近的数据
复制数据的好处是始终是最新的，但缺点是需要2次写入，并且可能在表中拥有比您需要的更多的数据-但是考虑到Dynamo的工作方式，如果您的PK/SK设置足够强大，这实际上不是那么大的缺点。
所以基本上答案是:找出你的访问模式，然后从那里开始。从你的帖子的字里行间看，我想说的是，userID的PK和EventName#ISO8601-Date的SK +一个翻转PK/SK的索引将是你最好的选择。或者，如果您计划主要做聚合数据，那么将其转换为EventName作为pk, userID#ISO8601-Date作为SK，并使用反向索引，因为这将是所有用户聚合分析的最新数据，因为另一种方式将是每个用户的最新数据。