DynamoDb 中的多对多访问模式
我有一个模型，其中用户可以访问多个文件，并且一个文件可以属于多个用户，因此是多对多结构。我有兴趣使用 DynamoDb 来实现此目的，即使没有本机关系支持。从其他帖子中，我认为我可以从以下结构开始：
- PK: USER#, SK: USER# = 定义用户
- PK: USER#, SK: FILE# = 共享给用户的文件的属性
- PK: FILE#, SK: FILE# = 文件的属性
使用此结构，我可以通过伪 sql 代码 SELECT * FROM table WHERE PK=user AND 执行“列出用户可用的所有文件”之类的操作SK.startsWith("FILE#")。
但是我不确定如何通过此结构执行“为用户 Y 检索文件 X”之类的操作。这似乎涉及两个查询：
- 检索用户 Y 可用的所有文件并检查 X 是否确实可用
- 如果步骤 1 确认 X 对 Y 可用，则执行查询 SELECT * FROM t WHERE PK=FILE#X 和SK=FILE#X。否则失败。
这似乎违背了该结构的目的，即最小化 IOPS。我该如何解决这个问题并且只需要对这种访问模式进行一次查询？
I have a model where a user can access multiple files and a file can belong to many users, hence the many-to-many structure. I'm interested in using DynamoDb for this, even though there is no native relational support. From other posts, I think I can start with the following structure:
- PK: USER#, SK: USER# = defines a user
- PK: USER#, SK: FILE# = attributes for the file shared to a user
- PK: FILE#, SK: FILE# = attributes for a file
With this structure, I can do things like "list all the files available to a user" via the pseudo-sql code SELECT * FROM table WHERE PK=user AND SK.startsWith("FILE#").
However I'm not sure how I could do something like "retrieve the file X for user Y" via this structure. This seems to involve two queries:
- Retrieve all files available to the user Y and check that X is indeed available
- If step 1 confirms that X is available to Y then perform a query
SELECT * FROM t WHERE PK=FILE#X and SK=FILE#X. Otherwise fail.
This seems to defeat the purpose of the structure, which is minimising IOPS. How do I go about solving this problem and only requiring one query for this access pattern?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您要么执行两个请求，要么将文件数据非规范化到用户持有的项目中。
或者，您可以在文件项中创建共享用户列表，但这通常无法很好地扩展。
You either do two requests or you denormalize the file data into the item held under the user.
Or you could create a list of shared-with users within the file item, but that’s usually not going to scale well.