firebase - Cloud Firestore上一组对象的数组vs. map vs.子集合

Question

我正在React-Native中开发一个移动应用程序。数据存储在Cloud Firestore中。 我有一个关于在Cloud Firestore上构造数据的最佳方法的问题。

该应用程序的每个用户在其手机上拥有的联系人列表都被复制到数据库上的文档中。
数据存储在Cloud Firestore上的“数组” 中。下面是一个示例。

例如，对于用户＃1，以下是文档collection("users").doc("1")的内容:

name: "Suzi", 
contacts: [
    {userID:"2", name:"John", appMember: false}, 
    {userID:"3", name:"Cathy", appMember: false} 
]

当联系人之一(John或Cathy)注册为该应用程序的用户时，Cloud Function需要检查他/她是否是另一应用程序用户的联系人。如果是，则需要更新该 “用户” 的联系记录，以表明他/她现在是应用程序成员。

例如，如果John的 John注册为该应用程序的用户，则Cloud Function会将上面的文档更新为如下所示。

name: "Suzi", 
contacts: [
    {userID:"2", name:"John", appMember: true},   // <--- appMember changed from false to true
    {userID:"3", name:"Cathy", appMember: false} 
]

我了解无法直接访问/更新 John的对象 {"userID":"2", "name":"John", "appMember": false}是 。更新此数组的唯一方法是(1)“获取”整个数组，(2)遍历整个数组以找到相关的对象，(3)更新该对象，以及(4)将新的更新后的数组保存回db 。

您能为这种数据想到更好的数据结构吗？

我想将联系人存储在(1)联系人对象的“ map ” (而不是联系人对象的数组)中，或(2)联系人的“子集合” 中。我认为这两个数据结构对于更新特定联系人的对象更为有效。因此，这两个选项将使云功能更加高效。

另一方面，我认为“数组” (1)易于添加更多联系人，以及(2)易于在UI上显示(使用<FlatList>)。这些任务直接影响用户的体验。因此，我认为这些选项听起来最合适。尽管云功能的效率较低，但对用户的影响却较小(如果有的话)。而且，我认为执行Cloud Functions的成本与“已处理”的数据量无关。我了解费用主要取决于检索到的文件数。是不是

编辑(添加有关预期查询和数据量的更多信息):

1.预期数量:

用户数: 100,000(但应可扩展到100万)

每个用户的联系人数量:我不知道!我猜想大多数人的联系人少于1000(这是联系人数组的大小)。为了避免达到文档大小的1MB限制，我想可以将联系人数量限制为10,000。我认为这足以满足99.99％的潜在用户。

2.预期查询:

2.a Contcats更新-用户查询

频率:100,000个用户中的每个用户每天很少几次

平台:用户查询-非云功能

查询:联系人列表应被更新。这涉及:(1)从设备获取联系人列表，(2)将该列表与数据库上的列表进行比较，以及(3)如果发现差异，则对该列表进行一些更改。如上所述，联系人列表可能约为1,000个联系人。注意:如果我能找到一种只对设备联系人进行“更改”的方法，而不是每次用户请求刷新时都处理整个列表，那将更加有效。但是，我找不到找到更改的方法(至少使用React-Native)。

2.b用户注册-用户查询

频率:每天100-1,000次

平台:用户查询-非云功能

查询:每当用户在应用程序上注册时，存储在设备上的联系人列表就会复制到数据库中。如上面的示例所示，只有3个或5个属性，例如UserID，Name，appMember标志)实际上已复制到数据库。我每天应接待大约100到1,000个用户。

2.c用户注册-云功能

频率:每天100-1,000次

平台:云功能-非用户查询

查询:如该问题开头所示，每当一个用户在该应用程序上注册时，Cloud Function就需要检查他/她是否是另一个应用程序用户的“联系人”。如果是，则需要更新该“用户” 的联系记录，以表明他/她现在是应用程序成员。 (请参阅此问题开头的代码)

非常感谢您的努力和时间来思考它并提供您的反馈...

Answer 1

从查询的声音来看，如果每个联系人都存储在每个用户的子集合的文档中，而不是用户文档中的数组，那么您的时间将会轻松得多。它们将更易于查询和修改。