0

我有以下一对多的关系：

Account 1--* User

Account包含全局帐户级别的信息，这些信息是可变的。

包含用户级别的信息，这些User信息也是可变的。

当用户登录时，他们需要Account和User信息。（我只知道UserId此时）。

理想情况下，我希望设计架构，以便需要单个查询。Account但是，如果不复制到每个对象中，我无法确定如何执行此操作User，因此需要一些后台 Lambda 作业来将更改传播到Account所有User对象的属性——据记录，这似乎比简单地使用更多的资源（和要维护的代码）规范化数据并在每次登录时进行 2 次查询：获取用户，然后获取帐户（使用标识帐户的用户对象内的 FK）。

是否可以设计一种模式，允许一个查询同时获取两者并且不需要非事务性后台作业来传播更新？（事务批量更新是不可能的，因为有超过 25 个用户。）如果不是，那么 2-query 的想法是最好的/可接受的方法吗？

4

1 回答 1

2

我将专注于您问题的一个角度 - 2-query 的想法。在许多情况下，它确实是一种可接受的方法，比其他方法更好。事实上，在许多 NoSQL 使用中，每个用户可见的请求都会导致明显多于两个数据库请求。事实上，人们经常说这就是 NoSQL 系统关心低尾延迟的原因（即，即使 99% 的延迟也应该很低）。

您没有说明为什么要避免使用 2-query 解决方案。您提供的 2-query 实现有两个缺点：

  1. 它的成本更高：您需要执行两个查询而不是一个，成本（当读取小于 4 KB 时）是单次读取的两倍。
  2. 如果您需要执行第一个查询，则延迟会加倍，然后才能执行第二个查询。

您可以使用一些技巧来解决这两个问题，具体取决于您的用例的更多细节：

对于延迟：您没有在应用程序中说明什么是“用户 ID”。如果它是某种唯一的数字标识符，也许它可以被设置成可以直接从用户id确定账户id，而不需要查表（例如，用户id的第一位是账户id）。如果是这种情况，您可以同时启动两个查找，而不会使延迟加倍。成本仍然会翻倍，但延迟不会。

对于成本：如果每个帐户有大量用户（你说有超过 25 个 - 我不知道是不是更多），缓存帐户数据可能很有用，这样不是每个用户查找将需要再次读取帐户数据 - 它可能经常被缓存。如果帐户信息很少更改并且它的一致性不是什么大问题（我不知道是不是......），您还可以通过对帐户信息进行“最终一致性”读取来解决 - 这需要花费一半常规的“一致”阅读。

于 2020-11-10T23:03:31.840 回答