Firebase根集合与集合中的子集合的性能/计费权衡是什么
我知道根级firebase集合是最灵活和可伸缩的，子集合不能轻易删除。在计费方面，我知道firestore的存储数据总量、数据库操作和结果集返回的数据量。但比方说，对于一个包含消息的应用程序，我正在讨论不同的数据库体系结构方法
仅使用Root级别集合：
- 会话集合字段
- 成员（用户引用数组）
- 上次接收时间
- 会话ID（会话文档参考）
对对话和消息子集合使用根集合
- 会话集合字段
- 成员（用户引用数组）
- lastReceivedTime
- 消息子集合
- 内容
- 日期时间
- 来自（用户参考）
收藏
共有1个答案
根据Firestore账单文件：
使用Cloud Firestore时，您需要支付以下费用：
- 您执行的读取、写入和删除次数。
- 您的数据库使用的存储量，包括元数据和索引的开销。
- 您使用的网络带宽量。
除非你能证明你在结构上的改变在测量这些东西的方式上有任何改变，否则你的计费没有显著的变化。
如果所有查询仍然读取、写入和删除相同数量的文档，那么第1点的账单将保持不变。
如果您的所有文档仍然包含相同的数据，那么第2点的账单将保持不变。
如果前两个假设仍然成立，那么传输所有内容的网络带宽基本相同，这意味着第2点的计费将保持不变。
由于文档路径的存储和传输方式，这里和那里可能会有一些字节的差异。假设更长的文档路径将占用更多的存储字节和带宽，那么更深入的收集可能会更昂贵一些。但在我看来，如果您试图优化每个文档中的几个字节的数据，那么您应该表明成本上的差异实际上是值得的。如果您还没有计算出节省的成本，那么这是一个过早的优化，可能不值得花时间。做任何能为你节省更多时间的事，这样你就能完成更多的工作。
-
我正在尝试为firestore中的社交媒体应用程序组织数据。为帖子创建一个新集合或将其放入用户的子集合更好吗？ 深度应该是一样的，但是一种方式比另一种方式有什么优势吗？ 创建新集合： 职位（集合） 用户（集合） 用户中的子集合： 用户（集合）
-
问题内容： 我一直遇到这个问题： 我想让hibernate管理一个表示集合集合的表。例如： 地图地图 套装清单 清单地图 例如，我希望能够代表这一点： 作为一个表： 没有自定义的hibernate代码似乎是不可能的，我不介意。但是我希望有人对自定义代码的外观有所指导。 我应该扩展AbstractPersistentCollection吗？ CompositeUserType？ 可以管理多个表是否正
-
我是Java 8的新手。我仍然不了解这个API，但是我做了一个小型的非正式基准测试来比较新的Streams API与好的旧集合的性能。 测试包括筛选一个列表，并对每个偶数计算平方根，并将其存储在的结果中。 代码如下： 问题： 这个测试公平吗？我犯错了吗？ 流比集合慢吗？有没有人在这方面做了一个很好的正式基准？ 我应该争取哪种方法？ 更新结果。 按照@pveentjer的建议，我在JVM预热（1k次
-
在我的集合的SnapshotListener中，我使用以下命令循环遍历文档: 在 for 循环中的每个文档中，让我们称之为 ，我在 Cloud Firestore 上还有另一个文档集合。我想检索内子集合中的所有文档（每个文档只有一个字符串字段）。我能够做一个来获取本身，我用它来获取字符串字段，但我不知道如何获取其子集合中的文档。
-
Map和Set都叫做集合，但是他们也有所不同。Set常被用来检查对象中是否存在某个键名，Map集合常被用来获取已存的信息。 Set Set是有序列表，含有相互独立的非重复值。 创建Set 既然我们现在不知道Set长什么样，有什么价值，那么何不创建一个Set集合看看呢？ 创建一个Set集合，你可以这样做： let set = new Set(); console.log(set);