Firebase 最大限度地利用Firestore中的文档存储

我正在做一些论坛项目，并试图找出理想的Firestore数据库结构。 我读到文档的最大大小为1 mg，但是通过在一个文档中存储多个帖子而不是在每个帖子中使用单个文档来最大化每个文档的存储空间，有什么优点和缺点

我想会便宜一些。假设应用程序将使用一个文档中的所有数据，带宽成本将是相同的，但不是多次读取，我将只对一个文档收费。这有意义吗

---

它会更快吗？

您可以在一个文档中存储许多帖子，根据您的应用程序，这样做可能有很好的理由。只要记住几件事：

• Firestore总是读取完整的文档。因此，如果在一个1MB文档中存储100篇文章，而只显示其中的10篇文章，那么读取操作可能减少了10倍，但带宽消耗却增加了10倍。你的移动用户可能也会为此带宽付费
• 实现您自己的分片策略并不总是困难的，但它很少与应用程序功能相关

在任何NoSQL数据库中建模数据时，我的指导原则是：

• 数据库中的模型应用程序屏幕
  我倾向于在应用程序中的屏幕之后对数据库中的数据进行建模。因此，如果您通常在用户启动应用程序时显示最近文章的标题列表，我可能会创建一个仅包含最近文章标题的文档。这样，应用程序只需阅读一份只有标题的文档，而不必阅读每一篇文章。这不仅减少了应用程序需要读取的文档数量，还减少了它所消耗的带宽

• 不要害怕重复数据
  这与前面的指导方针是一致的，在所有NoSQL数据库中都是非常正常的，但与我们许多人从关系数据库中学到的核心内容背道而驰。它有时也被称为非规范化，因为它与关系数据库模型的数据库规范化背道而驰
  继续前面的例子：每个帖子可能都有一个单独的文档，只是为了确保每个帖子都有自己的单点定义。但是你会把那篇文章的一部分存储在很多其他地方，比如我们以前看到的最近的头条新闻。这意味着我们必须将每个新帖子的数据复制到该文档中，可能还要复制到多个其他地方。这个过程被称为扇出，并且有一些
  我发现，只要清楚每个实体的定义要点是什么，这种重复就不会引起关注。因此，在我们的示例中：如果帖子文档本身中的帖子标题与最近标题的文档之间存在差异，我知道我应该更新最近标题的文档，因为帖子文档本身是我对帖子的定义点

所有这些的结果是，我经常将我的数据库视为实际数据存储的一部分，应用程序屏幕的一部分预渲染片段。只要定义的要点清楚，这就非常有效，并允许我为使用数据的应用程序的用户和操作它们的成本定义有效扩展的数据模型

要了解有关NoSQL数据建模的更多信息，请执行以下操作：

• ，其中包含这些预渲染应用程序屏幕的更多示例

---

嘿，弗兰克，在你的推文中看到了这一点。您认为如何将相关数据保存在本地存储上？我通常让Firestore的缓存处理文档的本地存储。在某些情况下，我可以自己更好地实现它，但这通常不值得花费时间。不过那是给我的，所以。