【问题标题】:How can I effectively store associated records in cloud firestore?如何有效地将关联记录存储在 Cloud Firestore 中?
【发布时间】:2019-03-22 16:55:10
【问题描述】:

我的 Firestore 应用中有群聊功能。所以,我有一个看起来像这样的消息集合......

{
   text: 'Hi there. This is a message.',
   createdAt: '8/7/2018 3:28:20 PM',
   author: 'GKN1q0Y1D3adLNf4xw84tOzukA22'
}

在上面的示例中,我只是将用户 ID 存储在作者字段中。但是,获取每条消息的整个用户记录并不可行。所以,我改用了这样的东西......

{
   text: 'Hi there. This is a message.',
   createdAt: '8/7/2018 3:28:20 PM',
   author: {
       id: 'GKN1q0Y1D3adLNf4xw84tOzukA22'
       name: 'Charlie',
       avatarURL: 'https://firebasestorage.googleapis.com/...'
   }
}

现在,我可以通过对消息集合的单个查询来显示作者的姓名并显示他们的头像。这很好,但是当用户更改他们的头像时会发生什么?还是他们的名字?

我是否只是编写一个云函数来更新此人发送的每条消息,知道一个人可能会发送数千条消息?在单个云函数调用中进行潜在的数千次写入是否合理?

【问题讨论】:

    标签: google-cloud-firestore


    【解决方案1】:

    如果您要求所有消息必须始终以最新的头像显示,那么您可能不希望在所有这些消息中复制该数据。当用户的消息数量变得非常大,并且他们想要更改他们的头像时,您需要查询所有这些消息并更新所有这些消息,这可能会很昂贵。

    相反,您可能希望存储以用户名为关键字的头像,并要求客户端获取该文档以在更新发生时获取更新。假设客户端会缓存文档直到它发生更改,您将通过这种方式产生很少的额外读取。

    底线是您必须比较每个实施的成本,并根据您的速度/大小/成本限制做出决定。你不可能总是三者中的佼佼者。

    【讨论】:

    • 那很快。我喜欢这个网站。您描述的头像解决方案效果很好,但名称仍然是一个问题。 “如果您要求所有消息必须始终以最新的头像显示,那么您可能不希望在所有这些消息中复制该数据。”我想我只是要放宽这个要求。只是想确保没有我遗漏的替代解决方案。谢谢。
    猜你喜欢
    • 2018-12-30
    • 1970-01-01
    • 1970-01-01
    • 2018-05-17
    • 1970-01-01
    • 2020-03-01
    • 2018-04-25
    • 2019-07-21
    • 1970-01-01
    相关资源
    最近更新 更多