我正在为一家非营利组织做志愿者，构建一个漂亮的数据密集型应用程序。这是我第一次使用 Firestore，因此我仍在学习最佳实践和优化策略。我希望尽可能降低基础设施成本。理想情况下，我能够将成本削减到免费级别，因为该应用程序没有稳定的资金来源，但我意识到这可能不是一个现实的目标。
我已经构建了这个应用程序的简单 MVP 版本，但它的成本比我想象的要高。我完全愿意过度设计解决方案。此时我什至愿意将数据库切换到不同的技术。
目前，我有一些收藏，每个收藏有约 10k 个文档。每个文档基本上只是一个键：值对。为了加载应用程序，我需要全部（或大部分）数据。该网站每天的访问量可能为 500 次，所以我的阅读成本比我想要的要多一些。
最大集合中的数据大约每天更新一次，几天的延迟是可以接受的，因此良好的缓存策略将非常受欢迎。
主要问题是：我看到的大多数建议都说，比起使用更多数据的更少文档，更喜欢使用许多小文档。为什么会这样呢？我想知道在我的情况下，使用一些包含（不完全）尽可能多的数据的大型文档是否是一个更好的主意。具体来说，每个集合中有 n=10 个左右的文档，代表所有 10k 文档中的数据。我可以通过对键进行散列并按 n 进行修改来确定每个键：值对进入哪个文档。然后，当我获取数据时，我只会阅读 10 篇文档。这样做有什么缺点？有更好的方法吗？基本上，我正在寻找除我自己之外的其他观点，这样我以后就不会陷入更糟糕的应用程序。
问题从这里开始：
目前，我有一些收藏，每个收藏有约 10k 个文档。每个文档基本上只是一个键：值对。为了加载应用程序，我需要全部（或大部分）数据。
每当应用程序的单个页面/屏幕需要加载数十个以上文档时，您都应该重新考虑您的数据模型和/或 NoSQL 数据库的选择。请记住：每个文档本质上都是一个文件，希望您不会为每个单独的页面视图打开数以万计的文件而皱眉。
在 NoSQL 数据库中，您应该针对应用程序的用例对数据进行建模。
如果您的应用程序需要 10k 个键值对，请将所有这些对存储在一个文档（或几个文档）中。这样，每个视图只需读取一个或几个文档。这可能意味着您需要重新建模数据和/或存储重复的数据，这使数据的写入变得复杂。但在 NoSQL 中，这正是您应该做出的权衡：让您的读取成本尽可能便宜，无论是在 $$$ 方面还是在其他资源使用方面，即使这会使您的写入操作更加复杂。
如果您对此类考虑不熟悉，我建议您阅读 NoSQL 数据建模技术 并观看 了解 Firestore。