В MongoDB - стратегия увеличения производительности записи в документы ежедневного журнала

У нас есть коллекция данных журнала, где каждый документ в коллекции идентифицируется MAC-адресом и календарным днем. Обычно:

{
  _id: ,
  mac: ,
  day: ,
  data: [ "value1", "value2" ]
}

Каждые пять минут мы добавляем новую запись журнала в массив данных в документе текущего дня. Документ переносится в полночь по всемирному координированному времени, когда мы создаем новый документ для каждого MAC.

Мы заметили, что IO, измеряемое количеством записанных байтов, увеличивается в течение всего дня, а затем снова падает в полночь по всемирному координированному времени. Этого не должно происходить, потому что частота сообщений журнала постоянна. Мы считаем, что неожиданное поведение связано с перемещением документов Mongo, а не с обновлением их массивов журналов на месте. Как бы то ни было, stats () показывает, что paddingFactor равен 1.0299999997858227.

Несколько вопросов:

1. Есть ли способ подтвердить, обновляется ли Mongo на месте или перемещается? Мы видим некоторые изменения в журнале медленных запросов, но это похоже на анекдотическое свидетельство. Я знаю, что могу db.setProfilingLevel (2) , затем db.system.profile.find () и, наконец, найти «перемещено: истина» , но я не уверен, можно ли это делать в загруженной производственной системе.
2. Размер каждого документа очень предсказуемый и постоянный.Предполагая, что Монго делает много ходов, как лучше всего выяснить, почему Монго не может более точно определять размер? Или сделать монго более точным? Если предположить, что приведенное выше описание проблемы верно, настройка коэффициента заполнения, похоже, не поможет.
3. Для меня должно быть достаточно легко выполнить предварительную настройку документа и избавиться от любых догадок от Mongo. (Я знаю, что коэффициент заполнения документы говорят, что мне не нужно этого делать, но мне просто нужно оставить эту проблему позади.) Как лучше всего задать размер документа? Кажется, просто написать документ с полем массива байтов мусора, а затем немедленно удалить это поле из документа, но есть ли какие-то подводные камни, о которых я должен знать? Например, я могу представить, что мне нужно ждать на сервере операции записи (т.е. выполнять безопасную запись) перед удалением поля мусора.
4. Я был обеспокоен предварительным размещением всех дневных документов примерно в одно и то же время, потому что, похоже, в то время это могло бы привести к насыщению диска. Это обоснованное беспокойство? Следует ли мне попытаться распределить предварительные затраты на предыдущий день?