Cloud Firestore 上一组对象的数组与映射与子集合

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）注册为应用程序的用户时，云函数需要检查他/她是否是另一个应用程序用户的联系人。如果他/她是，则需要更新他/她与该“用户”的联系记录，以表明他/她现在是应用程序成员。

例如，如果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）将新更新的数组保存回数据库.

你能想出更好的数据结构来处理这些数据吗？

我想将联系人存储在（1）联系人对象的“地图”（而不是联系人对象的数组）中，或（2）联系人的“子集合”中。我认为这两种数据结构对于更新特定联系人的对象更有效。因此，这两个选项将使 Cloud Functions 更高效。

另一方面，我认为“数组”（1）更容易添加更多联系人，（2）更容易在 UI 上显示（使用<FlatList>.）这些任务直接影响用户的体验。所以，我认为这些选项听起来最合适。尽管 Cloud Function 的效率较低，但对用户的影响较小（如果有的话）。此外，我认为执行 Cloud Functions 的成本与“处理”的数据量没有任何关系。我了解成本主要取决于检索的文档数量。不是吗？

编辑（添加有关预期查询和数据量的更多信息）：

1. 预期量：

• 用户数量： 100,000（但应该可以扩展到 100 万）

• 每个用户的联系人数量：我不知道！我猜大多数人的联系人少于 1,000 个（这是联系人数组的大小）。为了避免达到文档大小的 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 次

• 平台：云函数 - 不是用户查询

• 查询：如本问题开头所示，每当用户在应用程序上注册时，云函数都需要检查他/她是否是另一个应用程序用户的“联系人”。如果他/她是，则需要更新他/她与该“用户”的联系记录，以表明他/她现在是应用程序成员。（请参考本问题开头的代码）

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

Answer 1

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