Блог

У меня есть дизайн документа 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 операций ввода-вывода, а в пиковое время мы достигаем 2000. В настоящее время мы запускаем набор реплик на Atlas с уровнем M30.

MongoDB предполагает, что следует избегать неограниченных массивов из-за того, как документы перемещаются на диске, если они превышают выделенное пространство по размеру. Это, казалось, было заметной проблемой для механизма хранения MMAP, но, согласно их документам, это было решено с помощью MongoDB 4.0, который использует механизм хранения WiredTiger.

Поэтому я предполагаю, что мой вопрос будет следующим:

1. Может ли кто-нибудь подтвердить, перемещает ли механизм хранения WiredTiger также документы на диске, как только они превышают выделенный размер? Как часто это будет происходить и может ли это иметь серьезные последствия? В документах также указано, что хранилище выделено с полномочиями 2. Если это так, то для одного документа должно быть только минимальное «перемещение документа», так как оно экспоненциально увеличивается с размером документа?
2. Принимая во внимание тот факт, что мне все еще нужен доступ к необработанным/нерасчислимым данным, каков был бы лучший способ хранения этих данных, если таковые имеются?

Заранее спасибо!

Обновление одного документа => Загрузка документа в память (вы можете выполнить простой тест, чтобы проверить его)>
Когда документ становится большим => каждое обновление стоит дороже

Решение => сохраняйте меньшие массивы, сокращая временной диапазон.

У вас есть диапазон времени 1 день, вы можете сделать его 5 часов или 1 час.
(чтобы получить измерения за весь день, вы можете сгруппировать их после) Я думаю , что в вашем случае , просто имея более короткий временной диапазон => меньшие массивы, будет достаточно одного способа сделать это-иметь одно дополнительное поле> {:id 1, :hour 1} {:id 1 ,:hour 2} ... , новое поле часа должно быть проиндексировано.

Насколько я знаю, это происходит, документы перемещаются, но у MongoDB есть способ сделать это быстро, предварительно выделив место, Если вам нужна дополнительная внутренняя информация, вы также можете спросить здесь, но я не думаю, что это ваша проблема или что вы найдете способ обновить и быстро, большие документы.(вы так часто обновляетесь, что размер вызывает проблемы)

*Возможно, есть лучшие способы сделать это, чем мое решение, лучше всего подождать и других ответов.