Mongodb 数据存储性能 - 一个文档包含数组中的项目与每个项目包含多个文档

Question

我每天在 Mongodb 集合中为每条记录保存统计数据。例如我的收藏看起来大致像

{ record_id: 12345, date: Date(2011,12,13), stat_value_1:12345, stat_value_2:98765 }

每个 record_id/date 组合都是唯一的。我查询集合以使用 map-reduce 获取给定日期范围内每条记录的统计信息。

就读取查询性能而言，这种策略是否优于每个 record_id 存储一个文档，其中包含一组统计数据，就像上面的字典一样:

{ _id: record_id, stats: [
{ date: Date(2011,12,11), stat_value_1:39884, stat_value_2:98765 },
{ date: Date(2011,12,12), stat_value_1:38555, stat_value_2:4665 },
{ date: Date(2011,12,13), stat_value_1:12345, stat_value_2:265 },
]}

从好的方面来说，我需要一个查询来获取记录的整个统计历史记录，而无需诉诸较慢的 map-reduce 方法，而在不利的方面，我将不得不汇总给定日期范围内的统计数据在我的应用程序代码中，如果记录超出当前填充大小，则会继续进行一些磁盘重新分配。

Answer 1

我认为这取决于使用场景。如果单个聚合的数据集很小，比如 700 条记录，而您想实时执行此操作，我认为最好选择另一个选项并查询所有单独的记录并在客户端聚合它们。这避免了 Map/Reduce 开销，更易于维护，并且不受重新分配或大小限制的影响。索引的使用应该是高效和连接明智的，我怀疑有很大的不同:无论如何大多数驱动程序都是批量传输。

增加的灵 active 可能会派上用场，例如，如果您想了解所有记录中一天的统计值(如果这对您的应用程序有意义)。如果您需要存储更多 stat_values，则在子文档方法中，每条记录的最大日期数将会减少。使用数据库文档而不是子文档通常也更容易。

如果您在多台服务器上聚合大量数据，Map/Reduce 就会真正发挥作用，否则带宽和客户端并发性将成为瓶颈。