最大化 Firestore 中的文档存储空间

Question

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

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

还会更快吗？

Answer 1

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

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

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

• 在您的数据库中为应用程序屏幕建模

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

• 不要害怕重复数据

  这与之前的指南密切相关，在所有 NoSQL 数据库中都很正常，但与我们许多人从关系数据库中学到的核心内容背道而驰。它有时也称为非规范化，因为它与关系数据库模型的数据库规范化相反。

  继续前面的示例：您可能会为每个帖子创建一个单独的文档，以确保每个帖子都有自己的单一定义点。但是您会将该帖子的部分内容存储在许多其他地方，例如我们之前拥有的最近标题文档中。这意味着我们必须将每个新帖子的数据复制到该文档中，并可能复制到其他多个位置。这个过程称为扇出，有一些common strategies for updating this denormalized data。

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

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

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

• NoSQL data modeling
• Getting to know Cloud Firestore，其中包含更多这些预渲染应用程序屏幕的示例。