我正在创建一个应用程序，该应用程序使用Cloud Firestore在我们的实验室中的多个资产上存储有关“事件”的数据。我们收集了几个月的数据，平均每个资产每月平均大约2000个事件。每个事件都会捕获用户可以查询的一些元数据。
首先，我以非常简单的布局将所有数据导入了Firestore。
事件（事件数据的收集） -> EventData（包含一些元数据字段的文档）
根据我的理解，即使事件的集合变得很大，对于计费和查询速度而言，这也不是问题（假设我对查询结果进行了某种分页）。通过这种结构，复合索引也非常易于管理。
我看到的问题是，如果有人去看了Firestore控制台并提出了该集合，我们的读取请求就会通过屋顶。似乎已经对整个馆藏进行了完整的阅读……随着时间的流逝，这当然会杀死我们的账单。我认为这不会永远成为问题，因为最终我们应该可以使所有内容保持稳定并且不需要经常进入控制台，但是如果有人拥有一百万或更多的记录，如果有人这样做，该怎么办？ / p>
我的下一个想法是像这样构建数据库：
事件->资产-> {Asset_Name}-> {year_month}-> { 带有字段元数据的文档}
这无疑解决了文档收集不断增长的问题。我们拥有的资产数量是固定的，事件的数量（有效）也被设置为每月最大金额。但是，此设置的问题是管理复合索引。我的原始设置大约需要5个索引。我认为这种替代设置意味着每个月每个资产的每个文档集合都需要设置相同的5个索引。
我认为也许可以使用一种云功能为我管理它（似乎没有针对此的API）。我认为每个项目的索引数量也受到限制。
因此，最后，我正在寻找有关如何构造此数据库以限制使用控制台限制读取的建议，以及如何使索引易于管理。我对NoSQL还是很陌生，也许我已经完全不了解了。
答案 0 :(得分：0)
如果这对您有用，我建议您保持结构不变。您无需进行优化以减少控制台读取。控制台读取确实会影响您的使用，但是打开控制台时，控制台不会加载整个集合。
控制台仅加载足够的文档以使您稍微滚动一下，然后在向下滚动时加载更多的文档。如果您滚动整个收藏夹，它将仅加载整个收藏夹。