我有一个MongoDB文档设计，存储数组数据在6的顶级属性字段。该文档基本上存储了当天从一组特定传感器收集的物联网数据，并且在一天中非常频繁地更新(每2秒一次)。每个新的传感器数据包将数据附加到所有6个数组的末尾，这意味着到一天结束时，每个数组最多可以有43200个值(即使它从来没有得到那么多)。
基本结构如下:
{
_id: string,
tracker: string,
startTime: Date,
endTime: Date,
sensor1: number[],
sensor2: number[],
path: {
type: "Linestring",
coordinates: number[][],
},
times: Date[],
...
}
最近，我们的数据库似乎一直在"与高iops作斗争"。我们认为这可能是由于不断添加到这些数组中造成的。根据MongoDB顾问的说法，在过去的几个月里，这是几次主重启的情况，尽管我们的层允许3000 IOPS，而我们在高峰时间的最大IOPS只有2000。我们目前正在阿特拉斯上运行M30级的复制品。
MongoDB建议应该避免无界数组，因为如果文档的大小超过其分配的空间，那么文档将在磁盘上移动。对于MMAP存储引擎来说，这似乎是一个明显的问题，但根据他们的文档，使用WiredTiger存储引擎的MongoDB 4.0解决了这个问题。
所以我想我的问题是:
有人能确认一下，一旦文档超出分配的大小，WiredTiger存储引擎是否也会在磁盘上移动文档?这种情况多久发生一次，会产生重大影响吗?文档还指出，存储以2的幂分配。如果是这种情况，那么应该只有最小的"文档移动"。对于单个文档，因为它随着文档大小呈指数增长?
考虑到我仍然需要访问未处理/未计算的数据，如果有的话，存储这些数据的更好方法是什么?
提前感谢!
正在更新一个文档=>在内存中加载文档(你可以做简单的基准测试)
当文档变大=>每次更新花费更多
解决方案/strong>=比;
通过减少时间范围来保持更小的数组。你有一天的时间范围，你可以把它设置成5小时或1小时。
(要获得全天的测量值，您可以分组后)我认为在你的情况下，时间范围更短=>更小的数组，就足够了一种方法是增加一个额外的字段{:id 1, :hour 1} {:id 1 ,:hour 2} ...，新的小时字段应该被索引。
据我所知，它发生了，文档被移动，但MongoDB有一种方法可以通过预分配空间来快速做到这一点如果您需要更多的内部信息，您也可以在这里询问但我不认为这是你的问题，也不认为你会找到一种快速更新大型文档的方法。(你更新太频繁，所以大小导致问题)
*也许有比我的解决方案更好的方法，最好也等待其他的答案。