最大限度地利用 Firestore 中的文档存储空间 [英] Maxing out document storage in Firestore

问题描述

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

I'm working on some posting forum projects and trying to figure out the ideal Firestore database structure. I read that documents have a max size of 1 mg but what are the pros and cons to maxing out the storage space of each document by having multiple posts stored in a document rather than using a single document for each post?

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

I think it would be cheaper. Assuming that the app would make use of all the data in a document, the bandwidth costs would be the same but rather than multiple reads, I would be charged for only one document. Does this make sense?

它也会更快吗?

推荐答案

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

You can likely store many posts in a single document, and depending on your application, there may be good reasons for doing so. Just keep a few things in mind:

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

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

My guidelines when modeling data in any NoSQL database is:

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

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

I tend to model the data in my database after the screens that I have in my application. So if you typically show a list of headlines of recent articles when a user starts the app, I might actually create a document that contains just the headlines of recent articles. That way the app only has to read a single document with just the headlines, instead of having to read each individual post. This reduces not only the number of documents the app needs to read, but also the bandwidth it consumes.

不要害怕重复数据

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

This goes hand-in-hand with the previous guideline, and is very normal across all NoSQL databases, but goes against the core of what many of us have learned from relational databases. It is sometimes also referred to as denormalizing, as it counters the database normalization of relations database models.

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

Continuing the example from before: you'll probably have a separate document for each post, just to make sure that each post has its own single point of definition. But you'll store parts of that post in many other places, such as in the document-of-recent-headlines that we had before. This means that we'll have to duplicate the data for each new post into that document, and possibly multiple other places. This process is known as fan-out, and there are some common strategies for updating this denormalized data.

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

I find that this duplication leads to no concerns, as long as it is clear what the main point of definition for each entity is. So in our example: if there ever is a difference between the headline of a post in the post-document itself, and the document-of-recent-headlines, I know that I should update the document-of-recent-headlines, since the post-document itself is my point-of-definition for the post.

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

The result of all this is that I often see my database as part actual data storage, part prerendered fragments of application screens. As long as the points of definition are clear, that works quite well and allows me to define data models that scale efficiently both for users of the applications that consume the data and for the cost to operate them.

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

To learn more about NoSQL data modeling:

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

• NoSQL data modeling
• Getting to know Cloud Firestore, which contains many more examples of these prerendered application screens.

这篇关于最大限度地利用 Firestore 中的文档存储空间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！