MongoDB数据建模：文档嵌入困境答案

【问题标题】：MongoDB data modeling: Document embedding dilemmaMongoDB数据建模：文档嵌入困境
【发布时间】：2013-08-04 18:55:35
【问题描述】：

假设我有一个应用程序，它接收带有两个参数的请求：X 和 Y。我要做的就是计算这些请求，并且我想使用 MongoDB 来完成任务。

我可以想到两种方法在 MongoDB 中存储该信息：

1。每个 X 和 Y 组合都有一个文档：

{
  _id : "X+Y",
  count : 34
}

2。将 Y 嵌入 X 中，意味着每个 X 都有一个文档，该文档总结了该 X 的所有请求：

{
  _id : "X",
  total_count : 47,
  y: {
      "Y1" : 34,
      "Y2" : 13
   }
}

这些方法的优缺点是什么？
一种方法是否被认为是最佳实践？我还缺少另一种合法的方法吗？这是一个常见的困境吗？

我一直在阅读 MongoDB 的手册 data modeling 部分和 a FAQ discussing this issue，但我并不满意。

谢谢

更新

我的应用预计每天处理大约 50M 的请求，而每个请求包含几个属性（例如 X 和 Y），但数量相对较少（4-5），并且每个请求都应该计算在内（通过插入或更新）。
这些数据将每隔一小时左右查询一次，并且查询预计会使用聚合。这些查询通常会查询最近几天（最多一周）的数据。

【问题讨论】：

标签： mongodb data-modeling

【解决方案1】：

如果您认为可能需要按 X 分组的总计数，请坚持使用第二种方法。此外，如果您可能需要按 Y 对其进行分组，那么对您的数据进行非规范化并存储嵌入在 Ys 中的 Xs 以及嵌入在 Ys 中的 Xs 并不是一个坏习惯。那是因为 mongo 的聚合性能很差。

如果您确定不需要任何类型的聚合，则第一种方法会更好，因为它可以更快地读/写和更少的磁盘空间使用。

或者，如果您不完全确定，请将其存储为：{x: "X", y: "Y", count: 42}。确保为此创建索引{x: 1, y: 1}。这样，您仍然可以选择按“X”或“Y”检索所有文档。请注意，拥有{x: 1, y: 1} 索引意味着您不需要创建{x: 1} 索引以通过“X”查询，只需{y: 1} 以通过“Y”查询。

【讨论】：

第一种方法在读/写方面会更好？！也许如果我查询特定的 X 和 Y，对吗？因为如果我查询多种类型，我必须查询多个文档（比第二种方法更多），据我了解，您查询的文档越多就越糟糕，不是吗？

【解决方案2】：

这样的抽象文档很难给出建议，但请避免使用非描述性的键（或值作为键）。请使用您的文档的真实示例更新您的问题，以及您认为需要使用哪些查询（插入、更新和查找）。这些是可用于设计适当架构的唯一标准。

【讨论】：

我已经更新了这个问题，尽管我仍然认为无论现实世界的例子如何，这些方法都可以用优缺点来描述。