Firebase可扩展性限制 [英] Firebase Scalability Limit

问题描述

此帖子说，FireBase在个别节点开始时会出现问题有1-10 +百万儿童。
如果我们有超过1000万的应用程序，应该如何处理应用程序中的用户？在所有的例子我虽然用户只是单个节点用户的孩子。

This post says that FireBase will have an issue coming when an individual node begins to have 1-10+ million children. How should one handle Users in an app if we have more than 10 million? In all the examples I though Users were simply children of a single node "Users".

推荐答案

Firebase不是理想的处理长项目列表。这些长列表的问题不是存储数据，而是访问数据。

Firebase is not ideal for processing long lists of items. The problem with these long lists is not so much storing the data as it is accessing the data.

每当您访问列表（例如 ref.child（'users'）。on（... ） Firebase必须考虑服务器上该列表中的所有项目;即使你只下载一些用户（ .limitToLast（10）），它也必须考虑每个用户。

Whenever you access the list (e.g. ref.child('users').on(...) Firebase has to consider all items in that list on the server; even when you are only downloading a few users (.limitToLast(10)), it has to consider each user.

但是，只要您从不尝试访问列表，您可以根据需要存储尽可能多的用户，但这意味着您总是直接访问它们，例如 ref.child（'users'）。child（auth.uid）.on（... 。

But as long as you never try to access the list, you can store as many users under there as you want. But that means that you always access them directly, e.g. ref.child('users').child(auth.uid).on(....

这限制了你可以实现的用例，所以通常开发者按照他们需要使用它们的方式创建子列表。例如，如果每个用户保留一个朋友列表，你可以保留 ref。 child（'users_friends'）。child（auth.id）.on（... 并用 ref.child auth.uid）。这样，你只读一小部分用户列表，然后直接加载每个用户。

This limits the use-cases you can implement, so typically developers create sublists of users by how they need to use them. For example if each user is keeping a list of friends, you could keep those like ref.child('users_friends').child(auth.id).on(... and look each of them up with ref.child('users').child(auth.uid) again. That way, you're only reading a small list of users and then loading each of those users directly.

这篇关于Firebase可扩展性限制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！