1

假设一个文档（级别 1）应该具有N(k)不同类型的项目作为子文档数组（级别 2），并且由于缺乏对深度嵌套数组子文档的查询优化，这些项目存储在单独的集合中。现在，我们应该获取N(d1)1 级文档，每个文档都有N(d2)多个子文档（一个 1 级文档的 2 级文档总数为N(d2)）

将所有这些项目类型放在一个集合中与每种类型的集合有什么优缺点。考虑到以下几点：

  • 使用的存储引擎是WT
    • DB 可以在其他文档被写入同一个集合时读取。在这里。
    • 读写锁是文档级别的，而不是之前的情况下的集合级别。在这里。
  • 允许使用稀疏索引，因为字段可能因类型而异
  • 部署类型为分片集群
  • 所有可查询的字段都被索引（虽然不是盲目的）=>$or操作员可以使用索引
  • 支持一种方法的观点自动意味着它会导致其他方法的性能下降。

在多态集合的情况下查询将如何工作：

  • 所有不同的类型都可以在单个查询（使用$or）操作中获取，然后附加到服务器应用程序中的父文档。我们还可以使用聚合$group将一种类型的文档组合在一起。因此，
    • 减少网络引起的查询延迟。
    • 减少来自服务器的连接数。
  • 由于子文档被附加回其父文档，因此它需要在服务器端进行 for 循环。N(d1)至少必须循环遍历文档 - 如果$group在查询级别使用聚合 - 或者 N(d1) * N(d2)如果子文档尚未分组的话。

如果每种类型都有自己的集合，查询将如何工作：

  • N(k)进行查询后，只要查询返回，我们就可以将子文档附加到其父文档。
  • 我们可以再次使用聚合$group，从而将服务器端循环限制为N(d1)迭代

支持单一集合：

  • 使用的连接数更少。（一致为每个查询 1 个）
  • 一致的延迟。（作为前面一点的暗示）
  • ?

支持多个：

  • 我们更习惯的组织结构。（主观）
  • ?

每个案例如何影响性能？

4

0 回答 0