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

Question

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

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

它也会更快吗？

Answer 1

您可能会在一个文档中存储许多帖子，并且根据您的应用程序，这样做可能有充分的理由。请记住以下几点：

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

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

• 数据库中的模型应用程序屏幕

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

• 不要害怕重复数据

  这与之前的指南是一致的，并且在所有 NoSQL 数据库中都很正常，但与我们许多人从关系数据库中学到的核心知识背道而驰。它有时也被称为非规范化，因为它对抗关系数据库模型的数据库规范化。

  继续之前的示例：您可能会为每个帖子创建一个单独的文档，以确保每个帖子都有自己的单点定义。但是您会将该帖子的部分内容存储在许多其他位置，例如我们之前拥有的最近头条新闻文档中。这意味着我们必须将每个新帖子的数据复制到该文档中，可能还有多个其他地方。这个过程被称为扇出，有一些常见的策略来更新这个非规范化数据。

  我发现这种重复不会导致任何问题，只要每个实体的主要定义点是明确的。因此，在我们的示例中：如果发布文档本身中的帖子标题与最近标题文档之间存在差异，我知道我应该更新最近标题文档，因为post-document 本身就是我对 post 的定义点。

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

要了解有关 NoSQL 数据建模的更多信息：

• NoSQL 数据建模
• 了解 Cloud Firestore，其中包含这些预渲染应用程序屏幕的更多示例。