我正在使用 Firebase 来存储用户个人资料。我尝试在每个用户配置文件中放入最少量的数据（遵循有关结构化数据的文档中建议的良好实践），但由于我有超过 220K 个用户配置文件，因此在以 JSON 格式下载所有用户配置文件时，它仍然代表 150MB。
当然，随着我打算拥有更多用户，它会变得越来越大:)
我无法再对这些用户配置文件进行查询，因为每次这样做时，我都会达到 100% 的数据库 I/O 容量，因此当前使用该应用程序的用户执行的一些其他请求最终会出错。
据我所知，在使用查询时，Firebase 需要考虑列表中的所有数据，从而从磁盘读取所有数据。而且150MB的数据似乎太多了。
那么在达到 100% 数据库 I/O 容量之前是否存在实际限制？在这种情况下，Firebase 查询到底有什么用处？
如果我只有少量数据，我实际上不需要查询，我可以轻松下载所有数据。但现在我有很多数据，当我最需要它们时，我不能再使用查询了......
这里的核心问题不是查询或数据的大小，而是当不经常查询数据时将数据预热到内存（即从磁盘加载数据）所需的时间。这可能只是一个开发问题，因为在生产中此查询可能是更常用的资产。
但如果目标是提高初始负载的性能，那么这里唯一合理的答案是查询更少的数据。 150MB 是很重要的。尝试通过无线网络在计算机之间复制 150MB 文件，您就会了解通过互联网发送该文件或从文件服务器将其加载到内存中的感觉。
这里很多取决于用例，您没有包括在内。
假设您有相当标准的搜索条件（例如，您搜索电子邮件地址），您可以使用索引单独存储电子邮件地址以减少查询的数据集。
/search_by_email/$user_id/<email address>
现在，您只有字节来存储每条记录的电子邮件地址，而不是每条记录 50k，这是一个要小得多的有效负载以预热到内存中。
假设您正在寻找强大的搜索功能，最好的答案是使用真正的搜索引擎。例如，启用私人备份并导出到 BigQuery，或使用 ElasticSearch（请参阅手电筒举个例子）。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
