用于测量采集系统的 MongoDB 模式设计

Question

简介:

• 系统目前由 2 个设备组成。
• 每个设备都有 10 个测量数据的节点。该数据每 5 秒写入一次数据库。
• 我估计目前该设置的最大比率为 50:1(读:写)。当引入新设备/节点时，这很可能会改变。
• 我目前正在将所有内容嵌入到一个文档中(此处示例:http://pastebin.com/4dATY5NF)
• 我的 3 个主要用例是:
  • 将测量添加到数据库
  • 从所有节点获取最后一次测量(对于 5 个节点，这将返回 5 个测量网)
  • 获取给定日期的测量值列表(匹配输入日期/时间标准的长测量值列表)。

问题:

我主要担心的是随着时间的推移而增长很多的文档(插入到嵌入式测量数组)以及使测量难以查询给定日期/时间范围的一般文档结构。

例如即使每5秒只有一个节点上报数据，那么嵌入式阵列(仅一天)的测量总数为:24*60*60/5=17280。有 5 个节点报告一个月会给出:5 个包含 518400 个元素的嵌入式数组(在一个文档中!)。设备工作的时间越长，它在每个连接的节点的嵌入式测量数组中的条目就越多。

问题:

• 估计的读/写比率如何影响嵌入与链接的决策？

• 在这种情况下，牺牲嵌入的所有好处并将数据分成 2 个集合是否合理？

  我一直在想的是例如一个用于设备/节点配置的集合(此处嵌入信息，因为信息不多)，第二个仅用于测量(引用它来自的设备和节点)。我认为这会增加对数据库的几次调用，但在性能和内存使用方面会更好。

Answer 1

顺序:

• 它没有。在单个文档中嵌入无限增长的结构不会扩展，应该避免。到目前为止，最好将每个测量值存储为一个文档。尽管写入性能会更稳定(MongoDB 必须定期移动不断增长的文档，这可能会导致写入延迟峰值)，但一旦您这样做，读/写比率就不是很相关。
• 实际上，嵌入并没有太多“好东西”。它使查询复杂化，无法获取嵌入式结构的一小部分等等。因此，转移到两个单独的集合不仅是合理的，而且受到强烈鼓励。在未来的证明模式中，当且仅当您在查询顶级文档时始终需要整个嵌入式结构，并且无论您的系统必须处理多少用户或数据，该嵌入式结构是否受大小限制，您都会嵌入。<