2

介绍：

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

问题：

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

例如，即使每 5 秒只有一个节点上报数据，那么嵌入式阵列中的测量总数（仅 1 天）为：24*60*60/5=17280。一个月报告 5 个节点给出： 5 个具有 518400 个元素的嵌入式数组（在一个文档中！）。设备工作的时间越长，它在每个附加节点的嵌入式测量数组中的条目就越多。

问题：

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

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

    我一直在考虑的是，例如一个用于设备/节点配置的集合（在此处嵌入信息，因为它并不多），而第二个仅用于测量（参考它来自的设备和节点）。我认为这将花费更多对数据库的调用，但在性能和内存使用方面会更好。

4

1 回答 1

2

为了 ：

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