我可以从Firebase中的此类查询期望获得哪些性能？

我在想，如果这个，我会解释的战略，将被推荐在Firebase中使用。我可以从Firebase中的此类查询期望获得哪些性能？

我会先解释我的目标是什么，因为我确定其他人已经解决了同样的问题，也许你们中的一些人可以告诉我通常是如何做到的。

目标是通知所有用户的应用程序，当朋友在共同的“乔治”（基于他们的联系人）现在也是一个值得骄傲的应用程序的新用户。

所以，我的想法是这样做的：

1 - 建立一个收集这种结构：

{ 
    "contacts": 
    { 
     "user1": 
     { 
     {"user239":true} 
     , 
     {"user23":false} 
     , 
     {"user732":true} 
     } 
     , 
     { 
     "user2" : 
     { 
     {"user23":false} 
     , 
     {"user96":false} 
     , 
     {"user88":true} 
     } 
    } 
    } 
}

要保存每个用户的联系人列表。

那么新用户将查询的联系人列表如下：

fbRef.child('contacts').orderByChild('user23').equalTo(false).once('value', showResults, console.error);

然后用户将结果保存在地图中，将值更改为true，然后updateChildren()使用该地图。

现在，如果我们想象我们渴望拥有数十万甚至数百万用户使用该应用程序，这是否合理？

当我们有500万用户和少数几个加入时，这会有多昂贵？

对于这种情况，有没有已知的“最佳策略”？

感谢

来源

2016-09-23 GV3

保持这种简单。每个用户都有一个联系人节点，其中包含联系人信息名称（电子邮件，电话号码等等）。每个用户的应用程序都将观察者添加到包含所有用户的主要用户节点。当乔治注册他的信息被写入主要用户节点并且每个用户将被通知这个新用户。将该名称（电子邮件，电话号码）与他们的联系人列表进行比较，如果匹配，则将George的用户ID添加到联系人列表中。困难的部分是确定你想要使用哪种触发器，这足够精确地知道它是正确的乔治。成千上万的观察员没有问题。 – Jay

+1 @Jay，我认为这是正确的答案。顺便说一句，你永远不会得到5M的用户与另一个应用程序的应用程序，即使你这样做 - 它将是非盈利的Firebase价格。恕我直言 –

实时在火力地堡功能不仅适用于，但专为大型数据集。实时记录流的事实对此非常完美。

与任何大型数据应用程序一样，性能就与您的实施一样好。所以这里有几个需要记住的大数据集。

所以你可以做的是Denormalise的数据。

**/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**

第二种方法适用于迭代大数据集，第一种方法清晰可见。

避免在大型数据集上调用value。通过child_used 调用它有助于对上述数据进行非规范化。

记住Firebase可以处理大量数据，但它取决于您遵循的方法。

例如：如果我们想为任何用户存储'last_logins'，我们可以直接将它存储在特定的对象实例下。当我们想要访问特定用户的'last_logins'时，它将提供访问的方便性。

维护多对多关系

我们已经看到，我们不能嵌套组的用户，因为它不会代表多对多的关系，将离开冗余数据。我们可以创建一个特定组下的索引，其中只包含用户所属组的索引。这将使我们能够轻松获取用户所属的组的列表。

存储一对多关系或静态列表

这里是链接到一些必须用于火力设计的最佳实践。

Performance

Indexing

来源

2016-10-03 06:05:28

我可以从Firebase中的此类查询期望获得哪些性能？

回答

相关问题