Cloud Firestore 数据结构

Question

我正在创建一个应用程序，该应用程序使用 Cloud Firestore 在我们实验室的多个资产上存储有关“事件”的数据。我们收集了几个月的数据，我们平均每月每个资产大约 2000 个事件。每个事件都会捕获一些用户可以查询的元数据。

我一开始用一个非常简单的布局将所有数据导入了firestore。

事件（事件数据的收集） -> EventData（包含一些元数据字段的文档）

据我了解，即使事件的集合变得非常大，对于计费和查询速度来说，这也不是问题（假设我对查询结果进行了某种分页）。使用这种结构，复合索引也非常易于管理。

我看到的问题是，如果有人去查看 Firestore 控制台并打开该集合，我们的读取请求就会激增。似乎对整个系列进行了全面阅读……随着时间的推移，这当然会扼杀我们的计费。我不认为这永远是一个问题，因为最终我们应该达到一切稳定并且不需要经常进入控制台的地步，但是如果当我们拥有一百万或更多记录时有人这样做怎么办。

我的下一个想法是像这样构建数据库：

事件 -> 资产 -> {Asset_Name } -> {year_month} -> {Collection of 带有字段元数据的文档}

这无疑解决了文档集不断增长的问题。我们拥有的资产数量是固定的，事件数量（有效地）也被限制为每月的最大数量。但是，此设置的问题在于管理复合索引。我的原始设置大约需要 5 个索引。我认为这种替代设置意味着我需要每个月为每个资产的每个文档集合设置相同的 5 个索引。

我想也许有一种方法可以让云功能为我管理它（似乎没有为此提供 API）。我认为每个项目的索引数量也有上限。

因此，最后，我正在寻找有关如何构建此数据库以限制读取（如果使用控制台）以及保持索引可管理的建议。我对 NoSQL 还很陌生，也许我完全不了解。

Answer 1

我建议您保持结构不变，就好像这对您有用。您不需要优化以减少控制台读取。控制台读取确实计入您的使用量，但当您打开控制台时，控制台不会加载整个集合。

控制台只加载足够的文档让您滚动一下，然后如果您向下滚动，它会加载更多文档。如果您滚动浏览整个集合，它只会加载整个集合。