我正在使用Firebase来存储用户个人资料。我试图在每个用户配置文件中放入最少量的数据（遵循文档中关于构造数据的良好实践），但由于我有超过220K的用户配置文件，因此当以JSON所有用户配置文件下载时，它仍然代表150MB。 当然，随着我打算拥有更多用户，它会变得越来越大：）
我无法再对这些用户配置文件进行查询，因为每次执行此操作时，我都会达到100％的数据库I / O容量，因此当前使用该应用的用户执行的其他一些请求最终会出错。< / p>
我了解在使用查询时，Firebase需要考虑列表中的所有数据，从而从磁盘读取所有数据。 150MB的数据似乎太多了。
在达到100％数据库I / O容量之前是否存在实际限制？在这种情况下，Firebase查询的实用性究竟是什么？ 如果我只是拥有少量数据，我真的不需要查询，我可以轻松下载所有数据。但是现在我有很多数据，当我最需要它时，我不能再使用查询......
答案 0 :(得分：6)
这里的核心问题不是查询或数据的大小，它只是在不经常查询时将数据加热到内存（即从磁盘加载）所需的时间。它可能只是一个开发问题，因为在生产中这个查询可能是一个更常用的资产。
但如果目标是提高初始加载的性能，那么这里唯一合理的答案是查询较少的数据。 150MB是重要的。尝试通过无线网络在计算机之间复制150MB文件，您可以通过互联网了解它是什么样的，或者从文件服务器将其加载到内存中。
这里的很多内容取决于您未包含的用例。
假设您有相当标准的搜索条件（例如，您搜索电子邮件地址），您可以use indices分别存储电子邮件地址，以减少查询的数据集。
/search_by_email/$user_id/<email address>
现在，不是每条记录50k，而是只有每个记录存储电子邮件地址的字节数 - 一个小得多的负载加热到内存中。
假设您正在寻找强大的搜索功能，最好的答案是使用真正的搜索引擎。例如，启用private backups并导出到BigQuery，或者使用ElasticSearch（请参阅Flashlight以获取示例）。