【问题标题】:What is the best way to store a (potentially) huge list in Firestore?在 Firestore 中存储(可能)巨大列表的最佳方式是什么?
【发布时间】:2020-01-06 12:37:16
【问题描述】:

我有一个包含大量用户及其详细信息的用户集合。我还有一个通知集合,用户可以查询。我预计通知的数量至少会达到数千,但多年来可能会达到数万。

我希望用户能够将通知标记为“已看到”。我该怎么办?

我考虑过以下选项:

  • 向每个用户文档添加一个数组notificationsSeen,其中包含对通知文档的引用。不过,如果用户看到了例如,我害怕在这里达到大小限制。 50k 条通知。
  • 在用户中添加相同但作为子集合。不过我不知道该怎么做,因为我真的只需要一个属性(通知 ID)。我是否将通知 ID 作为子集合文档 ID 并且文档上没有字段?我是否让 Firestore 生成随机 ID 并将通知 ID 分配为子集合的属性?
  • 向每个通知文档添加一个数组seenBy,其中包含对用户文档的引用。虽然这将允许用户查看其他用户看到了哪些通知,但我不希望这样。

希望你能帮助我,我没有想法,我不知道如何实现我迄今为止最好的想法(用户的子集合),这里也提到了作为解决方案:@ 987654321@(但没有实现细节)。

【问题讨论】:

    标签: firebase google-cloud-firestore


    【解决方案1】:

    唯一在 Firestore 中存储任意大数据列表的可扩展方式是使用集合中的文档。数组类型字段无法针对不断增长的数据列表进行扩展,因为这些项目最终将超过单个文档的 1MB 大小限制,这显然会导致规模问题。

    可以有一个没有字段的文档。如果您需要做的只是记录文档存在以便稍后在该集合中检查它的存在,那很好。如果您绝对确定 ID 符合 Firestore 中的有效 ID,则可以使用通知 ID 作为文档 ID。否则,你应该给它一个随机的ID,并将通知ID作为一个字段放在文档中,以便以后查询。

    您需要熟悉 the documentation on Firestore limits,它涉及文档的最大大小,以及 Firestore 文档 ID 的有效字符。

    【讨论】:

    • 感谢您的快速回答。这肯定排除了选项 1,因为我对选项 3 不满意,所以我会尝试选项 2,看看效果如何。通知 ID 是由 Firestore 生成的,所以这应该不是问题。接受这个答案,因为它更完整。对不起!
    【解决方案2】:

    第一个选项是不可能的,因为由 firebase 定义的文档大小限制,第二个和第三个选项是可能的,但是第二个选项更好地实现此功能,在第二个选项中,我更喜欢将通知 ID 设置为文档 ID在子集合中,但将通知 id 设置为文档中的属性也是有效的(此选项更适合具有相同 id 的多个文档的情况,例如帖子集合,其中用户发布了多个帖子)。

    【讨论】:

    • 第三个选项到底怎么不可能?从技术上讲,它应该与第二个选项相同吗?其余的都是有道理的,谢谢。
    • 嗨,我的错,我有点困惑,我认为在第三个选项中你也在通知文档中存储为数组,更改了答案
    【解决方案3】:

    可以为每个用户的通知建立一个集合。您可以在阅读通知后删除用户特定的文档。您还可以添加一些 on_snapshot 目标以在将其添加到集合后发送通知。

    【讨论】:

      猜你喜欢
      • 2014-07-08
      • 2021-11-30
      • 2011-11-23
      • 2022-01-12
      • 1970-01-01
      • 2013-06-28
      • 2011-01-02
      • 2011-04-17
      • 2013-06-14
      相关资源
      最近更新 更多