Firebase 与大型数据集的性能

Posted 2023-03-08

【中文标题】Firebase 与大型数据集的性能

【英文标题】：Performance of Firebase with large data sets

【发布时间】：2013-04-20 19:51:25

【问题描述】：

我正在为一个项目测试 firebase，该项目可能有相当多的密钥，可能是数百万。

我已经测试过使用节点加载几万条记录，加载性能看起来不错。但是，如果我展开根节点，“FORGE”Web UI 会变得异常缓慢并呈现每条记录。

Firebase 是不是针对这种数据量而设计的，还是我做错了什么？

【问题讨论】：

正如 Kato 在下面提到的，这是 Forge 问题，而不是 Firebase 问题。尝试直接导航到更深的路径以处理更大的数据集。

【参考方案1】：

这只是 Forge UI 的局限性。它仍然相当初级。

Firebase 中的实时功能不仅适用于大型数据集，而且专为大型数据集而设计。实时记录流的事实非常适合这一点。

与任何大型数据应用程序一样，性能仅取决于您的实施。因此，对于大型数据集，请牢记以下几点。

去规范化，去规范化，去规范化

如果要迭代一个数据集，并且它的记录可以数以千计，请将其存储在自己的路径中。

这不利于迭代大型数据集：

/users/uid
/users/uid/profile
/users/uid/chat_messages
/users/uid/groups
/users/uid/audit_record

这有利于迭代大型数据集：

/user_profiles/uid
/user_chat_messages/uid
/user_groups/uid
/user_audit_records/uid

在大型数据集上避免“价值”

使用child_added，因为value 必须将整个记录集加载到客户端。

注意对儿童的隐藏value操作

当您调用child_added 时，您实际上是在对每个子记录调用value。因此，如果这些孩子包含大型列表，他们将不得不加载所有数据才能返回。因此，上面的 DENORMALIZE 部分。

【讨论】：

你的意思是，如果我们只是想获取有关用户的所有信息，就像显示用户个人资料页面一样，那么我们使用"This is bad for iterating large data sets" 方法，否则，如果想为管理员显示用户示例列表使用然后我们使用"this is good for iterating large data sets method" ?

@vzhen 差不多，诀窍是记住，当您调用 child_added 或 value（无论哪个）时，您正在下载该路径下的所有数据，包括所有孩子，而不仅仅是您要求的根级元素。

正如 Kato 提到的，child_added 的命名有点令人困惑，因为它也会返回路径下的所有数据，而不管它是什么时候实际添加的。如果您想要“添加新孩子时的事件”，您需要执行ref.limitToLast(1).on('child_added', ... 之类的操作。

/users/uid/chat_messages 上的child_added 与/user_chat_messages/uid 上的child_added 有何不同？我想使用第一种方法，但永远不会在/users/uid 上直接有任何听众。

@ZeeshanAli 不确定您是否已经发现。但是当使用/users/uid/chat_messages 设置并且您想要获取用户信息以显示在个人资料页面上时，这会很慢。它会连同它一起获取所有chat_messages。使用不同的数据路径，并基于 id 进行连接。简而言之：This is bad for iterating large data sets-approach 将很容易降低您的应用程序的速度，而 This is good for iterating large data sets-approach 将很难降低您的应用程序的速度。