在Firestore中最大限度地使用文档存储
我正在处理一些发布论坛项目，并试图找出理想的FiRecovery数据库结构。我读到文档的最大大小为1 mg，但通过将多个帖子存储在文档中而不是为每个帖子使用单个文档来最大限度地利用每个文档的存储空间的利弊是什么？
我认为它会更便宜。假设应用程序将使用文档中的所有数据，带宽成本是相同的，但不是多次读取，我将只对一个文档收费。这有意义吗？
它也会更快吗？
共有1个答案
你可以在一个文档中存储许多帖子，根据你的应用程序，这样做可能有充分的理由。记住几件事：
- Firestore总是阅读完整的文档。因此，如果在一个1MB文档中存储100篇文章，只显示其中的10篇文章，那么读取操作可能减少了10倍，但带宽消耗增加了10倍。你的移动用户可能也会为带宽付费
- 实现自己的切分策略并不总是困难的，但它很少与应用程序功能相关
在任何NoSQL数据库中建模数据时，我的指导原则是：
>
数据库中的模型应用程序屏幕
我倾向于根据应用程序中的屏幕对数据库中的数据进行建模。因此，如果你通常在用户启动应用程序时显示最近文章的标题列表，我实际上可能会创建一个只包含最近文章标题的文档。这样一来，应用程序只需阅读一篇只有标题的文档，而不必阅读每一篇文章。这不仅减少了应用程序需要读取的文档数量，还减少了它所消耗的带宽。
不要害怕复制数据
这与前面的指南齐头并进，在所有非关系型数据库中非常正常，但违背了我们许多人从关系型数据库中学到的核心。它有时也被称为非规范化，因为它对抗关系数据库模型的数据库规范化。
继续前面的例子：每个帖子可能都有一个单独的文档，只是为了确保每个帖子都有自己的单点定义。但你会把那篇文章的部分内容存储在许多其他地方，比如我们之前看到的最近的头条新闻。这意味着我们必须将每个新帖子的数据复制到该文档中，可能还要复制到多个其他地方。这个过程被称为扇出，有一些常用的策略来更新这些非规范化数据。
我发现，只要清楚每个实体的主要定义是什么，这种重复就不会引起任何担忧。因此，在我们的例子中：如果帖子文档本身中的帖子标题与最近标题的文档之间存在差异，我知道我应该更新最近标题的文档，因为帖子文档本身是我对帖子的定义点。
这一切的结果是，我经常将我的数据库视为实际数据存储的一部分，应用程序屏幕的一部分预渲染片段。只要定义的要点明确，这就非常有效，并允许我为使用数据的应用程序的用户和操作它们的成本定义有效扩展的数据模型。
要了解有关NoSQL数据建模的更多信息，请执行以下操作：
- NoSQL数据建模
- 了解Cloud Firestore，其中包含更多这些预渲染应用程序屏幕的示例
-
我已经在树莓派7英寸上安装了tarantool，并希望尽量减少与硬盘（sd卡）的交互。有什么简单的方法可以做到这一点。hdd的真正用法是什么？
-
我试图实现的很简单。只有当数据库不存在时，我才需要在数据库中创建一个用户条目。 应用程序流程： 使用Firebase身份验证（获取UID）创建用户 客户端代码（创建操作）： firestore规则： 附加信息： 正如您可能已经知道的那样，代码不起作用。每次我运行客户端代码时，当前用户都会被一个新文档完全替换。但是，如果我从规则中删除以下行，一切都会正常工作： 但现在问题来了，如何保护用户文档中的数
-
我正在使用CUDA上运行的Marching Cubes算法从体积数据生成网格。 我尝试过保存网格并以3种方式渲染它。 将一组粗略的三角形保存为顶点数据的连续数组。我估计第一次通过时的大小，创建一个OpenGL VBO，将其映射到CUDA，并以下面的格式将顶点数据写入其中 并使用绘制它。 VBO中的冗余顶点，每个立方体的冗余顶点，无索引。 VBO中没有冗余顶点，生成索引。 VBO中的冗余顶点，每个立
-
我的用户可以在子集合中创建文档（比如任务），并使用一系列安全规则检查身份验证、权限和数据有效性。他们甚至可以选择多个任务并将其复制到同一集合中。现在，一个普通用户可能一次最多创建100个任务，但如果有人恶意获取我的数据库凭据，进行身份验证，并尝试以编程方式创建大量有效文档，该怎么办？这将使Firestore的扩展不会出现问题，也会给我的Firebase账单带来意想不到的惊喜。这是我首先关心的问题，
-
是否可以在MongoDB中找到最大的文档大小？ 显示的是平均大小，这并不具有代表性，因为在我的例子中，大小可能会有很大差异。
-
我想像这样更新文档： 但是，如果doc user\u id不存在，上述代码将抛出错误。因此，如果不存在，如何告诉Firestore创建学生，换句话说，行为如下：