充分利用Firestore中的文档存储空间 [英] Maxing out document storage in Firestore

问题描述

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

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屋！