我正在使用 Firebase 来存储用户配置文件。我试图在每个用户配置文件中放入最少的数据(遵循有关结构化数据的文档中建议的良好做法)，但由于我有超过 220K 的用户配置文件，当以 JSON 格式下载所有用户配置文件时，它仍然代表 150MB。
当然，它会越来越大，因为我打算拥有更多用户:)
我无法再对这些用户配置文件进行查询，因为每次这样做时，我都会达到 100% 的数据库 I/O 容量，因此当前使用该应用程序的用户执行的一些其他请求最终会出现错误。
我知道在使用查询时，Firebase 需要考虑列表中的所有数据，从而从磁盘中读取所有数据。而且 150MB 的数据似乎太多了。
那么在达到 100% 的数据库 I/O 容量之前是否存在实际限制？在这种情况下，Firebase 查询究竟有什么用处？
如果我只有少量数据，我真的不需要查询，我可以轻松下载所有数据。但是现在我有很多数据，我不能再使用查询了，当我最需要它们的时候......
最佳答案
这里的核心问题不是查询或数据的大小，它只是在不经常查询数据时将数据预热到内存(即从磁盘加载)所需的时间。这可能只是一个开发问题，因为在生产中，此查询可能是更常用的 Assets 。
但是如果目标是提高初始加载的性能，这里唯一合理的答案是查询更少的数据。 150MB 很重要。尝试通过无线网络在计算机之间复制一个 150MB 的文件，您将了解通过 Internet 发送它或从文件服务器将其加载到内存中的感觉。
这在很大程度上取决于用例，您尚未包括在内。
假设您有相当标准的搜索条件(例如您搜索电子邮件地址)，您可以 use indices 单独存储电子邮件地址以减少查询的数据集。
/search_by_email/$user_id/<email address>
现在，而不是每条记录 50k，您只有字节来存储每条记录的电子邮件地址——一个更小的有效载荷可以预热到内存中。
假设您正在寻找强大的搜索功能，最好的答案是使用真正的搜索引擎。例如，启用 private backups 并导出到 BigQuery，或使用 ElasticSearch(参见 Flashlight 示例)。
关于Firebase:对大型数据集的查询，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/34676208/