【问题标题】:Firestore document structureFirestore 文档结构
【发布时间】:2020-04-26 01:32:10
【问题描述】:

由于读取操作过多,我目前正在重新构建我的 Firestore 文档之一。

使用以下结构,文档大小约为 90,000 字节。这可以吗?还是我应该以不同的方式组织我的文档?

如果您有任何建议,请告诉我:)

{
  name: "Acme",
  date_added: "November 5, 2020 at 3:12:16 PM UTC+1",
  id: "f9hh9tvkEd9dgjf3r",
  bg_color: "333333",
  sections: [ // Max 8 sections like the one below
    {
      section_type: "color",
      label: "user defined label",
      description: "some description",
      grid: 4,
      items: [
        {
          cmyk: { c: "0", m: "39", y: "100", k: "20" },
          hex: "C20D19",
          rgb: { r: "194", g: "13", b: "25" },
          name: "Rouge",
          date_added: "November 5, 2018 at 3:12:16 PM UTC+1"
        }
        // ... ~20 of these items
      ]
  ],
  users: [
    {
      name: "John Appleseed",
      email: "john@appleseed.com",
      id: "Kf3ghxS52fZ9G6Y1b8BD5pv6Cfn5",
      role: "member",
      date_added: "November 10, 2020 at 09:33:27 PM UTC+1"
    },
    // Let's say there's 300 users
  ]
}

【问题讨论】:

    标签: firebase database-design google-cloud-platform google-cloud-firestore


    【解决方案1】:

    使用以下结构,文档大小约为 90 000 字节。这样可以吗?

    只要您留在maximum size that is allowed for a document which is 1 MiB (1,048,576 bytes) 内,您就可以继续使用您的架构。无论您的文档大小是 90,000 字节 (0.09 MiB) 还是最大 1 Mib,您的应用都可以正常运行和扩展。

    由于读取操作过多,我目前正在重新构建我的 Firestore 文档之一。

    如果您在文档中存储大量数据并且文档应该由大量用户更新,那么您需要注意另一个限制。因此,每个文档每秒只能写入 1 次。因此,如果您遇到很多用户都试图一次将数据写入/更新到相同文档的情况,您可能会开始看到其中一些写入失败。所以,如果你达到了这个限制,那么你应该重新考虑你的文档结构,从一个数组中取出数据,例如在一个单独的子集合中。

    或者我应该以不同的方式构建我的文档?

    我们通常根据要执行的查询来构建数据库。在不知道这一点的情况下,很难说哪种模式可能更好。因此,如果遇到困难,请发布另一个问题,其中包含实际的数据库架构和您需要的查询,以便我们查看。

    【讨论】:

    • 谢谢,亚历克斯!我想在文档大小方面我是安全的。关于更新文档,这通常只由一个用户完成,而不是经常完成。除了用户添加文档时,他们的 uid 将被添加到用户数组中。而关于查询,将同时查询整个文档,如上所示。这就是我现有结构的问题,因为每个部分都有自己的子集合。
    • 在文档大小方面我很安全,是的。 关于更新文档,这通常只由一个用户完成,而不是经常。 那很好。 每个部分都有自己的子集合。 恐怕我不明白您的意思,因为我在您的文档中没有看到任何子集合,只有字符串类型的属性和一个数组。如果您想对整个数据库架构有所了解,请发布另一个新问题,以便我和其他 Firebase 开发人员可以为您提供帮助。
    • 嗨,尼古拉斯!我可以帮助您了解其他信息吗?如果您认为我的回答对您有所帮助,请考虑采纳(✔️)。我真的很感激。谢谢!
    • @AlexMamo 我看到的文档大小的另一个可能问题是对延迟补偿的影响。这对我来说是一个重要的权衡,因为我考虑在 1 个文档中存储多少与在多个文档中存储。从我的测试中,我看到了不一致的结果。哪个对延迟补偿的影响更大:查询结果大小或文档大小?到目前为止的完整问题和发现:stackoverflow.com/questions/61254151/…
    • @learningAngular 是的,这是这两个选项之间的交易。根据您的要求,您应该选择一个,或者另一个。
    【解决方案2】:

    Firestore 中文档的最大大小为 1MB。话虽如此,你是安全的,但是......

    • 如果该文档经常更改,将下载整个文档 每个用户对可能增加您的网络出口的每一次更改 并对您用户的移动数据计划产生一些影响。还是从我的 体验它比数据一更容易达到读取限制。
    • 如果您需要用户能够更改该文档,您无法通过 Firestore 安全规则对其进行管理,但您必须使用对运行次数也有限制的函数。
    • 我发现了潜在的隐私问题。在您当前的设置中,所有用户都可以访问其他用户的个人数据(姓名、姓氏、电子邮件等)。考虑可能将用户放在两个单独的文档中。一份所有人都可以访问的公共文档,而如果数据只能由您访问和编辑,您将拥有一份私人文档。如果用户需要编辑他们自己的数据,那么您将不得不为每个用户提供私人和公共文档以及一个包含所有人都应该看到的数据的公共索引。您不必使用函数更新该公共索引。

    【讨论】:

    • 很好的答案,谢谢!为了更好地澄清我的用例:文档在所有者首次设置时大部分都会对其进行写入,之后主要是读取操作。关于用户隐私的好提示,我可以将 uid 与角色一起存储,我认为这应该可以解决吗?这只是一个桌面应用程序,所以我认为数据大小不会是一个大问题?
    • 您不必将角色存储在 Firestore 中,除非它们需要被其他用户看到。您可以在自定义声明(用户令牌)link 中设置角色。与设置 Firestore 安全规则相比,您不必从数据库中读取,这算作读取来获取角色,而是直接从免费的用户令牌中读取 link
    • 哦,我不知道,太好了!但就我而言,用户可以访问更多文档,例如我发布的文档,他们的角色可以是其他角色(“管理员”或“成员”)
    • 您可以为每个用户分配多个角色。检查我提供的这两个链接以更好地了解可以做什么,您可以节省很多阅读量。
    猜你喜欢
    • 2018-11-09
    • 1970-01-01
    • 1970-01-01
    • 2018-08-20
    • 2023-03-08
    • 1970-01-01
    • 2016-07-24
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多