当许多用户读取相同的集合时，如何减少Fi还原文档的读取

Question

，这是我们的问题：

我们正在构建一个员工目录。组织中的每个员工都可以搜索和查看同一组织中的所有其他员工。

我们目前正在考虑两种不同的方法来存储和管理员工：

方法A

在每个组织下保持员工的分组。在这个模型中，每个员工都将是自己的文档。

这种方法的好处是我们充分利用了防火墙中的子集合提供的所有特性。我们可以轻松地添加、更新和删除员工，并且随着集合的增长，不需要进行任何真正的更改。

这种方法的主要问题是，我们将有大量的阅读。如果我们以一家拥有1,000名员工的公司为例，假设每个员工每天访问该目录5次，那么我们将查看1,000 * 5 * 1,000 = 5,000,000 reads/day。这似乎太多了，因为一组资源每天只会更改几次(假设员工流失)。

这个问题的明显解决方案似乎是缓存员工，但我不太确定我们如何才能不使用云函数来获取员工？

方法B

在每个组织文件上维护一个或多个员工。在这种模式中，所有员工都将存在于组织文档中。

这种方法的好处是，我们只需要读取单个文档即可获取所有员工。这意味着获取收集将是一个更快和更便宜的。

这种方法的主要问题是，随着员工数组大小的增加，我们将不得不拆分组织文档。这应该不会有太多的问题，直到有超过5k的雇员，但它似乎仍然相当混乱。一旦将数组拆分，我们还需要管理每个员工所属的块，这会使更新变得过于复杂。

说到更新，这种方法还会使员工更新复杂化，因为每次更新员工时，都必须重写整个数组。

有没有其他更好的方法来解决这个问题，还是我忽略了一些简单的解决方案？

提前谢谢。

Answer 1

方法B不会缩放，将来你会遇到麻烦。这不是推荐的。此外，为了保护该文档，您将在安全性规则方面增加复杂性，并且您还可能遇到加载下的文档写入的速率限制。我不建议这样做。

方法A是合乎逻辑的选择。它更干净更有感染力。而500万读物仅为3美元，对于一家拥有1000名员工的公司来说，这是一个微不足道的数字。这比正确实现B的开发工作要少得多。如果你真的需要降低成本，那就不要让每个人一次就把所有用户的文档都加载进去。如果用户需要浏览列表，则使用分页。