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

Question

简介：

• 系统目前包含2个设备。
• 每个设备有10个测量数据的节点。该数据每5秒写入数据库。
• 我估计现在该设置的最大50：1（读取：写入）比率。当引入新设备/节点时，这很可能会改变。
• 我目前正在一个文档中嵌入everthing（例如：http://pastebin.com/4dATY5NF）
• 我的3个主要用例是：
  • 向DB添加度量
  • 从所有节点获取最后一次测量（对于5个节点，这将返回5个测量网）
  • 获取给定日期的测量列表（符合输入日期/时间标准的长测量列表）。

问题：

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

E.g。即使每5秒只有一个节点报告数据，嵌入式阵列中的测量总数（仅一天）为：24 * 60 * 60/5 = 17280。有5个节点报告一个月给出：5个嵌入式阵列和518400个元素（在一个文档中！）。设备工作的时间越长，每个连接节点的嵌入式测量数组中的条目就越多。

问题：

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

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

  我一直在想的是例如一个用于设备/节点配置的集合（此处嵌入信息，因为它没有太多），第二个仅用于测量（引用它来自设备和节点）。我认为这会花费几次调用DB，但在性能和内存使用方面会更好。

Answer 1

按顺序：

• 它没有。在单个文档中嵌入无限增长的结构不会扩展，应该避免。到目前为止，最好将每个测量值存储为单个文档。虽然写入性能会更稳定（但MongoDB必须定期移动增长的文档，这可能会导致写入延迟峰值），因此读取/写入比率一旦达到此目的就不是很相关。“
• 实际上并没有很多好东西＆＃34;关于嵌入。它使查询变得复杂，无法获得嵌入式结构的一小部分，等等。因此，它不仅是合理的，而且非常鼓励转向两个单独的收藏品。在未来的证明模式中，只有当您查询顶级文档并且无论系统必须处理多少用户或数据时，如果您查询顶级文档并且该嵌入式结构的大小限制，您是否始终需要整个嵌入式结构。