测量采集系统的MongoDB方案设计

Question

简介：

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

​

问题：

我主要关心的是随时间增长的文档(插入到嵌入的度量数组中)，以及使度量难以查询给定日期/时间范围的一般文档结构。

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

问题：

• 估计的读写比如何影响嵌入与链接的决策？
• 在这种情况下，牺牲嵌入数据并将数据分成两个集合的所有优点是否合理？ 我一直在想的是，例如，一个用于设备/节点配置的集合(在这里嵌入信息，因为没有太多信息)，而第二个集合仅用于度量(引用它来自的设备和节点)。我认为这将增加对DB的几次调用，但在性能和内存使用方面会更好。

Answer 1

按顺序：

• 但事实并非如此。在单个文档中嵌入无限增长的结构并不是可伸缩的，应该避免。到目前为止，最好将每个度量存储为一个文档。一旦你这么做，读/写的比率就不是很重要了，尽管写性能会更稳定(MongoDB必须定期移动不断增长的文档，这可能会导致写延迟高峰)。
• 其实嵌入并没有太多的“好东西”。它使查询变得复杂，无法获得嵌入式结构的一小部分等等。因此，它不仅是合理的，而且高度鼓励移到两个单独的集合。在未来的验证模式中，如果您查询顶级文档，并且无论您的系统必须处理多少用户或数据，如果该嵌入结构是大小绑定的，则您始终需要嵌入if，并且只有当您需要嵌入的架构时才需要整个嵌入式结构。