我有以下一对多的关系:
Account 1--* User
Account
包含全局帐户级别的信息,这是可变的.
User
包含用户级别的信息,这也是可变的.
当用户登录时,他们同时需要Account
和User
信息。(我现在只知道UserId
)。
理想情况下,我希望设计模式,这样就需要一个查询。但是,如果不将Account
复制到每个User
中,并因此需要一些背景Lambda作业来在所有User
对象之间传播对Account
属性的更改,我就无法确定如何做到这一点--从记录上看,这似乎比简单地规范化数据和在每个登录上有2个查询更像是资源使用(和维护):获取用户,然后获取帐户(在标识帐户的用户对象内使用FK )。
是否有可能设计一个模式,允许一个查询同时获取两个查询,并且不需要一个非事务性后台作业来传播更新?(事务性批处理更新是不可能的,因为有超过25个用户。)如果不是,2-查询的想法是最好的/一个可接受的方法吗?
发布于 2020-11-10 23:03:31
我将集中在你问题的一个角度-2-查询的想法。在许多情况下,这确实是一种可以接受的方法,比其他方法更好。事实上,在许多NoSQL使用中,每个用户可见的请求都会产生两个以上的数据库请求。事实上,经常有人说这就是为什么NoSQL系统关心低尾延迟的原因(也就是说,即使是第99百分位数的延迟也应该很低)。
您没有说明为什么要避免2-查询解决方案。您介绍的2-查询实现有两个缺点:
可能有一些技巧可以用来解决这两个问题,具体取决于用例的更多细节:
延迟:您没有在应用程序中说明什么是“用户id”。如果它是某种唯一的数字标识符,也许可以设置它,以便可以直接从用户id确定帐户id,而不需要查找表(例如,用户id的第一位是帐户id)。如果是这样的话,您可以同时启动两个查找,而不是将延迟增加一倍。成本仍然是双倍的,但不是延迟。
成本方面:如果每个帐户有大量用户(您说超过25个--我不知道它是否更多),缓存帐户数据可能是有用的,这样不是每个用户查找都需要再次读取帐户数据--它可能经常被缓存。如果帐户信息很少改变,而且一致性不是什么大问题(我不知道它是否.),您也可以通过对帐户信息进行“最终一致性”读取--这是常规“一致性”读取的一半。
发布于 2022-06-15 17:33:28
我认为以下的计划将是有用的。
中。
PK: account SK: recordId
=== Account record ===
account: 123512321 recordId: METADATA attributes: name, environment, ownerId...
=== User record ===
account: 123512321 recordId: USERID#34543543 attributes: name, email, phone...
通过这种数据的反规范化,您可以在一个查询中检索帐户元数据和相关用户。您还可以更改帐户元数据,而无需将任何更改应用于相关用户。
奖励:您还可以将其他类型的资产链接到帐户记录。
https://stackoverflow.com/questions/64777415
复制相似问题